ورود به VPN و سپس باج‌افزار: شواهد از چه چیزی پشتیبانی می‌کنند
ورود در 02:14 و فایل‌های رمزی‌شده در 03:02 توالی‌ای است که ارزش بررسی دارد، نه نقطه ورود. شواهد احراز هویت، نشست و میزبان را جدا نگه دارید.
همه موارد زیر از یک رکورد فرضی استفاده می‌کنند، که برای نشان دادن یک شکل ساخته شده، نه برای توصیف یک پرونده واقعی. مثل یک زنجیره خوانده می‌شود: احراز هویت دروازه در 02:14، نشست رومیزی در 02:19، تغییر حساب دارای امتیاز در 02:41 و فایل‌های رمزی‌شده که در 03:02 پیدا شدند. خط اول شبیه پاسخ به نظر می‌رسد و گزارش اغلب طوری نوشته می‌شود که گویی پاسخ همان است. ورود رویدادی است که دروازه ثبت کرده، نه یافته‌ای درباره اینکه کسی چگونه وارد شده، و همین تفاوت تعیین می‌کند بعد چه کاری انجام دهید.
نشانه: ورودی که شبیه پاسخ است
سوابق احراز هویت آسان‌ترین شواهد برای به دست آوردن و آسان‌ترین برای بیش‌تفسیر کردن هستند. آن‌ها نشان می‌دهند که سرویس یک اعتبارنامه را در زمانی، از نشانی‌ای، برای حسابی پذیرفته است. آن‌ها نشان نمی‌دهند که چه کسی اعتبارنامه را کنترل می‌کرده، آیا دروازه بهره‌برداری شده یا آیا دستگاه صاحب حساب از قبل در معرض نفوذ بوده است.
سه توضیح با همان خط ورود سازگارند. کسی از رمز عبور دزدیده‌شده استفاده کرده و دروازه دقیقاً همان کاری را کرده که برایش ساخته شده است. لپ‌تاپی که پیش‌تر در معرض نفوذ بوده، به سادگی مثل همیشه وارد شده است. یک سرویس در معرض خطر نامرتبط ورود واقعی را فراهم کرده و نشست VPN اقدام بعدی و جداگانه همان عامل است.
هر توضیح شواهد متفاوتی در جای دیگری از محیط پیش‌بینی می‌کند، و به همین دلیل تحقیق باید به دنبال آن پیش‌بینی‌ها برود، نه تأیید اولین توضیحی که جور در می‌آید. رمز عبور دزدیده‌شده جغرافیا یا زمان احراز هویت غیرعادی را پیش‌بینی می‌کند. لپ‌تاپ در معرض نفوذ، مصنوعات میزبان را پیش از ورود پیش‌بینی می‌کند. نقطه ورود نامرتبط، فعالیتی را پیش‌بینی می‌کند که هیچ ارتباطی با دروازه ندارد.
رویدادها را پیش از روایت کردن جدا نگه دارید
رویدادها را پیش از آنکه هر روایتی وجود داشته باشد جداگانه بنویسید، چون روایت، خط زمانی را به چیدن پیرامون یک مظنون دعوت می‌کند. هر خط باید بگوید آن رکورد چه چیزی را اثبات می‌کند و به‌طور جداگانه، چه چیزی را به تنهایی نمی‌تواند اثبات کند. همان لحظه‌ای که دو خط در یک جمله ادغام شوند، یک تفسیر از پیش برنده شده است.
توجه کنید که رویداد آخر درباره کشف است، نه درباره مهاجم. زمان کشف و زمان نفوذ معمولاً ساعت‌ها یا هفته‌ها فاصله دارند، و گزارشی که آن‌ها را برابر می‌گیرد هر خواننده‌ای را که پس از شما بیاید گمراه می‌کند.
ثبت کنید هر مهر زمانی از کجا آمده، نه فقط چه می‌گوید. زمان دریافت گردآورنده، زمان رویداد و زمان کشف سه عدد متفاوت‌اند، و نرمال‌سازی خاموش آن‌ها در یک ستون همان چیزی است که به خط زمانی شکلی می‌دهد که شواهد هرگز نداشته‌اند.
رکوردها را فقط جایی به هم بپیوندید که شناسه‌ها هم‌خوانی دارند
ادغام رکوردها یک فرضیه است، نه گامی از قالب‌بندی. نام حساب، نشانی VPN اختصاص‌یافته، میزبان هدف و شناسه نشست باید هم‌خوانی داشته باشند تا دو ردیف به یک داستان تبدیل شوند. یک نشانی عمومی مشترک کافی نیست، چون از روی طراحی مشترک است.
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
وقتی ورودی را ردیابی می‌کنید جدول را از پایین به بالا بخوانید، و وقتی دامنه تأثیر را مشخص می‌کنید از بالا به پایین، چون این دو پرسش جهت‌های مخالف می‌خواهند. جایی که شناسه‌ها واقعاً هم‌خوانی دارند، بگویید و به هر دو رکورد استناد کنید. جایی که هم‌خوانی ندارند، شکاف را آشکار بگذارید نه اینکه با یک فرض آن را ببندید.
اینجا همان جایی است که یک نام کاربری آشنا گمراه می‌کند. همان حساب را می‌توان صبح صاحب قانونی و شب کس دیگری استفاده کند، و نام حساب به تنهایی نمی‌تواند آن‌ها را از هم تشخیص دهد. حساب را نسبت دهید، سپس شخص را جداگانه نسبت دهید، و تنها زمانی که چیزی از آن پشتیبانی می‌کند. بیشتر خط‌های زمانی که در بازبینی از هم می‌پاشند دقیقاً همین گام را بیش از حد سریع برداشته‌اند.
گزارش‌های ناقص یک شکاف است، نه شاهد منفی
نبود رویدادهای رمز عبور ناموفق اثبات نمی‌کند که ورود موفق قانونی بوده است. اعتبارنامه‌های دزدیده‌شده معتبر یک رکورد احراز هویت موفق و هیچ شکستی تولید نمی‌کنند، و همین است که سرقت اعتبارنامه را جذاب می‌کند.
به همین ترتیب، پورتی که امروز بسته است چیزی درباره امروز می‌گوید. درباره اینکه آن سرویس آن زمان در معرض بود یا نه، آن زمان آسیب‌پذیر بود یا نه، یا اینکه حمله را حمل کرده یا نه، چیزی نمی‌گوید. پیکربندی تاریخی و شواهد سرویس تنها راه بستن آن شکاف هستند.
شکاف را به‌صراحت در گزارش بیان کنید. «ما برای آن بازه سابقه‌ای نداریم» جمله‌ای قابل دفاع است؛ «چیز دیگری رخ نداد» نیست و به شما بازگردانده می‌شود. شکاف‌ها صاحب هم دارند: سیستمی را نام ببرید که باید رکورد را تولید می‌کرد و چرا نکرد. همان خط یک حذف را به مورد اصلاح تبدیل می‌کند.
یافته‌ها را در سطحی بنویسید که شواهد پشتیبانی می‌کنند
حفظ، مهار و بازیابی را از طریق مالک حادثه هماهنگ کنید، نه دور از او. راهنمای فنی CISA بر جمع‌آوری مصنوعات و گزارش‌های مرتبط پیش از آنکه اصلاح، آنچه باقی مانده را تغییر دهد تأکید می‌کند، و این ترتیب از هر ابزار واحدی مهم‌تر است.
اجرای دوباره یک اکسپلویت مشکوک روی تجهیزات زنده برای بستن شکاف ارزش ریسک افزوده را ندارد. آزمایشی که نشان دهد حمله‌ای می‌توانست کار کند، شاهد آن نیست که کار کرده، و تفاوت این دو گزاره تمام انضباط این تمرین است.
با چهار فهرست پایان دهید: چه چیزی مشاهده شد، رکوردها از چه روابطی پشتیبانی می‌کنند، چه چیزی فرضیه می‌ماند و کدام رکوردها در دسترس نیستند. «در جریان حادثه از یک حساب VPN استفاده شد» وقتی رکوردها پشتیبانی کنند در فهرست دوم قرار می‌گیرد. «VPN باعث باج‌افزار شد» تا وقتی چیزی علیت را اثبات نکند هیچ‌جا قرار نمی‌گیرد.