IOC مخفف Indicator of Compromise است؛ به فارسی خودمانی: نشانی که اگر جایی دیدید، باید زنگ خطرتان به‌صدا درآید.

مشکل اینجاست که هر ردی از لاگ، IOC خوب نیست. خیلی از تیم‌ها بعد از یک سندباکس‌ران، بیست خط دامنه و مسیر فایل را در تیکت می‌ریزند و فردا نصفش false positive می‌شود.

دسته‌های رایج IOC

Hash فایل برای همان باینری عالی است و برای variant بعدی سریع می‌سوزد. دامنه ممکن است یک هفته قیمت داشته باشد یا همان روز بسوزد. IP اشتراکی می‌تواند نصف CDN بی‌گناه را قربانی کند.

IOC خوب چه شکلی است؟

چهار سؤال قبل از انتشار داخلی:

  1. چقدر اختصاصی است؟ chrome.exe شاخص نیست.
  2. چقدر پایدار است؟ دامنهٔ یک‌بارمصرف را برای بلاک دائمی برندارید مگر سیاست‌تان کوتاه‌مدت باشد.
  3. زمینه چیست؟ از کدام نمونه، در چه تاریخی، با چه اطمینانی؟
  4. اقدام چیست؟ بلوکه؟ شکار؟ فقط آگاهی؟

بدون پاسخ سؤال چهار، IOC فقط دکوراسیون گزارش است. برای نوشتن گزارش قابل‌عمل، این راهنما را ببینید.

از سندباکس تا لیست قابل‌اعتماد

در اجرای دینامیک معمولاً زیاد می‌بینید: DNSهای ویندوز، telemetry نرم‌افزار، آپدیت. کار تحلیل‌گر جدا کردن سیگنال از پس‌زمینه است.

روش کاربردی:

اگر به ساخت بلوکه‌لیست می‌رسید، بعداً ساخت امن blocklist را بخوانید.

mutex و دوستانش

خیلی‌ها mutex را فراموش می‌کنند چون در SIEM کمتر به‌صورت پیش‌فرض شکار می‌شود. با این حال برای تشخیص خانواده یا جلوگیری از اجرای دوباره روی همان میزبان، طلاست — مخصوصاً وقتی نامش منحصربه‌فرد باشد نه یک GUID تصادفی هر اجرا.

جمع‌بندی

IOC پلی است بین «چیزی که در سندباکس دیدید» و «کاری که شیفت بعد می‌تواند بکند». کم، مستند، و اقدام‌پذیر جمع کنید؛ انبار شاخص‌های پوسیده نسازید.

مشاهدهٔ لایه‌ای در آزمایشگاه سیستم‌کال کمک می‌کند همان IOC را از روی رفتار واقعی جدا کنید، نه از روی حدس.