امنیت

بررسی Persistence در ویندوز

بررسی Persistence در ویندوز

شناسایی روش‌های ماندگاری مهاجم

مقدمه

در یک Incident امنیتی، دسترسی اولیه مهاجم همیشه موقتی باقی نمی‌ماند.

بعد از دسترسی به Windows Server یا Windows Client ممکن است مهاجم تلاش کند مکانیزمی ایجاد کند که بعد از:

  • Restart سیستم
  • Logoff کاربر
  • بسته شدن Session
  • Terminate شدن Process
  • تغییر Password
  • قطع ارتباط اولیه

دوباره کد یا ابزار موردنظرش اجرا شود.

به این روش‌ها:

Persistence

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

در Windows مکانیزم‌های مختلفی می‌توانند به‌صورت قانونی برای اجرای خودکار برنامه‌ها استفاده شوند و همین قابلیت‌ها ممکن است مورد سوءاستفاده قرار بگیرند؛ از جمله:

Scheduled Tasks
Windows Services
Run / RunOnce Registry Keys
Startup Folders
Winlogon
WMI Event Subscriptions
PowerShell Profiles
Local Users
Administrator Membership

MITRE ATT&CK نیز Scheduled Task، Windows Service، Registry Run Keys، Startup Folder، Winlogon و WMI Event Subscription را در میان تکنیک‌هایی قرار می‌دهد که می‌توانند برای Persistence مورد سوءاستفاده قرار گیرند.

در این مقاله روش بررسی این نقاط را با استفاده از PowerShell، CMD، Event Viewer، Registry، Sysmon و Autoruns بررسی می‌کنیم.

هدف این مقاله شناسایی Persistence و Incident Response روی سیستم‌های تحت مدیریت شما است و شامل آموزش ایجاد Persistence نیست.

Persistence چیست؟

فرض کنید مهاجم از طریق یک Vulnerability، Credential سرقت‌شده یا RDP وارد Server شده باشد.

دسترسی اولیه ممکن است فقط تا زمانی که Session فعال است باقی بماند:

Initial Access
     |
     v
Temporary Session

در صورت Restart شدن Server ممکن است آن دسترسی از بین برود.

بنابراین یک Persistence Mechanism می‌تواند ساختاری مانند زیر ایجاد کند:

Initial Access
     |
     v
Persistence
     |
     v
Automatic Execution
     |
     v
Access After Reboot / Logon

هدف Investigation این است که تمام نقاطی که می‌توانند اجرای خودکار یا دسترسی مجدد ایجاد کنند بررسی شوند.

آیا هر Persistence Mechanism مخرب است؟

خیر.

همین قابلیت‌ها توسط Windows و نرم‌افزارهای قانونی استفاده می‌شوند.

برای مثال:

Windows Update
Backup Software
Monitoring Agent
Antivirus
Database Services
Application Updater

ممکن است Service، Task یا Startup Entry داشته باشند.

بنابراین معیار اصلی این نیست که یک Scheduled Task یا Service وجود دارد.

باید مشخص شود:

Who created it?
When?
What does it execute?
From which path?
Under which account?
Is it documented?
Is it digitally signed?

قبل از تغییر چیزی Evidence جمع‌آوری کنید

اگر احتمال Incident واقعی وجود دارد، بلافاصله Service، Task یا Registry Entry را حذف نکنید.

ابتدا اطلاعات مربوط به آن را ثبت کنید.

برای یک فایل مشکوک:

Get-Item "C:\Path\Suspicious.exe" |
Format-List *

سپس Hash:

Get-FileHash `
"C:\Path\Suspicious.exe" `
-Algorithm SHA256

Signature:

Get-AuthenticodeSignature `
"C:\Path\Suspicious.exe"

و اطلاعات Version:

(Get-Item "C:\Path\Suspicious.exe").VersionInfo

این اطلاعات در Incident Response بسیار ارزشمند هستند.

مرحله اول: بررسی Scheduled Taskها

Task Scheduler یکی از اولین نقاطی است که باید بررسی شود.

برای مشاهده تمام Scheduled Taskهای سیستم:

Get-ScheduledTask

Get-ScheduledTask تعریف Taskهای ثبت‌شده روی سیستم محلی را نمایش می‌دهد.

برای خروجی کاربردی‌تر:

Get-ScheduledTask |
Select-Object TaskName,
              TaskPath,
              State,
              Author,
              @{Name="RunAs";Expression={$_.Principal.UserId}}

Action هر Scheduled Task را بررسی کنیم

مهم‌ترین قسمت Task این است که چه چیزی اجرا می‌کند.

Get-ScheduledTask |
ForEach-Object {

    $Task = $_

    foreach ($Action in $Task.Actions) {

        [PSCustomObject]@{
            TaskName  = $Task.TaskName
            TaskPath  = $Task.TaskPath
            Execute   = $Action.Execute
            Arguments = $Action.Arguments
            RunAs     = $Task.Principal.UserId
        }

    }
}

اکنون می‌توانید Command واقعی مربوط به هر Task را مشاهده کنید.

چه Taskهایی بیشتر نیازمند بررسی هستند؟

مواردی مانند:

powershell.exe
pwsh.exe
cmd.exe
wscript.exe
cscript.exe
mshta.exe
rundll32.exe

اگر در Task ناشناخته استفاده شده باشند، باید بررسی شوند.

همچنین مسیرهایی مانند:

C:\Users\<User>\AppData\
C:\Users\Public\
C:\ProgramData\
C:\Temp\
C:\Windows\Temp\

اگر Executable ناشناس از آنها اجرا شود، ارزش Investigation بیشتری دارند.

وجود این موارد به‌تنهایی نشانه Compromise نیست.

Taskهای مخفی را بررسی کنیم

هر Scheduled Task دارای Propertyهایی است.

برای مثال:

Get-ScheduledTask |
Where-Object {
    $_.Settings.Hidden -eq $true
} |
Select-Object TaskName,TaskPath,State

بعضی Taskهای قانونی نیز Hidden هستند.

بنابراین Task مخفی باید با Baseline سیستم مقایسه شود.

اطلاعات اجرای Scheduled Task

برای مشاهده زمان آخرین اجرا:

Get-ScheduledTask |
Get-ScheduledTaskInfo |
Select-Object TaskName,
              LastRunTime,
              LastTaskResult,
              NextRunTime

این اطلاعات در Timeline Incident مفید است.

Event ID 4698 چیست؟

اگر Audit Policy مناسب فعال باشد، ایجاد Scheduled Task می‌تواند Event:

4698

در Security Log ایجاد کند.

Microsoft Event 4698 را:

A scheduled task was created

تعریف می‌کند و Monitoring ایجاد Taskها را به‌خصوص روی سیستم‌های حساس توصیه می‌کند.

برای مشاهده:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4698
} -MaxEvents 50

Eventهای مهم Scheduled Task

در صورت فعال بودن Audit مناسب:

4698 = Task Created
4699 = Task Deleted
4700 = Task Enabled
4701 = Task Disabled
4702 = Task Updated

این Eventها تحت Audit Other Object Access Events قرار می‌گیرند.

برای بررسی همزمان:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4698,4699,4700,4701,4702
} -MaxEvents 100 |
Select-Object TimeCreated,Id,Message

مرحله دوم: بررسی Windows Services

Serviceها یکی از مهم‌ترین نقاط Persistence در Windows هستند.

Windows Service می‌تواند در Startup سیستم اجرا شود و بدون Login کاربر در Background فعالیت کند.

MITRE ATT&CK نیز ایجاد یا تغییر Windows Service را یکی از تکنیک‌های رایج Persistence معرفی می‌کند.

ابتدا Serviceها را مشاهده کنید:

Get-Service

اما Get-Service مسیر Executable را نمایش نمی‌دهد.

برای Investigation بهتر است از:

Get-CimInstance Win32_Service

استفاده کنیم.

Microsoft نیز برای دریافت اطلاعات Serviceها از Win32_Service استفاده می‌کند.

نمایش اطلاعات مهم Serviceها

Get-CimInstance Win32_Service |
Select-Object Name,
              DisplayName,
              State,
              StartMode,
              StartName,
              PathName

به‌خصوص ستون‌های:

StartMode
StartName
PathName

اهمیت دارند.

Serviceهای Auto Start را بررسی کنیم

Get-CimInstance Win32_Service |
Where-Object {
    $_.StartMode -eq "Auto"
} |
Select-Object Name,
              State,
              StartName,
              PathName

هر Service با Auto Start باید Purpose مشخصی داشته باشد.

Serviceهای مشکوک چه ویژگی‌هایی دارند؟

برای مثال ترکیب زیر نیازمند بررسی است:

Unknown Service
+
Auto Start
+
LocalSystem
+
Executable in AppData

یا:

Generic Service Name
+
Unsigned Executable
+
Recently Created

نام Service معیار قابل اعتمادی نیست.

مثلاً نامی مانند:

WindowsUpdateHelper
SystemMonitor
SecurityAgent

ممکن است قانونی یا صرفاً Masquerading باشد.

مسیر Service را بررسی کنیم

فرض کنیم Service موردنظر:

ExampleService

است.

Get-CimInstance Win32_Service |
Where-Object {
    $_.Name -eq "ExampleService"
} |
Format-List *

سپس Executable را بررسی کنید.

Get-Item "C:\Path\Service.exe" |
Format-List *

Hash:

Get-FileHash `
"C:\Path\Service.exe" `
-Algorithm SHA256

Signature:

Get-AuthenticodeSignature `
"C:\Path\Service.exe"

Event ID 7045

وقتی Service جدیدی روی سیستم Install شود، Service Control Manager می‌تواند Event:

7045

در System Log ثبت کند.

Microsoft Event 7045 را با عبارت:

A service was installed in the system

نمایش می‌دهد و Event شامل Service Name، File Name، Start Type و Service Account است.

برای مشاهده:

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7045
} -MaxEvents 50 |
Select-Object TimeCreated,Message

Event ID 4697

Security Auditing نیز Event:

4697

را برای تلاش جهت Install کردن Service در اختیار دارد و Microsoft آن را در فهرست Eventهای قابل مانیتور Security قرار داده است.

برای بررسی:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4697
} -MaxEvents 50

وجود Event به Audit Policy سیستم بستگی دارد.

مرحله سوم: بررسی Registry Run و RunOnce

Windows دارای Registry Keyهایی است که برای اجرای Program هنگام Login استفاده می‌شوند.

چهار مسیر اصلی عبارت‌اند از:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Microsoft توضیح می‌دهد که Run در هر Login اجرا می‌شود و RunOnce برای اجرای یک‌باره استفاده می‌شود.

بررسی Run Key با PowerShell

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"

سپس:

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

RunOnce:

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce"

و:

Get-ItemProperty `
"HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce"

نسخه 32 بیتی Registry را فراموش نکنید

روی Windows 64-bit بعضی Applicationهای 32-bit ممکن است Entryهای خود را در:

HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

قرار دهند.

بررسی:

Get-ItemProperty `
"HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run" `
-ErrorAction SilentlyContinue

Run Entry مشکوک چه ویژگی‌هایی دارد؟

مواردی مانند:

Unknown Value Name
+
Executable in AppData

یا:

System-like Name
+
Unsigned Binary

یا:

PowerShell / Script Interpreter
+
Unexpected Script

باید بررسی شوند.

MITRE نیز Registry Run Keys و Startup Folder را از نقاط شناخته‌شده Autostart و Persistence در Windows طبقه‌بندی می‌کند.

Registry Entry را حذف نکنید

اگر Entry ناشناخته مشاهده کردید، ابتدا آن را Export یا ثبت کنید.

برای مثال:

reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run"

سپس:

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" |
Format-List *

و فایل اشاره‌شده را بررسی کنید.

مرحله چهارم: بررسی Startup Folder

برنامه‌های موجود در Startup Folder نیز هنگام Login اجرا می‌شوند و MITRE این مکانیزم را همراه با Registry Run Keys در T1547.001 قرار می‌دهد.

Startup Folder کاربر:

C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Startup Folder مشترک:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Startup کاربر فعلی را بررسی کنیم

Get-ChildItem `
"$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" `
-Force

Startup عمومی:

Get-ChildItem `
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp" `
-Force

Startup Folder تمام کاربران

Get-ChildItem `
"C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup" `
-Force `
-ErrorAction SilentlyContinue

به فایل‌های:

.exe
.bat
.cmd
.vbs
.ps1
.lnk

توجه کنید.

اما وجود آنها به‌تنهایی مخرب نیست.

Shortcutها را جدی بگیرید

فایل:

.lnk

ممکن است نام کاملاً عادی داشته باشد اما Target دیگری اجرا کند.

برای بررسی Shortcut می‌توان از PowerShell و WScript Shell به‌صورت Read-only استفاده کرد:

$Shell = New-Object -ComObject WScript.Shell

$Shortcut = $Shell.CreateShortcut(
    "C:\Path\Example.lnk"
)

$Shortcut.TargetPath
$Shortcut.Arguments

Target و Arguments را با Application مورد انتظار مقایسه کنید.

مرحله پنجم: بررسی Winlogon

Winlogon یکی دیگر از نقاط حساس Windows است.

MITRE توضیح می‌دهد که Registry مربوط به Winlogon می‌تواند برای اجرای DLL یا Executable در زمان Login مورد سوءاستفاده قرار گیرد.

مسیر اصلی:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

بررسی:

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" |
Select-Object Shell,Userinit

Shell و Userinit

روی سیستم معمولی معمولاً باید مقادیر این بخش با Baseline استاندارد Windows مطابقت داشته باشند.

دو Property مهم:

Shell
Userinit

هستند.

MITRE به‌طور مشخص Shell و Userinit را از قسمت‌هایی معرفی می‌کند که تغییر آنها می‌تواند باعث اجرای مجدد کد در Login شود.

هر مسیر اضافی یا Executable ناشناس باید بررسی شود.

HKCU Winlogon را نیز بررسی کنیم

Get-ItemProperty `
"HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" `
-ErrorAction SilentlyContinue

وجود Configuration غیرمنتظره در User Scope نیز باید Investigation شود.

مرحله ششم: بررسی WMI Persistence

Windows Management Instrumentation یا:

WMI

می‌تواند Event Subscription دائمی ایجاد کند.

Microsoft توضیح می‌دهد Permanent WMI Consumerها می‌توانند بعد از Restart سیستم نیز باقی بمانند.

MITRE نیز WMI Event Subscription را یک تکنیک Persistence معرفی می‌کند.

یک WMI Subscription معمولاً از سه قسمت تشکیل می‌شود:

Event Filter
Consumer
Binding

WMI Event Filterها را بررسی کنیم

Get-CimInstance `
-Namespace root\subscription `
-ClassName __EventFilter

به Propertyهایی مانند:

Name
Query
EventNamespace

توجه کنید.

CommandLine Event Consumerها

Get-CimInstance `
-Namespace root\subscription `
-ClassName CommandLineEventConsumer

موارد مهم:

Name
CommandLineTemplate
ExecutablePath

اگر Consumer ناشناخته Command یا Script اجرا می‌کند، باید بررسی شود.

ActiveScript Event Consumerها

Get-CimInstance `
-Namespace root\subscription `
-ClassName ActiveScriptEventConsumer

وجود Script Consumer ناشناخته روی Server باید با Configuration سازمان مقایسه شود.

Bindingها را بررسی کنیم

Get-CimInstance `
-Namespace root\subscription `
-ClassName __FilterToConsumerBinding

Binding مشخص می‌کند کدام Filter به کدام Consumer متصل شده است.

برای Investigation باید هر سه قسمت:

Filter
Consumer
Binding

با یکدیگر بررسی شوند.

Sysmon و WMI Persistence

اگر Sysmon از قبل نصب و Config شده باشد، Eventهای:

19 = WMI Event Filter
20 = WMI Event Consumer
21 = WMI Filter-to-Consumer Binding

می‌توانند WMI Registration را ثبت کنند.

مستندات فعلی Microsoft این Eventها را مشخصاً برای WMI و تشخیص Persistence و Fileless Activity معرفی می‌کنند.

برای بررسی:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-Sysmon/Operational'
    Id=19,20,21
} -MaxEvents 100 |
Select-Object TimeCreated,Id,Message

مرحله هفتم: بررسی PowerShell Profile

PowerShell می‌تواند در زمان شروع Session فایل‌های Profile را Load کند.

Microsoft برای PowerShell چند Profile مختلف در سطح User و All Users تعریف می‌کند.

برای مشاهده Profile مربوط به Session فعلی:

$PROFILE

برای مشاهده تمام Profile Pathها:

$PROFILE | Format-List *

آیا Profile وجود دارد؟

Test-Path $PROFILE

اگر وجود دارد:

Get-Item $PROFILE |
Format-List *

و برای مشاهده محتوا:

Get-Content $PROFILE

Profileهای مختلف PowerShell

$PROFILE.AllUsersAllHosts
$PROFILE.AllUsersCurrentHost
$PROFILE.CurrentUserAllHosts
$PROFILE.CurrentUserCurrentHost

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

PowerShell 5 و PowerShell 7

روی یک Server ممکن است هر دو نسخه وجود داشته باشند:

Windows PowerShell
PowerShell 7

و Profile Pathهای آنها الزاماً یکسان نیست.

بنابراین فقط Profile مربوط به Shell فعلی را بررسی نکنید.

در PowerShell Profile دنبال چه چیزی بگردیم؟

موارد غیرمنتظره مانند:

Execution of unknown script
External download
Hidden process
Unknown module import
Encoded command
Executable from AppData

باید Investigation شوند.

همچنین Timestamp فایل:

Get-Item $PROFILE |
Select-Object FullName,
              CreationTime,
              LastWriteTime

می‌تواند برای Timeline مفید باشد.

مرحله هشتم: بررسی Local Userها

Persistence الزاماً به معنی اجرای خودکار Program نیست.

ممکن است Account جدیدی ایجاد شده باشد.

برای مشاهده Local Userها:

Get-LocalUser

خروجی کاربردی‌تر:

Get-LocalUser |
Select-Object Name,
              Enabled,
              LastLogon,
              PasswordLastSet,
              SID

Accountهای فعال ناشناخته باید بررسی شوند.

Administratorها را بررسی کنیم

Get-LocalGroupMember Administrators |
Select-Object Name,
              ObjectClass,
              PrincipalSource

وجود:

Unknown Local User
Unknown Domain User
Unexpected Domain Group

در Administrators می‌تواند Persistence از طریق Account باشد.

Built-in Administrator

حتی اگر Rename شده باشد می‌توان آن را براساس SID با RID:

500

پیدا کرد.

Get-LocalUser |
Where-Object {
    $_.SID.Value -match '-500$'
}

Eventهای Account Management

در Investigation کاربران، Eventهای زیر مفیدند:

4720 = User Created
4722 = User Enabled
4725 = User Disabled
4726 = User Deleted
4732 = Member Added to Local Security Group
4738 = User Changed

مثلاً:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4720,4722,4725,4726,4732,4738
} -MaxEvents 100 |
Select-Object TimeCreated,Id,Message

مرحله نهم: بررسی Autoruns

یکی از بهترین ابزارهای Microsoft برای بررسی Autostart Locationهای Windows:

Autoruns

از مجموعه Sysinternals است.

Microsoft توضیح می‌دهد Autoruns تعداد زیادی از نقاط اجرای خودکار Windows را نمایش می‌دهد، از جمله:

  • Startup Folder
  • Run
  • RunOnce
  • Services
  • Scheduled Tasks
  • Winlogon
  • WMI
  • Explorer Extensions
  • Drivers

و سایر Autostart Locationها.

چرا Autoruns مفید است؟

به‌جای بررسی دستی ده‌ها Registry Path و Folder می‌توان بسیاری از آنها را در یک Interface مشاهده کرد.

Tabهای مهم برای Investigation عبارت‌اند از:

Logon
Scheduled Tasks
Services
Drivers
WMI
Winlogon

Hide Microsoft Entries

Autoruns گزینه:

Hide Signed Microsoft Entries

دارد که می‌تواند تمرکز Investigation را روی Third-party Autostart Entryها بیشتر کند.

اما:

Signed بودن یا Microsoft نبودن به‌تنهایی معیار سالم یا مخرب بودن نیست.

Autoruns باید برای کاهش Noise استفاده شود، نه نتیجه‌گیری قطعی.

Autorunsc

نسخه Command Line این ابزار:

Autorunsc

است.

Microsoft اعلام می‌کند Autorunsc می‌تواند خروجی را به CSV یا XML تبدیل کند و مواردی مانند Hash و Signature Verification را نیز نمایش دهد.

این قابلیت برای Incident Response و مقایسه Baseline بسیار مفید است.

مرحله دهم: بررسی Registry با Sysmon

اگر Sysmon به‌درستی Config شده باشد، تغییرات Registry نیز قابل مانیتور هستند.

MITRE در Detection Strategy مرتبط با Registry Startup Persistence به Eventهای Registry و Process Creation Sysmon برای Correlation اشاره می‌کند.

برای بررسی Eventهای Registry:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-Sysmon/Operational'
    Id=12,13,14
} -MaxEvents 200

بسته به Configuration Sysmon ممکن است:

Registry Key Create/Delete
Registry Value Set
Registry Key/Value Rename

ثبت شود.

Eventها را با Process Creation ترکیب کنید

یک Registry Entry به‌تنهایی کافی نیست.

مثلاً اگر:

Run Key modified

و کمی بعد:

Unknown.exe executed

را مشاهده کنید، Evidence قوی‌تری دارید.

Sysmon Event:

1

برای Process Creation کاربرد دارد.

بنابراین Correlation:

Registry Modification
       |
       v
Process Execution

اهمیت زیادی دارد.

مرحله یازدهم: Processهای فعال را بررسی کنیم

Persistence در نهایت معمولاً Processی را اجرا می‌کند.

برای مشاهده:

Get-Process

برای اطلاعات بهتر:

Get-CimInstance Win32_Process |
Select-Object ProcessId,
              ParentProcessId,
              Name,
              ExecutablePath,
              CommandLine

به‌خصوص:

ParentProcessId
ExecutablePath
CommandLine

را بررسی کنید.

Process Tree چرا مهم است؟

فرض کنید یک Executable ناشناس از Startup اجرا شده است.

ممکن است ساختار:

explorer.exe
     |
     v
unknown.exe

دیده شود.

یا Service:

services.exe
     |
     v
unknown.exe

یا Scheduled Task:

taskeng / taskhost
     |
     v
powershell.exe

Parent Process می‌تواند به تشخیص Persistence Mechanism کمک کند.

Network Connectionها را بررسی کنیم

یک Persistence ممکن است بعد از اجرا Connection خارجی ایجاد کند.

Get-NetTCPConnection -State Established

برای نمایش Process:

Get-NetTCPConnection -State Established |
Select-Object RemoteAddress,
              RemotePort,
              OwningProcess,
              @{Name="Process";Expression={
                  (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName
              }}

اگر Service یا Task ناشناخته به Destination خارجی غیرمنتظره متصل شده باشد، Investigation اهمیت بیشتری پیدا می‌کند.

فایل‌های جدید در مسیرهای حساس

مسیرهایی مانند:

C:\ProgramData
C:\Users\Public
C:\Windows\Temp
C:\Users\<User>\AppData

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

برای مثال فایل‌های هفت روز اخیر:

Get-ChildItem C:\ProgramData -File -Recurse -ErrorAction SilentlyContinue |
Where-Object {
    $_.LastWriteTime -gt (Get-Date).AddDays(-7)
} |
Select-Object FullName,
              Length,
              CreationTime,
              LastWriteTime

روی Serverهای بزرگ جستجوی Recursive می‌تواند زمان‌بر باشد؛ بازه و مسیر را براساس Incident محدود کنید.

یک Workflow عملی برای بررسی Persistence

فرض کنیم روی یک Windows Server احتمال Compromise وجود دارد.

مرحله اول: Processها

Get-CimInstance Win32_Process |
Select ProcessId,
       ParentProcessId,
       Name,
       ExecutablePath,
       CommandLine

مرحله دوم: Network

Get-NetTCPConnection -State Established

مرحله سوم: Scheduled Tasks

Get-ScheduledTask

و:

Get-ScheduledTask |
ForEach-Object {
    [PSCustomObject]@{
        TaskName = $_.TaskName
        TaskPath = $_.TaskPath
        RunAs    = $_.Principal.UserId
        Action   = ($_.Actions.Execute -join ',')
        Args     = ($_.Actions.Arguments -join ',')
    }
}

مرحله چهارم: Services

Get-CimInstance Win32_Service |
Select Name,
       State,
       StartMode,
       StartName,
       PathName

مرحله پنجم: Run Keys

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

مرحله ششم: Startup Folder

Get-ChildItem `
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp" `
-Force

مرحله هفتم: Winlogon

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" |
Select Shell,Userinit

مرحله هشتم: WMI

Get-CimInstance `
-Namespace root\subscription `
-ClassName __EventFilter
Get-CimInstance `
-Namespace root\subscription `
-ClassName CommandLineEventConsumer
Get-CimInstance `
-Namespace root\subscription `
-ClassName __FilterToConsumerBinding

مرحله نهم: PowerShell Profile

$PROFILE | Format-List *

مرحله دهم: Userها و Administratorها

Get-LocalUser
Get-LocalGroupMember Administrators

مرحله یازدهم: Eventها

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4698,4702,4697,4720,4732
} -MaxEvents 100

و:

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7045
} -MaxEvents 50

یک Audit اولیه با PowerShell

برای بررسی سریع چند نقطه اصلی:

Write-Host "`n=== SCHEDULED TASKS ==="

Get-ScheduledTask |
Select TaskName,
       TaskPath,
       State,
       @{N='RunAs';E={$_.Principal.UserId}}


Write-Host "`n=== AUTO START SERVICES ==="

Get-CimInstance Win32_Service |
Where-Object {
    $_.StartMode -eq 'Auto'
} |
Select Name,
       State,
       StartName,
       PathName


Write-Host "`n=== HKLM RUN ==="

Get-ItemProperty `
"HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" `
-ErrorAction SilentlyContinue


Write-Host "`n=== STARTUP FOLDER ==="

Get-ChildItem `
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp" `
-Force `
-ErrorAction SilentlyContinue


Write-Host "`n=== LOCAL ADMINS ==="

Get-LocalGroupMember Administrators |
Select Name,
       ObjectClass,
       PrincipalSource

این Script هیچ Persistence Mechanism جدیدی ایجاد نمی‌کند و فقط Inventory اولیه انجام می‌دهد.

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

مثلاً:

New Scheduled Task
+
PowerShell
+
Runs as SYSTEM
+
Unknown Script

یا:

New Service
+
Auto Start
+
Unsigned Executable
+
AppData Path

یا:

Run Registry Entry
+
Recently Created EXE
+
External Network Connection

یا:

WMI Consumer
+
Unknown Command
+
Sysmon Events 19/20/21

یا:

Unknown Local User
+
Administrators Membership
+
Recent RDP Login

یک Indicator به‌تنهایی معمولاً برای نتیجه‌گیری کافی نیست.

Persistence مشکوک پیدا کردیم؛ چه کنیم؟

فوراً آن را Delete نکنید.

ابتدا ثبت کنید:

Name
Path
User
Command Line
Creation Time
Last Write Time
Hash
Digital Signature
Related Logs
Network Connections

اگر فایل وجود دارد:

Get-FileHash `
"C:\Path\File.exe" `
-Algorithm SHA256

و:

Get-AuthenticodeSignature `
"C:\Path\File.exe"

Export کردن Scheduled Task مشکوک

می‌توانید اطلاعات Task را قبل از تغییر ذخیره کنید.

برای مثال:

Get-ScheduledTask -TaskName "ExampleTask" |
Export-Clixml C:\IR\ExampleTask.xml

همچنین Eventهای مربوط به Task را ذخیره کنید.

اطلاعات Service را ذخیره کنیم

Get-CimInstance Win32_Service |
Where-Object {
    $_.Name -eq "ExampleService"
} |
Export-Clixml C:\IR\ExampleService.xml

Registry Evidence را ثبت کنیم

برای مثال:

reg export "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" C:\IR\HKLM_Run.reg

این کار قبل از Remediation کمک می‌کند وضعیت فعلی Registry حفظ شود.

چرا حذف فوری اشتباه است؟

فرض کنید یک Scheduled Task مشکوک پیدا کرده‌اید.

اگر فوراً Task را حذف کنید ممکن است اطلاعاتی مانند:

Task Action
Arguments
User
Trigger
Creation Context

را از دست بدهید.

هدف Investigation فقط حذف Persistence نیست.

باید مشخص شود:

  • Initial Access چه بوده؟
  • Persistence چه زمانی ایجاد شده؟
  • چه Accountی آن را ایجاد کرده؟
  • Payload از کجا آمده؟
  • Credential دیگری Compromise شده؟
  • سیستم دیگری نیز درگیر است؟
  • چه Network Connectionهایی برقرار شده؟

Root Cause را پیدا کنید

Persistence معمولاً مرحله‌ای بعد از Initial Access است.

Initial Access ممکن است از طریق:

RDP Compromise
Stolen Credentials
Web Vulnerability
Malicious File
Phishing
Vulnerable Service
Remote Management

ایجاد شده باشد.

اگر Persistence حذف شود ولی Root Cause باقی بماند، مهاجم ممکن است دوباره وارد سیستم شود.

Credentialها را بررسی کنید

اگر Administrative Access تأیید شده است، Scope Credential Exposure باید مشخص شود.

ممکن است لازم باشد:

Local Administrator Password
Domain Password
Service Accounts
API Tokens
Database Credentials
Cloud Credentials
Backup Credentials

براساس Incident Response Plan سازمان Rotate شوند.

چه زمانی Rebuild بهتر است؟

اگر مهاجم Administrative یا SYSTEM Access طولانی‌مدت داشته و چند Persistence Mechanism یا دستکاری عمیق مشاهده شده باشد، پاک‌سازی دستی همیشه قابل اعتماد نیست.

در چنین شرایطی ممکن است:

Rebuild from trusted image
+
Restore known-good data
+
Credential rotation

از تلاش برای حذف تک‌تک Persistenceها مطمئن‌تر باشد.

این تصمیم باید براساس Scope Incident و سیاست سازمان گرفته شود.

برای پیشگیری چه کنیم؟

اقدامات مهم عبارت‌اند از:

  • Least Privilege
  • محدود کردن Local Administrator
  • Windows LAPS
  • Microsoft Defender / EDR
  • Sysmon
  • PowerShell Script Block Logging
  • Process Creation Auditing
  • Scheduled Task Auditing
  • Service Installation Monitoring
  • File Integrity Monitoring
  • Application Control
  • Centralized Logging
  • SIEM
  • Patch Management

Baseline بسیار مهم است

یکی از بهترین روش‌های Detection این است که بدانیم حالت عادی Server چیست.

مثلاً Baseline شامل:

Approved Services
Approved Scheduled Tasks
Approved Local Administrators
Approved Run Entries
Approved Startup Programs
Approved WMI Subscriptions

باشد.

در این صورت تغییرات جدید بسیار سریع‌تر مشخص می‌شوند.

Autoruns برای Baseline

می‌توان خروجی Autostartهای سالم Server را در زمان Deploy ثبت کرد.

بعداً در Incident یا Audit خروجی جدید با Baseline مقایسه شود.

Autoruns به دلیل پوشش گسترده Autostart Locationها ابزار مناسبی برای چنین مقایسه‌ای است.

Logها را مرکزی کنید

اگر Log فقط روی Server آلوده وجود داشته باشد، Administrator مهاجم ممکن است آن را حذف یا تغییر دهد.

برای Serverهای مهم بهتر است Logهایی مانند:

Security
System
PowerShell
Sysmon
Defender
Task Scheduler

به SIEM یا Log Server مرکزی ارسال شوند.

اشتباهات رایج

برخی اشتباهات رایج هنگام بررسی Persistence در Windows عبارت‌اند از:

  • بررسی فقط Scheduled Task
  • بررسی نکردن Windows Service
  • نادیده گرفتن Run و RunOnce
  • بررسی نکردن Startup Folder
  • نادیده گرفتن Winlogon
  • بررسی نکردن WMI Subscription
  • بررسی نکردن PowerShell Profile
  • توجه نکردن Local User و Administrator
  • اعتماد به نام Service یا Task
  • حذف فوری Evidence
  • نتیجه‌گیری فقط براساس فایل Unsigned
  • نادیده گرفتن Event ID 4698
  • بررسی نکردن Event ID 7045
  • نادیده گرفتن Sysmon Eventهای WMI
  • بررسی نکردن Network Activity
  • پیدا نکردن Root Cause

بهترین روش‌ها

برای بررسی صحیح Persistence:

  • Scheduled Taskها را Baseline کنید.
  • Action و Arguments هر Task را بررسی کنید.
  • Serviceهای Auto Start را Inventory کنید.
  • Service Pathها را بررسی کنید.
  • Run و RunOnce Registry Keyها را مانیتور کنید.
  • Startup Folder تمام Userها را بررسی کنید.
  • Winlogon Registry را Baseline کنید.
  • WMI Subscriptionها را Audit کنید.
  • PowerShell Profileها را بررسی کنید.
  • Local Administratorها را مستندسازی کنید.
  • Autoruns را برای Audit دوره‌ای استفاده کنید.
  • Sysmon را با Configuration مناسب Deploy کنید.
  • Eventهای امنیتی را مرکزی نگهداری کنید.
  • قبل از Remediation Evidence تهیه کنید.
  • Initial Access را پیدا کنید.

چک‌لیست

برای بررسی Persistence روی Windows Server موارد زیر را کنترل کنید:

  • Processهای فعال بررسی شده‌اند.
  • Network Connectionها بررسی شده‌اند.
  • Scheduled Taskها Inventory شده‌اند.
  • Task Action و Arguments بررسی شده‌اند.
  • Hidden Taskها بررسی شده‌اند.
  • Event ID 4698 بررسی شده است.
  • Event ID 4702 بررسی شده است.
  • Serviceهای Auto Start بررسی شده‌اند.
  • Service Pathها بررسی شده‌اند.
  • Service Accountها بررسی شده‌اند.
  • Event ID 7045 بررسی شده است.
  • Event ID 4697 بررسی شده است.
  • HKLM Run بررسی شده است.
  • HKCU Run بررسی شده است.
  • RunOnce بررسی شده است.
  • WOW6432Node Run بررسی شده است.
  • Startup Folder عمومی بررسی شده است.
  • Startup Folder تمام Userها بررسی شده است.
  • Shortcutهای ناشناس بررسی شده‌اند.
  • Winlogon Shell بررسی شده است.
  • Winlogon Userinit بررسی شده است.
  • WMI Event Filterها بررسی شده‌اند.
  • WMI Consumerها بررسی شده‌اند.
  • WMI Bindingها بررسی شده‌اند.
  • Sysmon Event 19 بررسی شده است.
  • Sysmon Event 20 بررسی شده است.
  • Sysmon Event 21 بررسی شده است.
  • PowerShell Profileها بررسی شده‌اند.
  • Local Userها بررسی شده‌اند.
  • Local Administratorها بررسی شده‌اند.
  • Autoruns بررسی شده است.
  • فایل‌های مشکوک Hash شده‌اند.
  • Digital Signature بررسی شده است.
  • Evidence قبل از حذف حفظ شده است.
  • Root Cause مشخص شده است.

مطالعات بیشتر

برای مطالعه بیشتر درباره Persistence و نقاط Autostart در Windows:

Microsoft Sysinternals – Autoruns
مرجع رسمی Autoruns برای مشاهده Startup، Run/RunOnce، Services، Scheduled Tasks، WMI، Winlogon و سایر Autostart Locationها.
Microsoft Learn – Autoruns

Run and RunOnce Registry Keys
مستندات رسمی Microsoft درباره Registry Keyهای Run و RunOnce.
Microsoft Learn – Run and RunOnce Registry Keys

Get-ScheduledTask
مرجع PowerShell برای مشاهده Scheduled Taskهای ثبت‌شده روی Windows.
Microsoft Learn – Get-ScheduledTask

Sysmon Events
مرجع Eventهای Sysmon از جمله Eventهای WMI، Process و Registry.
Microsoft Learn – Sysmon Events

PowerShell Profiles
مستندات Profileهای مختلف PowerShell در سطح User و System.
Microsoft Learn – about Profiles

MITRE ATT&CK – Persistence
فهرست Techniqueهای مرتبط با حفظ دسترسی در سیستم.
MITRE ATT&CK – Persistence

MITRE ATT&CK – Registry Run Keys / Startup Folder
جزئیات سوءاستفاده از Run Key و Startup Folder برای Persistence.
MITRE ATT&CK – Registry Run Keys / Startup Folder

MITRE ATT&CK – Scheduled Task
اطلاعات مربوط به استفاده از Windows Task Scheduler برای Persistence.
MITRE ATT&CK – Scheduled Task

MITRE ATT&CK – Windows Service
اطلاعات مربوط به ایجاد یا تغییر Service برای Persistence.
MITRE ATT&CK – Windows Service

MITRE ATT&CK – WMI Event Subscription
توضیح WMI Permanent Event Subscription به‌عنوان Persistence Mechanism.
MITRE ATT&CK – WMI Event Subscription

جمع‌بندی

Persistence در Windows محدود به یک Scheduled Task یا Registry Key نیست.

مهاجم می‌تواند از مکانیزم‌های قانونی Windows مانند:

Scheduled Tasks
Services
Run Keys
Startup Folders
Winlogon
WMI
PowerShell Profiles
User Accounts

برای حفظ دسترسی استفاده کند.

برای Scheduled Taskها یکی از بهترین نقاط شروع:

Get-ScheduledTask

است.

برای Serviceها:

Get-CimInstance Win32_Service

اطلاعاتی مانند:

StartMode
StartName
PathName

را در اختیار قرار می‌دهد.

Run Keyها را نیز باید در:

HKLM
HKCU
WOW6432Node

بررسی کرد.

برای Autostartهای Login، Startup Folder و Winlogon اهمیت زیادی دارند.

WMI Persistence نیز نباید نادیده گرفته شود؛ به‌خصوص اگر Sysmon فعال باشد Eventهای:

19
20
21

می‌توانند در شناسایی WMI Event Subscription کمک کنند.

در کنار بررسی دستی، Microsoft Autoruns یکی از کاربردی‌ترین ابزارها برای مشاهده مجموعه بزرگی از Autostart Locationهای Windows است.

اما پیدا کردن یک Task، Service یا Registry Entry ناشناخته به‌تنهایی اثبات Compromise نیست.

باید:

Persistence Entry
+
Executable
+
User
+
Timestamp
+
Process
+
Network
+
Event Logs

در کنار یکدیگر بررسی شوند.

اگر Persistence مشکوکی پیدا شد، ابتدا Evidence را حفظ کنید، سپس Scope حادثه و Initial Access را مشخص کنید و بعد Remediation را انجام دهید.

حذف Persistence بدون پیدا کردن Root Cause ممکن است فقط یکی از نشانه‌های نفوذ را حذف کند و مانع بازگشت مهاجم نشود.

کیان پور

نظرات خود را بنویسید...

اشتراک گذاری این مقاله

بررسی Persistence در ویندوز

کپی کردن لینک

سلام