پاک‌سازی Neshta، تحلیل Persistence و File Association، رفع اختلال فایل‌ ویندوز.

با تشخیص آلودگی Neshta و جلوگیری از آن، در این پست آشنا شدیم (برای آشنایی بهتر روی لینک کلیک کنید)
حالا به سراغ تجربه شخصی خودم این ویروس و نحوه پاکسازیش از ویندوز سیستمم میریم.

نقطه شروع  Incident

در وحله یک ویروس که ویندوز دیفندر ان را با نام NetshaC میشناخت وارد سیستم من شده بود و احتمالا بخاطر وجود exclusion هایی که روی Windows Defender برای پوشه هام گذاشته بودم توسط انتی ویروس شناسایی نشد.

طی استفاده ای که میکردم ناگهان تعداد چند هزار هشدار Threat Found از انتی ویروس برام اومد.

با بررسی مسیر و نام های فایل هایی که داشتند توسط انتی ویروس پاک میشدند متوجه شدم فایل های معتبری با پسوند .exe درحال پاک شدن بودند حتی برنامه هایی مثل msedge و یا notepad.exe داشتند توسط انتی ویروس حذف میشدند.

اولش فکر میکردم که انتی ویروس ویندوز دچار باگ شده مخصوصا چون قبل این موضوع یکبار ویندوزم رو اپدیت کرده بودم. با نصب مجدد ویندوز این مورد مجدد تکرار شد و با باز کردن اولین فایل .exe داخل ویندوز جدید مجددا انتی ویروس همین رفتار رو نشون میداد.

بعد ازینکه انتی ویروس فایل هارو پاک میکرد یکسری علائم داخل ویندوز داشتم :

همچنان چندین بار نسخه های مختلف از ویندوز رو نصب کردم ولی مشکل همچنان وجود داشت.

در این مرحله مسئله را به‌صورت زیر تعریف کردم:

آیا Defender فقط در حال حذف فایل‌های سالم به طور اشتباه است ؟ یا Defender الوده شده ؟ و شاید این پروتکل جدید مایکروسافت برای خراب کردن ویندوز های کرکی است.

همین سؤال، نقطه شروع اصلی Investigation شد.
 

علائم غیرعادی در Windows

قبل از رسیدن به IOC اصلی، چند رفتار غیرعادی در سیستم مشاهده می‌شد.

مشکل در اجرای فایل‌های  EXE

یکی از مهم‌ترین علائم این بود که بعضی فایل‌های اجرایی با رفتار عادی Windows اجرا نمی‌شدند.

به جای اجرای مستقیم برنامه، Windows در برخی موارد با پیامی شبیه:

Choose an app to open this file

رفتار می‌کرد.

این پیام برای یک فایل .exe عادی نیست.

چون Windows به‌صورت پیش‌فرض می‌داند فایل‌های .exe باید توسط Windows executable loader اجرا شوند.

بنابراین وقتی سیستم با یک فایل EXE مثل یک فایل معمولی رفتار می‌کند، یکی از مواردی که باید بررسی شود، File Association مربوط به EXE است.
 

چرا File Association برای EXE اهمیت دارد؟

Windows برای انواع فایل‌ها Association تعریف می‌کند.

برای مثال:

• .txt → Notepad
• .jpg → Image Viewer
• .pdf → PDF Reader
• .exe → Windows executable handling

برای فایل‌های اجرایی، Registry مسیر مهمی در این فرآیند دارد.

یکی از کلیدهای مهم:

HKCR\exefile\shell\open\command

است.

در حالت صحیح، مقدار پیش‌فرض این بخش باید عملاً به اجرای خود فایل اشاره کند:

"%1" %*

معنی آن ساده است:

• %1 = فایل اجرایی که کاربر قصد اجرای آن را دارد
• %* = سایر آرگومان‌های command line

بنابراین اگر کاربر مثلاً:

C:\Tools\test.exe

را اجرا کند، Windows  باید همان فایل را به executable handling mechanism خودش تحویل دهد.
 

چیزی که در سیستم مشاهده شد

در زمان بررسی Registry، مقدار این کلید مشاهده شد:

HKEY_CLASSES_ROOT\exefile\shell\open\command
(Default)
C:\WINDOWS\svchost.com "%1" %*

این مورد بسیار مهم بود.

چرا؟

چون به جای اینکه Windows مستقیماً %1  را اجرا کند، یک فایل دیگر به‌عنوان واسطه معرفی شده بود:

C:\WINDOWS\svchost.com

در واقع زنجیره اجرا به این شکل تغییر کرده بود:

User→example.exe→exefile association→ C:\Windows\svchost.com→"%1" %*

یعنی تقریباً هر زمانی که یک فایل EXE اجرا می‌شد، سیستم ابتدا آن فایل را از طریق svchost.com عبور می‌داد.

این رفتار برای svchost.com  کاملاً غیرعادی بود.

 

svchoct.com نامی که عمداً گمراه‌کننده است

یکی از نکات جالب Incident همین نام فایل بود.

Windows یک فرآیند شناخته‌شده دارد:

svchost.exe

که همان Service Host است و برای اجرای سرویس‌های مختلف Windows استفاده می‌شود.

اما فایل مشاهده‌شده:

svchost.com

بود.

این دو فایل یکسان نیستند.

در Windows، پسوند .com نیز می‌تواند یک نوع فایل اجرایی باشد.

بنابراین وجود فایلی با نام:

svchost.com

در مسیر:

C:\Windows\

می‌تواند از نظر ظاهری بسیار گمراه‌کننده باشد.

کاربر ممکن است با دیدن  svchostتصور کند که با یک فایل سیستمی Windows مواجه است، در حالی که پسوند فایل متفاوت است.

در این Incident، Defender نیز دقیقاً همین فایل را به‌عنوان تهدید شناسایی کرد.
 

بررسی خود فایل svchost.com

برای بررسی وجود فایل از دستور زیر استفاده شد:

dir C:\Windows\svchost.com /a

خروجی نشان داد که فایل واقعاً وجود دارد.

سپس مشخصات فایل با PowerShell بررسی شد:

Get-Item 'C:\Windows\svchost.com' |
Select-Object FullName,Length,CreationTime,LastWriteTime,LastAccessTime

در محیط مستندسازی‌شده، فایل دارای مشخصاتی مشابه موارد زیر بود:

نکته:

 مهم‌تر، نبودن اطلاعات معتبر مربوط به Version Information بود.

همچنین بررسی امضای دیجیتال:

Get-AuthenticodeSignature 'C:\Windows\svchost.com'
Status : NotSigned

در حالی که فایل‌های سیستمی معتبر Windows معمولاً در بسیاری از موارد دارای امضای دیجیتال معتبر Microsoft هستند.

البته:

 Unsigned بودن به‌تنهایی به معنی Malware بودن نیست.

اما وقتی این موضوع همراه با:

• نام مشابه فایل سیستمی
• قرار گرفتن در C:\Windows
• تغییر  File Association
• رفتار غیرعادی  EXE 
• و Detection توسط  Defender

دیده می‌شود، ارزش Evidence آن بسیار بالا می‌رود.
 

Hash  کردن  IOC

برای اینکه به جای تکیه صرف بر اسم فایل، یک شناسه محتوایی دقیق از آن داشته باشیم، SHA-256 گرفته شد:

Get-FileHash 'C:\Windows\svchost.com' -Algorithm SHA256
SHA256: f04acd9936ce613948e18cef4590ac6a78f3c26824cb4aca62bf3b9d2c765e15

هش اهمیت زیادی دارد چون نام فایل قابل تغییر است، اما SHA-256 محتوای همان فایل را مشخص می‌کند.

بنابراین در Incident Response بهتر است IOC را به شکل زیر ثبت کنیم:

Path:

Evidence بسیار مهم:  Windows Defender

برای بررسی اینکه Defender دقیقاً چه چیزی شناسایی کرده، از PowerShell استفاده شد:

Get-MpThreatDetection
Where-Object{
     $_.Resources-match’svchost\.com|Neshta|3582-490|directx\sys’
   }
Select-Object
InitialDetectionTime,
LastThreatStatusChangeTime,
ThreatID,
ThreatStatusID,
ActionSuccess,
Resources
Format-List

نتیجه نشان داد:

همچنین Event مربوط به Defender نشان می‌داد:

این بخش از Investigation بسیار مهم بود.

چون در این مرحله دیگر فقط با یک فایل ناشناخته مواجه نبودیم.

خود Microsoft Defender نیز فایل را به‌عنوان یک تهدید مشخص شناسایی کرده بود.
 

 Neshta چیست ؟

Neshta یک خانواده قدیمی از Malwareهای File Infector است.

File Infectorها برخلاف بسیاری از Trojanهای معمولی، می‌توانند به فایل‌های اجرایی توجه ویژه‌ای داشته باشند.

این موضوع برای Incident ما اهمیت زیادی داشت، زیرا یکی از علائم اصلی سیستم نیز مربوط به فایل‌های .exe بود.

به‌صورت مفهومی، یک File Infector می‌تواند زنجیره‌ای شبیه این داشته باشد:

Malware→Infect executable→Modify execution behavior→Persistence→Execute through modified association

البته از روی یک IOC به‌تنهایی نمی‌توان با قطعیت گفت تمام فایل‌های سیستم آلوده شده‌اند.

اما ترکیب Detection + Registry Modification + فایل‌های غیرعادی، نیاز به بررسی جدی را ایجاد می‌کند.

 بررسی  directx.sys 

در ادامه فایل دیگری مشاهده شد:

C:\Windows\directx.sys

در نگاه اول اسم فایل ممکن است شبیه یک فایل مرتبط با DirectX به نظر برسد.

اما بررسی دقیق‌تر نشان داد فایل فقط:

39 bytes

حجم داشت.

برای بررسی:

Get-Item 'C:\Windows\directx.sys' | Format-List *

و سپس:

type C:\Windows\directx.sys

اجرا شد.

محتوای فایل چیزی شبیه این بود:

C:\WINDOWS\TEMP\3582-490\MICROS~1.EXE

این Discovery بسیار مهم بود.

چون فایل با پسوند  .sys در ظاهر شبیه Driver است، اما محتوای آن در واقع فقط یک مسیر متنی بود.

بنابراین نمی‌توان آن را صرفاً بر اساس اسم، یک Driver واقعی فرض کرد.
 

 چرا directx.sys مشکوک بود؟

یک Driver واقعی معمولاً یک PE binary معتبر است و ساختار خاص خودش را دارد.

فایلی با:

directx.sys

39 bytes

که فقط حاوی یک مسیر Windows است، با مفهوم Driver واقعی همخوانی ندارد.

از طرف دیگر، اسم:

directx.sys

می‌تواند برای ایجاد حس اعتماد استفاده شده باشد.

این تکنیک در Malwareها رایج است:

استفاده از نام‌هایی که شبیه فایل‌ها یا اجزای واقعی سیستم‌عامل هستند.

برای همین در بررسی Malware نباید صرفاً به filename اعتماد کرد.
 

مسیر Temp و پوشه 3582-490

یکی دیگر از بخش‌های مهم Investigation پوشه زیر بود:

C:\Users\<USER>\AppData\Local\Temp\3582-490

داخل آن چند فایل اجرایی مشاهده شد:

IDMan.exe

msedge.exe

msedgewebview2.exe

وجود فایل‌هایی با نام برنامه‌های شناخته‌شده در Temp به‌خودی‌خود اثبات‌کننده Malware نیست.

نرم‌افزارهای مختلف واقعاً از Temp استفاده می‌کنند.

اما اینجا مسئله زمانی مهم شد که یکی از فایل‌ها:

IDMan.exe

با فایل اصلی IDM موجود در Program Files مقایسه شد.
 

مقایسه دو IDMan.exe 

فایل رسمی‌تر:

C:\Program Files (x86)\Internet Download Manager\IDMan.exe

و فایل Temp:

C:\Users\<USER>\AppData\Local\Temp\3582-490\IDMan.exe

از نظر مشخصات یکسان نبودند.

نمونه خروجی:

و مهم‌تر از آن SHA-256 متفاوت بود.

بنابراین این دو فایل از نظر محتوای باینری یکسان نبودند.
 

 Digital Signature و HashMismatch 

بررسی امضای فایل

Get-AuthenticodeSignature `
'C:\Users\<USER>\AppData\Local\Temp\3582-490\IDMan.exe' |
Format-List Status,StatusMessage,SignerCertificate,Path

نتیجه:

Status: HashMismatch

این مورد با  NotSigned فرق دارد.

 NotSigned یعنی فایل امضای دیجیتال ندارد.

اما:

HashMismatch

یعنی یک امضا/اطلاعات امضای دیجیتال وجود داشته، ولی محتوای فعلی فایل با چیزی که در امضا انتظار می‌رود مطابقت ندارد.

در نتیجه فایل ممکن است:

• تغییر داده شده باشد،
• Patch شده باشد،
• دستکاری شده باشد،
• یا نسخه‌ای باشد که امضای آن معتبر نیست.

در Incident Response این یک Indicator بسیار مهم است.
 

نکته مهم درباره IDMan.exe 

در ابتدا ممکن بود تصور شود:

چون IDMan.exe مربوط به Internet Download Manager است، پس مشکلی ندارد.

اما بررسی نشان داد فایل موجود در Temp با نسخه Program Files متفاوت است و Digital Signature آن نیز:

HashMismatch

بود.

بنابراین صرفاً filename یا حتی وجود نام شرکت در Certificate کافی نیست.

باید حداقل این موارد با هم بررسی شوند:

Path → Hash → Signature → File Size  → Creation Time →Parent Process → Command Line
 

 اجرای IDMan.exe از Temp 

یکی از شواهد مهم دیگر این بود که فایل Temp واقعاً در حال اجرا بود.

بررسی Process:

Get-CimInstance Win32_Process |
Where-Object {
    $_.ExecutablePath -eq
    'C:\Users\<USER>\AppData\Local\Temp\3582-490\IDMan.exe'
} |
Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine |
Format-List

خروجی نمونه:

این قسمت بسیار مهم بود.

چون مشخص شد فایل فقط روی دیسک وجود ندارد؛ بلکه واقعاً به‌عنوان Process اجرا شده است.
 

اهمیت Command Line 

این بخش:

/onboot

نیز ارزش بررسی داشت.

 Command Line می‌تواند مشخص کند یک Process با چه هدفی اجرا شده است.

برای Incident Response معمولاً بررسی این موارد بسیار مفید است:

چون filename به‌تنهایی ممکن است جعل شده باشد.

مثلاً:

msedge.exe

می‌تواند:

C:\Program Files\Microsoft\Edge\msedge.exe

باشد.

یا:

C:\Users\<USER>\AppData\Local\Temp\...\msedge.exe

این دو از نظر امنیتی یکسان نیستند.

بررسی Startup Registry

در ادامه Startup Registry بررسی شد:

Get-ItemProperty `
'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'

در ابتدا مقدار مشکوکی برای IDMan وجود داشت:

IDMan:

C:\Users\<USER>\AppData\Local\Temp\3582-490\IDMan.exe /onboot

این یعنی Windows هنگام Login کاربر می‌توانست فایل Temp را اجرا کند.

از دید Persistence ، این موضوع اهمیت زیادی دارد.

Run Key چیست؟

 Registry Run Key یکی از روش‌های شناخته‌شده برای اجرای خودکار برنامه‌ها هنگام Login است.

برای User فعلی:

و برای کل سیستم:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

استفاده می‌شود.

به‌طور ساده:

Windows Login → Run Keys → Configured Executable → Process

بنابراین اگر یک فایل ناشناخته در Temp داخل Run Key قرار گیرد، باید به‌عنوان یک Persistence Mechanism بررسی شود.

بررسی وضعیت Registry پس از پاک‌سازی

بعد از اصلاح موارد مشکوک، Registry دوباره بررسی شد:

Get-ItemProperty `
'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'

در وضعیت اصلاح‌شده، موارد شناخته‌شده و معتبر باقی مانده بودند؛ از جمله مواردی مربوط به نرم‌افزارهای قانونی نصب‌شده. مهم این بود که مسیر Temp مشکوک دیگر در Startup قرار نداشت.
 

 بررسی File Association بعد از اصلاح

یکی از مهم‌ترین بخش‌های Recovery، بازگرداندن Association مربوط به EXE بود.

کلید بررسی‌شده:

reg query "HKCR\exefile\shell\open\command"

و همچنین:

reg query "HKLM\SOFTWARE\Classes\exefile\shell\open\command"

در وضعیت آلوده، مقدار:

C:\WINDOWS\svchost.com "%1" %*

وجود داشت.

این یعنی Windows برای اجرای EXE ابتدا به  svchost.com هدایت می‌شد.

در وضعیت صحیح، باید منطق اجرای فایل به شکل استاندارد Windows برگردد:

"%1" %*

وجود:

IsolatedCommand
"%1" %*

نیز در بررسی دیده شد.
 

چرا این Registry Modification بسیار مهم بود؟

این تغییر می‌تواند اثر بسیار گسترده‌ای داشته باشد.

فرض کنیم کاربر می‌خواهد این فایل را اجرا کند:

notepad.exe

در حالت طبیعی:

notepad.exe → Windows executable handling → notepad.exe  

اما اگر Association دستکاری شده باشد:

notepad.exe → C:\Windows\svchost.com → notepad.exe

در این حالت Malware می‌تواند خودش را در مسیر اجرای فایل‌های EXE قرار دهد.

این دقیقاً دلیل مهم بودن چنین Registry Modificationهایی است.
 

ارتباط Registry با علائم روزمره سیستم

بعد از اینکه Registry را با علائم سیستم کنار هم گذاشتم، بسیاری از رفتارهای عجیب قابل توضیح‌تر شدند.

مشکل اجرای EXE 

چون handler فایل‌های EXE تغییر کرده بود.

Choose an app

چون Windows دیگر رفتار استاندارد اجرای EXE را دنبال نمی‌کرد.

Incorrect Parameter

می‌تواند نتیجه اجرای یک executable از طریق یک handler یا command line غیرطبیعی باشد.

نیاز به Run as administrator

اجرای بعضی برنامه‌ها با Token متفاوت می‌تواند باعث شود رفتارشان متفاوت شود، اما این علامت به‌تنهایی اثبات‌کننده Malware نیست.

مشکل در اجرای برنامه‌های مختلف

چون modification در سطح  exefile قرار گرفته بود، اثر آن می‌توانست گسترده باشد.
 

حذف IOC اصلی

پس از شناسایی IOCها، تمرکز روی پاک‌سازی موارد مشخص قرار گرفت.

IOCهای اصلی شامل:

و Registry modification مربوط به:

HKCR\exefile\shell\open\command

بودند.

همچنین Startup entry مربوط به اجرای IDMan از Temp بررسی و اصلاح شد.
 

چرا فقط حذف فایل کافی نبود؟

این یکی از مهم‌ترین درس‌های این Incident بود.

اگر فقط:

svchost.com

را حذف کنیم ولی Registry را اصلاح نکنیم، سیستم همچنان ممکن است دنبال همان مسیر بگردد.

یعنی:

EXE → Registry → C:\Windows\svchost.com → File Missing

در نتیجه مشکل اجرای EXE می‌تواند باقی بماند و دقیقا همین اتفاق افتاد.

قبل از حذف کامل من فقط فایل svchost.com رو پاک کردم بدون درست کردن ریجستری و بعد از بوت شدن سیستم همون اول پیغام مربوط به choose an app to open .exe file رو داد که به معنی وجود یک .exe و اجرای ان همزمان با بوت سیستم است.

برعکس، اگر فقط Registry را اصلاح کنیم ولی فایل و Persistence باقی بمانند، ممکن است Malware دوباره Registry را تغییر دهد.

بنابراین Recovery باید چند لایه را پوشش دهد:

IOC File → Persistence → Registry Modification → Malicious Copies → Defender Detection
 

پاک‌سازی و بررسی مجدد

بعد از پاک‌سازی، موارد مشکوک دوباره بررسی شدند.

برای مثال:

dir C:\Windows\svchost.com /a

باید دیگر فایل را نشان نمی‌داد.

همچنین:

where /r C:\ svchost.com

برای پیدا کردن  Copy های دیگر استفاده شد.

این دستور اهمیت زیادی دارد چون ممکن است Malware فقط در یک مسیر نباشد.
 

اهمیت جستجوی Copyهای دیگر

فرض کنیم:

C:\Windows\svchost.com

حذف شود.

اما Copy دیگری وجود داشته باشد:

C:\Users\<USER>\AppData\Local\Temp\abc\svchost.com

در این صورت Incident هنوز تمام نشده است.

برای همین جستجوی recursive انجام شد:

where /r C:\ svchost.com

در وضعیت نهایی فقط مسیرهای مورد انتظار باید باقی بمانند.

بررسی مجدد Registry

بعد از پاک‌سازی:

reg query "HKCR\exefile\shell\open\command"

بررسی شد.

هدف این بود که دیگر مقدار:

C:\WINDOWS\svchost.com "%1" %*

وجود نداشته باشد.

و منطق استاندارد اجرای EXE به حالت صحیح بازگردد.

این مرحله به اندازه حذف فایل Malware مهم بود.
 

بررسی Startup

همچنین:

Get-ItemProperty `
'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'

اجرا شد.

هدف:

C:\Users\<USER>\AppData\Local\Temp\3582-490\IDMan.exe

نباید دیگر در Startup باقی مانده باشد.
 

آیا سیستم کاملاً پاک شده بود؟

در Incident Response بهتر است هیچ‌وقت فقط با دیدن حذف یک فایل بگوییم:

سیستم 100٪ پاک است.

چون ممکن است Malware:

• فایل دیگری ایجاد کرده باشد،
• Persistence دیگری داشته باشد،
• فایل‌های اجرایی دیگری را تغییر داده باشد،
•  Scheduled Task ایجاد کرده باشد،
•  Service ایجاد کرده باشد،
•  Startup دیگری داشته باشد،
• یا در بخش دیگری از سیستم باقی مانده باشد.

اما در محدوده IOC هایی که در این Investigation شناسایی و بررسی شدند، موارد اصلی پاک‌سازی شدند.
 

مهم‌ترین Chain of Evidence

اگر بخواهم کل Incident را به یک زنجیره تبدیل کنم، ساختار آن تقریباً این بود:

مشاهده رفتار غیر عادی ←EXE ها درست اجرا نمی شوند←بررسی File Association←exefile←svchost.com←پیدا شدن C:\Windows\svchost.com←Unsigned←SHA-256 ثبت شد←Defender Detection←Virus:Win32/Neshta.C←بررسی Persistence←Temp\3582-490←IDMan.exe مشکوک←HashMismatch←IDMan.exe از Temp در حال اجرا ←Run Key←پاک سازی IOC ها←اصلاح Registry←بررسی مجدد←Recovery

این Chain در واقع مهم‌ترین بخش کل Write-up است.
 

چرا اسم svchost انتخاب شده بود؟

یکی از نکات جالب از نظر تحلیل Malware، مفهوم  Masqueradingاست.

 Masquerading یعنی یک فایل یا Process طوری نام‌گذاری یا قرار داده شود که شبیه یک مؤلفه معتبر به نظر برسد.

مثلاً:

svchost.exe

یک فایل/Process واقعی Windows است.

ولی:

svchost.com

چیز دیگری است.

کاربر عادی ممکن است به قسمت  .com توجه نکند.

همین تکنیک را می‌توان با نام‌های دیگری مثل:

explorer

winlogon

services

lsass

csrss

نیز تصور کرد.

بنابراین در Threat Hunting: 

 Filename به‌تنهایی Evidence کافی نیست.
 

چرا مسیر فایل مهم‌تر از نام آن است؟

فرض کنیم دو فایل داریم:

C:\Windows\System32\svchost.exe

و:

C:\Users\<USER>\AppData\Local\Temp\svchost.exe

اسم یکسان است.

اما Context کاملاً متفاوت است.

به همین دلیل یک Rule خوب برای تشخیص رفتار مشکوک باید ترکیبی از:

Filename

Path

Hash

Signature

Parent Process

Command Line

User

را در نظر بگیرد.
 

تفاوت NotSigned و HashMismatch

این دو مورد را نباید با هم اشتباه گرفت.

NotSigned

یعنی فایل Digital Signature معتبر ندارد.

مثلاً:

Status:

NotSigned

این موضوع به‌تنهایی Malware بودن فایل را اثبات نمی‌کند.
 

HashMismatch

یعنی فایل دارای Signature بوده، اما محتوای فعلی فایل با اطلاعات امضا مطابقت ندارد.

Status:

HashMismatch

این وضعیت بسیار مهم‌تر است و می‌تواند نشانه تغییر فایل باشد.
 

چرا MicrosoftEdgeUpdate.exe الزاماً Malware نبود؟

در بررسی یک فایل:

MicrosoftEdgeUpdate.exe

داخل Temp نیز مشاهده شد.

اما Signature آن بررسی شد و نتیجه:

Status:Valid

بود.

 Certificate نیز متعلق به:

Microsoft Corporation

بود.

بنابراین برخلاف  svchost.com نمی‌توانستیم صرفاً به خاطر قرار گرفتن در Temp آن را Malware اعلام کنیم.

این یک نکته مهم در Incident Response است:

هر چیزی که در Temp است Malware نیست.
 

دلیل اهمیت زمان ایجاد فایل‌ها

Timestampها نیز Evidence مهمی بودند.

برای مثال:

svchost.com

CreationTime:

2026-08-28 08:49

و:

directx.sys

CreationTime:

2026-08-27 15:06

و فایل‌های Temp نیز در بازه زمانی مشابهی ایجاد شده بودند.

وقتی Timestamp چند Artifact در یک بازه زمانی نزدیک قرار می‌گیرد، می‌توان آن‌ها را از نظر Timeline با یکدیگر مقایسه کرد.

Timeline می‌تواند کمک کند بفهمیم:

• اول چه چیزی ایجاد شد؟
• بعد چه چیزی تغییر کرد؟
• چه چیزی اجرا شد؟
• چه چیزی Persistence ایجاد کرد؟
• چه زمانی Defender Detection داد؟

سیستم رو فورمت کنیم ؟

خیر.

اگر:

• تعداد فایل‌های آلوده زیاد باشد،
• احتمال File Infector بالا باشد،
• Integrity سیستم‌عامل قابل اعتماد نباشد،
• Malware ناشناخته باشد،
• Persistenceهای متعدد پیدا شوند،
• یا سطح اطمینان کافی نباشد،

 Clean Installation می‌تواند امن‌ترین تصمیم باشد.

خصوصاً در مواردی که احتمال می‌دهیم Malware تعداد زیادی executable را تغییر داده باشد.

نتیجه نهایی Investigation

در پایان Investigation چند Artifact کلیدی شناسایی شدند:

IOC شماره 1

 IOCشماره 2

IOC شماره 3

IOC شماره 4

Persistence

Run Key مربوط به:

IDMan.exe /onboot

از مسیر Temp.

چک‌لیست پیشنهادی برای موارد مشابه

اگر دوباره با چنین شرایطی مواجه شدم، این ترتیب برای من منطقی‌تر است:

ثبت علائم اولیه←جلوگیری از تغییرات غیر ضروری←بررسی Defender Detection←پیدا کردن فایل مشکوک←Hash←Digital Signature←Path←Creation/Modification Time←Process←Parent Process←Command Line←Registry Persistence←Startup←Scheduled Tasks←Services←بررسی Copy های دیگر IOC←Remediation←اصلاح Registry←Defender Scan←Validation

محدودیت مهم

با وجود پاک‌سازی موفق IOCهای شناسایی‌شده، از نظر حرفه‌ای نمی‌توان صرفاً با این شواهد ادعا کرد:

هیچ فایل آلوده دیگری روی سیستم وجود ندارد.

به‌خصوص در مورد Malware هایی که قابلیت تغییر فایل‌های اجرایی دارند، سطح اطمینان کامل فقط با بررسی جامع یا در موارد خاص با نصب مجدد سیستم‌عامل حاصل می‌شود.

به همین دلیل بهتر است نتیجه Incident به شکل زیر نوشته شود:

IOCهای شناسایی‌شده و مکانیزم‌های Persistence و Registry Modification مرتبط با آن‌ها شناسایی و Remediate شدند.

Disclaimer:

این مستند بر اساس تجربه عملی و بررسی انجام‌شده روی یک نمونه واقعی از آلودگی تهیه شده است و صرفاً جنبه آموزشی و تجربی دارد. مطالب و دستورات ارائه‌شده لزوماً یک مستند رسمی یا راهکار جامع برای تمامی نمونه‌های مشابه نیستند و ممکن است بسته به سیستم‌عامل، نحوه آلودگی و شرایط محیطی نیاز به تغییر یا تکمیل داشته باشند. برای بررسی و Incident Response در محیط‌های عملیاتی، توصیه می‌شود نتایج این مستند در کنار مستندات رسمی Microsoft و سایر منابع معتبر امنیتی مورد استفاده قرار گیرد.

با تشکر از همراهی شما