امنیت

شناسایی Reverse Shell در ویندوز

شناسایی Reverse Shell در ویندوز

مقدمه

یکی از روش‌هایی که ممکن است پس از نفوذ به Windows Server یا Windows Client مشاهده شود، ایجاد Reverse Shell است.

در یک اتصال عادی مدیریتی، مدیر سیستم از سیستم خود به Server متصل می‌شود:

Administrator
      |
      v
Windows Server

اما در Reverse Shell جهت ارتباط برعکس می‌شود.

سیستم آلوده خودش یک Connection خروجی به سیستم دیگری برقرار می‌کند و از طریق همان ارتباط امکان اجرای Command فراهم می‌شود.

به همین دلیل ممکن است:

  • هیچ پورت Listener مشکوکی روی Server وجود نداشته باشد.
  • هیچ RDP Session جدیدی دیده نشود.
  • Firewall ورودی Connection خاصی ثبت نکرده باشد.
  • اما یک Process روی Server به IP خارجی متصل شده باشد.

در این مقاله روش‌های شناسایی Reverse Shell در Windows را با استفاده از PowerShell، netstat، Task Manager، Event Log، Sysmon و Windows Firewall Log بررسی می‌کنیم.

هدف این مقاله شناسایی و پاسخ به فعالیت مشکوک روی سیستم‌های تحت مدیریت خودتان است و شامل آموزش ساخت یا اجرای Reverse Shell نمی‌شود.

Reverse Shell چیست؟

در یک ارتباط عادی Client به Server متصل می‌شود.

برای مثال:

Client
   |
   v
Server:3389

در Reverse Shell معمولاً سیستم مقصد خودش یک Connection خروجی ایجاد می‌کند:

Compromised Windows Server
            |
            | Outbound Connection
            v
       Remote System

سپس یک Process مانند Command Interpreter یا Script Engine می‌تواند Input و Output خود را از طریق همین Connection دریافت و ارسال کند.

همین رفتار باعث می‌شود Reverse Shell در بسیاری از موارد شبیه یک Connection خروجی عادی دیده شود.

چرا شناسایی Reverse Shell دشوار است؟

Windows Server به‌طور طبیعی Connectionهای خروجی زیادی ایجاد می‌کند.

برای مثال:

DNS
Windows Update
Monitoring
Backup
SMTP
Database
API
Cloud Services
Active Directory
Antivirus

بنابراین مشاهده یک Connection خارجی به‌تنهایی به معنی Reverse Shell نیست.

معمولاً باید چند Evidence را کنار هم قرار دهیم:

Network Connection
        +
Owning Process
        +
Parent Process
        +
Command Line
        +
User
        +
Event Logs

هرچه این نشانه‌ها بیشتر با یکدیگر هم‌خوانی داشته باشند، احتمال Incident بیشتر می‌شود.

اولین مرحله: بررسی Connectionهای فعال

در PowerShell می‌توان از:

Get-NetTCPConnection

استفاده کرد.

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

LocalAddress
LocalPort
RemoteAddress
RemotePort
State
OwningProcess

را نمایش می‌دهد. Microsoft نیز Get-NetTCPConnection را برای مشاهده TCP Connectionها و PID مالک Connection ارائه می‌کند.

فقط Connectionهای Established را نمایش دهیم

برای تمرکز روی Connectionهای فعال:

Get-NetTCPConnection -State Established

نمونه خروجی:

LocalAddress LocalPort RemoteAddress   RemotePort State        OwningProcess
------------ --------- -------------   ---------- -----        -------------
10.10.10.20  49722     203.0.113.50    8443       Established  6240

در این مثال:

Local Port:
49722
Remote IP:
203.0.113.50
Remote Port:
8443

و:

PID:
6240

است.

مهم‌ترین اطلاعات برای ادامه Investigation همان:

OwningProcess

است.

نمایش Connectionها به همراه نام Process

برای اینکه مجبور نباشیم هر PID را جداگانه بررسی کنیم:

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

اکنون ممکن است نتیجه‌ای مانند زیر مشاهده کنید:

RemoteAddress   RemotePort   ProcessName   OwningProcess
-------------   ----------   -----------   -------------
203.0.113.50    8443         powershell    6240
198.51.100.25   443          chrome        7712

وجود Connection خارجی برای:

powershell

لزوماً مخرب نیست، اما باید مشخص شود چرا PowerShell چنین Connectionی دارد.

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

Processهایی مانند موارد زیر اگر Connection خارجی غیرمنتظره داشته باشند ارزش بررسی بیشتری دارند:

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

اما:

نام Process به‌تنهایی اثبات فعالیت مخرب نیست.

هر کدام از این برنامه‌ها کاربردهای قانونی نیز دارند.

آنچه اهمیت دارد:

Process
+
Command Line
+
Parent
+
Destination

است.

بررسی Connection با netstat

روش کلاسیک Windows:

netstat -ano

گزینه‌ها:

-a = تمام Connectionها و Listenerها
-n = نمایش IP و Port به‌صورت عددی
-o = نمایش PID

Microsoft نیز برای Troubleshooting شبکه از netstat و PID برای پیدا کردن Process مالک Connection استفاده می‌کند.

برای مشاهده Connectionهای Established:

netstat -ano | findstr ESTABLISHED

نمونه:

TCP    10.10.10.20:49722    203.0.113.50:8443    ESTABLISHED    6240

اکنون PID:

6240

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

پیدا کردن Process از روی PID

در CMD:

tasklist /FI "PID eq 6240"

نمونه:

Image Name                     PID Session Name
========================= ======== ================
powershell.exe                6240 Console

در PowerShell:

Get-Process -Id 6240

این مرحله فقط نام Process را مشخص می‌کند.

برای Investigation واقعی باید اطلاعات بیشتری بگیریم.

بررسی Command Line Process

یکی از مهم‌ترین مراحل بررسی:

Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
Select-Object ProcessId,
              ParentProcessId,
              Name,
              ExecutablePath,
              CommandLine

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

ProcessId       : 6240
ParentProcessId : 4852
Name            : powershell.exe
ExecutablePath  : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine     : powershell.exe ...

در این مرحله به‌خصوص موارد زیر مهم‌اند:

ParentProcessId
ExecutablePath
CommandLine

چرا Parent Process اهمیت دارد؟

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

powershell.exe

است.

اگر Parent آن:

explorer.exe

باشد، ممکن است Administrator از Desktop آن را اجرا کرده باشد.

اگر Parent:

services.exe

باشد، ممکن است توسط Service اجرا شده باشد.

اگر Parent چیزی غیرمنتظره مانند یک Web Server Process یا Script Host باشد، Investigation اهمیت بیشتری پیدا می‌کند.

مشاهده Parent Process

اگر:

ParentProcessId = 4852

باشد:

Get-CimInstance Win32_Process -Filter "ProcessId = 4852" |
Select-Object ProcessId,
              ParentProcessId,
              Name,
              ExecutablePath,
              CommandLine

اکنون می‌توان Process Tree اولیه را ساخت:

Parent Process
      |
      v
powershell.exe
      |
      v
External Connection

یک مثال مشکوک

فرض کنید Connection زیر مشاهده می‌شود:

powershell.exe
      |
      v
203.0.113.50:8443

و Parent آن:

w3wp.exe

باشد.

w3wp.exe مربوط به IIS Worker Process است.

ساختار:

w3wp.exe
   |
   v
powershell.exe
   |
   v
External IP

در بسیاری از Web Serverها رفتار معمولی محسوب نمی‌شود و باید بررسی شود که آیا Web Application عمداً PowerShell اجرا می‌کند یا خیر.

استفاده از Task Manager

برای بررسی سریع GUI:

Ctrl + Shift + Esc

Task Manager را باز کنید.

سپس:

Details

را انتخاب کنید.

ستون‌های زیر مفید هستند:

PID
User name
Command line

اگر Command Line نمایش داده نمی‌شود:

Right Click روی Header
→ Select Columns
→ Command line

را فعال کنید.

برای Investigationهای سریع، Task Manager مفید است؛ اما PowerShell و Event Log اطلاعات دقیق‌تری ارائه می‌دهند.

استفاده از Process Explorer

برای بررسی عمیق‌تر می‌توان از ابزار رسمی Microsoft Sysinternals:

Process Explorer

استفاده کرد.

این ابزار Process Tree، Parent Process، Command Line، User، Handle و سایر اطلاعات Process را به‌صورت گرافیکی نمایش می‌دهد.

در بررسی Processهای مشکوک، مشاهده Parent/Child Relationship بسیار مهم است.

شماره Port به‌تنهایی معیار نیست

یکی از اشتباهات متداول این است که فقط Portهایی مانند:

4444
5555
9001
1337

را مشکوک بدانیم.

Reverse Shell یا هر Connection مخرب می‌تواند از Portهای عادی مانند:

80
443
53

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

از طرف دیگر ممکن است یک Application قانونی روی Port غیرمعمول کار کند.

بنابراین:

Port Number

به‌تنهایی معیار مناسبی برای Detection نیست.

Remote IP را بررسی کنیم

وقتی Connection غیرمنتظره پیدا شد، مشخص کنید Destination چیست.

سؤالات مهم:

  • IP متعلق به Microsoft است؟
  • Monitoring Provider است؟
  • Backup Service است؟
  • Cloud Platform است؟
  • API رسمی Application است؟
  • CDN است؟
  • یا هیچ ارتباطی با سرویس‌های شناخته‌شده ندارد؟

در Serverهای Production بهتر است Baseline مشخصی از Connectionهای خروجی وجود داشته باشد.

ایجاد Baseline برای Connectionهای خروجی

برای مثال یک Server ممکن است در حالت عادی فقط به این Destinationها متصل شود:

DNS
Active Directory
Backup Server
Monitoring
Microsoft Update
Approved APIs

اگر ناگهان Process جدیدی به Destination دیگری متصل شود، بررسی آن ساده‌تر خواهد بود.

بررسی تمام Connectionهای یک PID

اگر PID مشکوک:

6240

است:

Get-NetTCPConnection -OwningProcess 6240

این قابلیت به‌صورت رسمی در Get-NetTCPConnection وجود دارد.

نمونه:

LocalPort    RemoteAddress    RemotePort    State
---------    -------------    ----------    -----
49722        203.0.113.50     8443          Established

بررسی Processهایی که تعداد زیادی Connection دارند

برای مشاهده تعداد Connectionها براساس Process:

Get-NetTCPConnection |
Group-Object OwningProcess |
Sort-Object Count -Descending |
Select-Object Count,
              Name,
              @{Name="Process";Expression={
                  (Get-Process -Id $_.Name -ErrorAction SilentlyContinue).ProcessName
              }}

این روش برای پیدا کردن Processهای دارای Connectionهای غیرعادی مفید است.

بررسی Windows Security Event ID 4688

یکی از مهم‌ترین Eventها برای Investigation:

4688

است.

Event 4688 هنگام ایجاد Process جدید ثبت می‌شود، البته باید Audit Process Creation فعال باشد. Microsoft توضیح می‌دهد که این Event می‌تواند نام Process، Parent Process و در صورت فعال بودن Policy مربوطه Command Line را نیز ثبت کند.

برای مشاهده:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4688
} -MaxEvents 100

جستجوی PowerShell در Event 4688

برای مثال:

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4688
} |
Where-Object {
    $_.Message -match 'powershell.exe|pwsh.exe'
} |
Select-Object TimeCreated,Message

این روش می‌تواند زمان اجرای PowerShell و Process ایجادکننده آن را مشخص کند.

چرا Command Line در Event 4688 خالی است؟

به‌صورت پیش‌فرض ممکن است Event 4688 ایجاد شود اما:

Process Command Line

خالی باشد.

برای ثبت Command Line باید Policy:

Include command line in process creation events

فعال شود. Microsoft تأکید می‌کند این قابلیت به Audit Process Creation وابسته است و به‌صورت پیش‌فرض فعال نیست.

مسیر Group Policy:

Computer Configuration
  → Administrative Templates
    → System
      → Audit Process Creation
        → Include command line in process creation events

هشدار درباره Command Line Logging

Command Line ممکن است شامل اطلاعات حساس باشد:

Password
Token
API Key
Connection String

Microsoft نیز هشدار می‌دهد که با فعال کردن Command Line Logging این اطلاعات ممکن است به‌صورت Plain Text داخل Security Event Log ثبت شوند.

بنابراین دسترسی به Security Log باید محدود باشد.

بررسی PowerShell Event ID 4104

اگر Activity مشکوک مربوط به PowerShell باشد، Event:

4104

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

در صورت فعال بودن Script Block Logging، PowerShell محتوای Script Blockهایی را که پردازش می‌کند در:

Microsoft-Windows-PowerShell/Operational

ثبت می‌کند.

برای مشاهده:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-PowerShell/Operational'
    Id=4104
} -MaxEvents 100

جستجوی Scriptهای مشکوک

می‌توان Eventها را براساس Keyword بررسی کرد:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-PowerShell/Operational'
    Id=4104
} |
Where-Object {
    $_.Message -match 'TcpClient|WebClient|Invoke-WebRequest|Net.Sockets'
}

وجود چنین Keywordهایی به‌تنهایی اثبات Reverse Shell نیست.

ممکن است Script قانونی از Network API استفاده کند.

هدف پیدا کردن Eventهایی است که نیاز به بررسی دقیق‌تر دارند.

PowerShell 7 را فراموش نکنید

اگر روی سیستم PowerShell 7 نصب باشد، Logها ممکن است در:

PowerShellCore/Operational

ثبت شوند.

Script Block Logging در PowerShell Core نیز Event ID 4104 تولید می‌کند.

برای مشاهده:

Get-WinEvent -LogName "PowerShellCore/Operational" -MaxEvents 100

استفاده از Sysmon

برای Serverهایی که Monitoring امنیتی اهمیت دارد، Sysmon یکی از ابزارهای مهم Microsoft Sysinternals است.

Sysmon می‌تواند اطلاعات دقیقی درباره Process و Network Activity ثبت کند.

دو Event بسیار مهم برای این موضوع:

Event ID 1
Process Creation

و:

Event ID 3
Network Connection

هستند. Microsoft توضیح می‌دهد که Event 1 اطلاعات Process Creation و Command Line را ثبت می‌کند و Event 3 برای TCP/UDP Connectionها استفاده می‌شود.

مشاهده Sysmon Event ID 3

در صورت نصب و Config شدن Sysmon:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-Sysmon/Operational'
    Id=3
} -MaxEvents 100

این Event می‌تواند اطلاعاتی مانند:

Image
ProcessId
SourceIp
SourcePort
DestinationIp
DestinationPort

ارائه کند.

این داده برای شناسایی Connection خارجی Process بسیار ارزشمند است.

ارتباط Event ID 1 و Event ID 3

یکی از مزیت‌های Sysmon وجود:

ProcessGuid

است.

Microsoft توضیح می‌دهد ProcessGUID برای Correlation رویدادهای یک Process استفاده می‌شود.

بنابراین می‌توان:

Process Create
     |
     v
Network Connection

را با دقت بیشتری به هم مرتبط کرد.

یک سناریوی Investigation با Sysmon

فرض کنید Event ID 3 نشان می‌دهد:

Image:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

DestinationIp:
203.0.113.50

DestinationPort:
8443

سپس Event ID 1 همان Process را بررسی می‌کنیم:

ParentImage:
C:\Windows\System32\inetsrv\w3wp.exe

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

IIS Worker
    |
    v
PowerShell
    |
    v
External Connection

داریم.

این Correlation به‌مراتب مهم‌تر از مشاهده صرف یک Port است.

بررسی Windows Firewall Log

Windows Defender Firewall می‌تواند Connectionهای Allowed و Dropped را Log کند.

مسیر پیش‌فرض Log:

%windir%\system32\logfiles\firewall\pfirewall.log

است. Microsoft توصیه می‌کند در صورت نیاز به تحلیل، Logging مربوط به Connectionهای مجاز و Drop شده فعال شود.

برای مشاهده:

Get-Content `
"$env:windir\System32\LogFiles\Firewall\pfirewall.log" `
-Tail 100

آیا Firewall Log به‌صورت پیش‌فرض کامل است؟

خیر.

Microsoft توضیح می‌دهد Logging باید برای Profileهای موردنظر Config شود و می‌توان ثبت:

Allowed Connections
Dropped Packets

را فعال کرد.

برای Incidentهای آینده بهتر است Logging متناسب با ظرفیت Server از قبل تنظیم شده باشد.

بررسی Scheduled Taskها

بعد از شناسایی Connection مشکوک فقط Process فعلی را بررسی نکنید.

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

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

Get-ScheduledTask

این Cmdlet Taskهای ثبت‌شده روی سیستم را نمایش می‌دهد.

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

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

بررسی Action مربوط به Scheduled Task

برای مشاهده Commandهایی که Task اجرا می‌کند:

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

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

powershell.exe
pwsh.exe
cmd.exe
wscript.exe
mshta.exe

بررسی Windows Services

Persistence ممکن است از طریق Service انجام شده باشد.

برای مشاهده Serviceها:

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

به:

PathName

توجه کنید.

Serviceهایی که Executable آنها از مسیرهای غیرعادی مانند:

C:\Users\
C:\Temp\
C:\ProgramData\...

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

بررسی Startup Folder

Startup Folder کاربران:

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

و Startup عمومی:

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

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

برای مثال:

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

بررسی Run و RunOnce

برای Audit دفاعی می‌توان Registry Pathهای Startup را به‌صورت Read-only بررسی کرد:

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

و:

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

ورودی‌های ناشناخته باید بررسی شوند.

بررسی PowerShell History

اگر Process مشکوک مربوط به PowerShell است، History نیز می‌تواند سرنخ ایجاد کند.

مسیر واقعی History:

(Get-PSReadLineOption).HistorySavePath

برای مشاهده:

Get-Content (Get-PSReadLineOption).HistorySavePath -Tail 100

اما History منبع قطعی نیست و ممکن است:

  • پاک شده باشد.
  • غیرفعال باشد.
  • Command داخل Script اجرا شده باشد.
  • از Host دیگری استفاده شده باشد.

بنابراین History باید در کنار Event 4104 و 4688 بررسی شود.

بررسی Processهای فعلی PowerShell و CMD

برای مشاهده:

Get-Process powershell,pwsh,cmd -ErrorAction SilentlyContinue

برای دریافت Command Line:

Get-CimInstance Win32_Process |
Where-Object {
    $_.Name -in @(
        'powershell.exe',
        'pwsh.exe',
        'cmd.exe'
    )
} |
Select-Object ProcessId,
              ParentProcessId,
              Name,
              CommandLine

این Command هیچ تغییری روی سیستم ایجاد نمی‌کند و صرفاً Processهای فعال را بررسی می‌کند.

بررسی Connectionهای PowerShell فعال

برای مثال:

$Pids = Get-Process powershell,pwsh -ErrorAction SilentlyContinue |
Select-Object -ExpandProperty Id

foreach ($Pid in $Pids) {
    Get-NetTCPConnection -OwningProcess $Pid -ErrorAction SilentlyContinue
}

اگر PowerShell فعال Connection خارجی دارد، Command Line و Parent آن را بررسی کنید.

یک Workflow عملی برای شناسایی Reverse Shell

فرض کنیم روی Windows Server رفتار مشکوکی مشاهده شده است.

مرحله اول: ثبت Connectionهای فعلی

Get-NetTCPConnection -State Established |
Select-Object LocalAddress,
              LocalPort,
              RemoteAddress,
              RemotePort,
              OwningProcess |
Export-Csv C:\IR\connections.csv -NoTypeInformation

مرحله دوم: پیدا کردن Process

فرض کنیم PID:

6240

است.

Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
Select-Object *

مرحله سوم: Parent Process

$Process = Get-CimInstance Win32_Process -Filter "ProcessId = 6240"

Get-CimInstance Win32_Process `
-Filter "ProcessId = $($Process.ParentProcessId)" |
Select-Object ProcessId,
              Name,
              CommandLine,
              ExecutablePath

مرحله چهارم: بررسی Event 4688

Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4688
} |
Where-Object {
    $_.Message -match '6240|powershell'
}

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

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-PowerShell/Operational'
    Id=4104
} -MaxEvents 200

مرحله ششم: بررسی Sysmon

در صورت نصب:

Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-Sysmon/Operational'
    Id=1,3
} -MaxEvents 200

مرحله هفتم: بررسی Persistence

Get-ScheduledTask

و:

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

اکنون Evidenceهای مختلف را با هم مقایسه کنید.

چه الگویی بیشتر مشکوک است؟

به‌عنوان مثال:

w3wp.exe
   |
   v
powershell.exe
   |
   v
External IP

یا:

winword.exe
   |
   v
cmd.exe
   |
   v
powershell.exe
   |
   v
External IP

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

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

ممکن است Automation سازمانی رفتار مشابهی ایجاد کند.

آیا می‌توان فقط براساس PowerShell نتیجه گرفت؟

خیر.

PowerShell یکی از ابزارهای اصلی Administration در Windows است.

به همین دلیل وجود:

powershell.exe

کاملاً طبیعی است.

مواردی که باید با هم بررسی شوند:

Who started it?
When?
From what parent?
With what command line?
Where did it connect?
Was the destination expected?

اگر Process مشکوک پیدا کردیم چه کنیم؟

یکی از اشتباهات رایج این است که فوراً:

Stop-Process -Id PID -Force

اجرا کنیم.

در Incident جدی بهتر است ابتدا Evidenceهای Volatile ثبت شوند.

زیرا بعد از Kill شدن Process ممکن است:

  • Connection از بین برود.
  • Command Line از دسترس خارج شود.
  • Parent/Child Relationship تغییر کند.
  • Memory Evidence از بین برود.

جمع‌آوری اولیه Evidence

ابتدا Directory ایجاد کنید:

New-Item C:\IR -ItemType Directory -ErrorAction SilentlyContinue

Connectionها:

Get-NetTCPConnection |
Export-Csv C:\IR\network.csv -NoTypeInformation

Processها:

Get-CimInstance Win32_Process |
Select-Object ProcessId,
              ParentProcessId,
              Name,
              ExecutablePath,
              CommandLine |
Export-Csv C:\IR\processes.csv -NoTypeInformation

Sessionهای User:

quser > C:\IR\sessions.txt

Scheduled Taskها:

Get-ScheduledTask |
Export-Clixml C:\IR\scheduled-tasks.xml

Hash فایل Executable مشکوک

اگر Process از Executable ناشناس اجرا شده است:

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

Hash را ثبت کنید.

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

مرحله Containment

اگر Compromise تأیید یا بسیار محتمل باشد، سیستم باید طبق Incident Response Plan سازمان مهار شود.

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

  • Egress Traffic محدود شود.
  • Server از VLAN جدا شود.
  • Security Group تغییر کند.
  • Firewall Rule موقت اعمال شود.
  • Access خارجی محدود شود.

در Incidentهای جدی خاموش کردن فوری Server همیشه بهترین کار نیست، زیرا Evidenceهای Volatile از بین می‌روند.

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

اگر مهاجم روی Server Command اجرا کرده باشد، ممکن است Credentialهای موجود روی سیستم در معرض خطر قرار گرفته باشند.

برای مثال:

Domain Credential
Local Administrator Password
API Token
Database Password
Service Account
Cloud Credential
Backup Credential

در صورت تأیید Incident باید Credentialهای مرتبط براساس Scope حادثه Rotate شوند.

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

بستن Connection فقط Symptom را حذف می‌کند.

باید مشخص شود Reverse Shell چگونه ایجاد شده است.

برای مثال:

  • Web Application آسیب‌پذیر
  • Credential سرقت‌شده
  • RDP Compromise
  • Phishing
  • Service آسیب‌پذیر
  • Application Upload
  • Malicious Scheduled Task
  • Service Persistence

تا Root Cause برطرف نشود، مهاجم ممکن است دوباره دسترسی ایجاد کند.

چگونه احتمال Reverse Shell را کاهش دهیم؟

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

  • Patch Management
  • Microsoft Defender یا EDR
  • Least Privilege
  • محدود کردن Local Administrator
  • Egress Filtering
  • Firewall Logging
  • Script Block Logging
  • Process Creation Auditing
  • Sysmon
  • Application Control
  • ASR Rules
  • Centralized Logging
  • SIEM

محدود کردن Outbound Traffic

یکی از مهم‌ترین راهکارهای دفاعی، کنترل Egress Traffic است.

بسیاری از Serverها نیازی ندارند به هر IP و Port اینترنت دسترسی داشته باشند.

برای مثال Web Server ممکن است فقط نیاز داشته باشد به:

DNS
Windows Update
Monitoring
Backup
Approved APIs
Database

متصل شود.

اگر Destinationهای مجاز مشخص باشند، Connection ناشناخته سریع‌تر قابل تشخیص است.

فعال کردن Logging مناسب قبل از Incident

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

برای همین بهتر است قبل از حادثه حداقل موارد زیر در Serverهای مهم وجود داشته باشند:

Audit Process Creation
Command Line Logging
PowerShell Script Block Logging
Firewall Logging
Sysmon / EDR
Centralized Logs

Event ID 4688 و Sysmon Eventهای 1 و 3 در Correlation Process و Network بسیار کاربردی هستند.

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

برخی اشتباهات متداول هنگام بررسی Reverse Shell در Windows عبارت‌اند از:

  • بررسی فقط Listening Portها
  • تمرکز فقط روی Portهای عجیب
  • تصور اینکه هر PowerShell Process مخرب است
  • بررسی نکردن OwningProcess
  • بررسی نکردن Parent Process
  • توجه نکردن به Command Line
  • Kill کردن Process قبل از جمع‌آوری Evidence
  • بررسی نکردن Event 4688
  • بررسی نکردن Event 4104
  • نادیده گرفتن Sysmon Event 3
  • بررسی نکردن Scheduled Taskها
  • بررسی نکردن Serviceها
  • پیدا نکردن Root Cause

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

برای Detection دقیق‌تر:

  • Connectionهای Established را بررسی کنید.
  • PID مالک Connection را مشخص کنید.
  • Command Line Process را بررسی کنید.
  • Parent Process را پیدا کنید.
  • Destination IP را با Baseline مقایسه کنید.
  • Event 4688 را بررسی کنید.
  • PowerShell Event 4104 را بررسی کنید.
  • Sysmon Event 1 و 3 را Correlate کنید.
  • Scheduled Taskها و Serviceها را بررسی کنید.
  • قبل از Kill کردن Process Evidence بگیرید.
  • Firewall Logging را فعال نگه دارید.
  • Egress Traffic را محدود کنید.
  • Root Cause را پیدا کنید.

چک‌لیست

اگر احتمال Reverse Shell روی Windows Server وجود دارد، موارد زیر را بررسی کنید:

  • Connectionهای Established استخراج شده‌اند.
  • Remote IPهای ناشناخته مشخص شده‌اند.
  • Remote Portها بررسی شده‌اند.
  • PID مربوط به Connection پیدا شده است.
  • Process Name مشخص شده است.
  • Command Line بررسی شده است.
  • Executable Path بررسی شده است.
  • Parent Process مشخص شده است.
  • User مربوط به Process بررسی شده است.
  • Event ID 4688 بررسی شده است.
  • Event ID 4104 بررسی شده است.
  • Sysmon Event ID 1 بررسی شده است.
  • Sysmon Event ID 3 بررسی شده است.
  • Windows Firewall Log بررسی شده است.
  • Scheduled Taskها بررسی شده‌اند.
  • Serviceهای جدید بررسی شده‌اند.
  • Startup Locationها بررسی شده‌اند.
  • PowerShell History بررسی شده است.
  • Evidence قبل از Terminate کردن Process ذخیره شده است.
  • Root Cause بررسی شده است.
  • Credentialهای در معرض خطر Rotate شده‌اند.

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

برای مطالعه بیشتر درباره ابزارها و Logهای مورد استفاده در این مقاله می‌توانید منابع رسمی Microsoft را بررسی کنید:

جمع‌بندی

Reverse Shell در Windows لزوماً با یک پورت Listening یا RDP Session جدید قابل تشخیص نیست.

در بسیاری از موارد باید Connectionهای خروجی سیستم را بررسی کنیم.

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

Get-NetTCPConnection -State Established

است.

این دستور علاوه بر Destination IP و Port، مقدار:

OwningProcess

را نیز ارائه می‌کند.

پس از پیدا کردن PID باید Process و Command Line آن بررسی شود:

Get-CimInstance Win32_Process -Filter "ProcessId = PID"

و سپس Parent Process مشخص شود.

در Investigation واقعی الگوی:

Suspicious Process
       +
Unexpected Parent
       +
External Connection
       +
Unusual Command Line

اهمیت بیشتری از شماره Port دارد.

برای بررسی فعالیت‌های گذشته نیز Event:

4688

برای Process Creation،

Event:

4104

برای PowerShell Script Block،

و در صورت استفاده از Sysmon:

Event ID 1
Event ID 3

برای Process Creation و Network Connection بسیار مهم هستند.

اگر Process مشکوکی پیدا شد، قبل از Terminate کردن آن باید اطلاعات Network، Process Tree، Command Line و Logها ثبت شوند.

همچنین بررسی Scheduled Task، Windows Service، Startup Location و PowerShell History ضروری است، زیرا Reverse Shell ممکن است فقط بخشی از یک Persistence Mechanism بزرگ‌تر باشد.

در نهایت، شناسایی Reverse Shell نباید براساس یک Port یا یک Process انجام شود. تشخیص معتبر زمانی شکل می‌گیرد که Network Connection، Process، Parent Process، Command Line و Event Logها در کنار یکدیگر تحلیل شوند.

کیان پور

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

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

شناسایی Reverse Shell در ویندوز

کپی کردن لینک

سلام