مقدمه

یکی از خطرناک‌ترین اتفاقاتی که ممکن است بعد از نفوذ به یک وب‌سایت یا Web Server رخ دهد، قرار گرفتن یک Web Shell روی سرور است.

Web Shell معمولاً یک فایل یا Component سمت Server است که از طریق درخواست HTTP یا HTTPS فراخوانی می‌شود و می‌تواند امکان اجرای دستور یا انجام عملیات مختلف روی سیستم را در اختیار مهاجم قرار دهد.

MITRE ATT&CK تکنیک Web Shell را با شناسه T1505.003 در دسته Server Software Component قرار می‌دهد و آن را روشی برای حفظ دسترسی به Web Server توصیف می‌کند.

روی سرورهای لینوکسی، Web Shell ممکن است داخل مسیرهایی مانند:

/var/www/
/usr/share/nginx/html/
/home/<user>/public_html/

یا داخل Directoryهای مربوط به Upload، Plugin، Theme، Cache و Application قرار گرفته باشد.

در این مقاله روش عملی شناسایی Web Shell را با استفاده از ابزارهای استاندارد Linux بررسی می‌کنیم؛ از جمله:

find
grep
stat
file
sha256sum
ps
pstree
ss
journalctl
Apache / Nginx Logs

هدف این مقاله Detection و Incident Response روی سرورهای تحت مدیریت شما است و شامل آموزش ساخت یا استفاده از Web Shell نیست.

Web Shell چیست؟

Web Shell معمولاً داخل Application سمت Server قرار می‌گیرد.

برای مثال در یک Application مبتنی بر PHP ممکن است ساختار حمله به شکل زیر باشد:

Internet
   |
   v
Web Server
   |
   v
Web Application
   |
   v
Unauthorized Server-side File
   |
   v
Command / File / System Access

تفاوت مهم Web Shell با یک Reverse Shell این است که Web Shell معمولاً از طریق Web Server و درخواست HTTP یا HTTPS فراخوانی می‌شود.

MITRE توضیح می‌دهد Web Shell می‌تواند روی Web Server قابل دسترس قرار بگیرد و برای اجرای دستورات یا دسترسی بیشتر به Server استفاده شود.

Web Shell چگونه روی سرور قرار می‌گیرد؟

وجود Web Shell معمولاً نتیجه یک مشکل امنیتی قبلی است.

برای مثال:

Vulnerable CMS
Vulnerable Plugin
Vulnerable Theme
Insecure File Upload
Compromised Admin Account
Stolen FTP / SSH Credential
Incorrect File Permission
Remote Code Execution

بنابراین پیدا کردن فایل Web Shell کافی نیست.

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

Web Shell چگونه وارد Server شده است؟

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

Web Shell الزاماً نامی مانند:

shell.php
backdoor.php

ندارد.

ممکن است نام آن شبیه فایل‌های عادی Application باشد:

cache.php
config-old.php
class.api.php
image.php
update.php
functions2.php
ajax.php

یا حتی داخل یک فایل قانونی Inject شده باشد.

بنابراین Detection فقط براساس Filename قابل اعتماد نیست.

باید موارد مختلفی را کنار هم بررسی کنیم:

File Location
File Content
Modification Time
Owner
Permissions
Web Logs
Processes
Network Connections
Application Baseline

مرحله اول: Web Root واقعی را پیدا کنید

قبل از جستجو باید بدانیم Application دقیقاً از کدام Directory Serve می‌شود.

مسیرهای رایج عبارت‌اند از:

/var/www/html
/var/www/
/usr/share/nginx/html
/home/user/public_html

اما این مسیرها قطعی نیستند و ممکن است Virtual Host مسیر دیگری داشته باشد.

بررسی Apache DocumentRoot

روی Apache می‌توان Configuration را جستجو کرد:

grep -RIn "DocumentRoot" \
/etc/apache2 \
/etc/httpd \
2>/dev/null

نمونه:

DocumentRoot /var/www/example.com/public

اکنون مسیر اصلی Investigation مشخص‌تر است.

بررسی Nginx Root

برای Nginx:

grep -RInE '^\s*root\s+' \
/etc/nginx \
2>/dev/null

یا Configuration نهایی Nginx:

nginx -T 2>/dev/null | grep -E '^\s*root\s+'

این کار کمک می‌کند Web Root واقعی هر Server Block مشخص شود.

مرحله دوم: فایل‌های اخیراً تغییرکرده را پیدا کنید

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

برای مثال فایل‌های تغییرکرده در ۲ روز اخیر:

find /var/www \
-type f \
-mtime -2 \
-ls 2>/dev/null

گزینه -mtime برای جستجو براساس زمان آخرین تغییر محتوای فایل استفاده می‌شود.

فایل‌های PHP جدید را بررسی کنیم

اگر Application مبتنی بر PHP است:

find /var/www \
-type f \
-name "*.php" \
-mtime -2 \
-ls 2>/dev/null

برای ۷ روز اخیر:

find /var/www \
-type f \
-name "*.php" \
-mtime -7 \
-ls 2>/dev/null

این بازه باید متناسب با زمان احتمالی Incident انتخاب شود.

mtime و ctime چه تفاوتی دارند؟

mtime مربوط به زمان تغییر محتوای فایل است.

اما ctime در Linux زمان تغییر Metadata مربوط به inode را نشان می‌دهد؛ برای مثال تغییر:

Owner
Permission
Link
File Metadata

برای فایل‌های دارای ctime اخیر:

find /var/www \
-type f \
-ctime -2 \
-ls 2>/dev/null

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

خروجی مرتب براساس زمان

برای مشاهده فایل‌ها همراه Timestamp:

find /var/www \
-type f \
-printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n' \
2>/dev/null |
sort

این خروجی اطلاعات زیر را نشان می‌دهد:

Date
Time
Owner
Group
Permission
Path

و برای Timeline بسیار مفید است.

مرحله سوم: Directoryهای Upload را بررسی کنید

یکی از نقاط مهم برای Web Shell، مسیرهایی است که Web Application اجازه Upload فایل دارد.

برای مثال:

uploads
upload
files
media
images
attachments
tmp
cache

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

find /var/www \
-type d \
\( -iname "*upload*" \
-o -iname "*media*" \
-o -iname "*attachment*" \) \
-print 2>/dev/null

فایل PHP داخل Upload Directory

اگر Directory Upload فقط باید شامل تصویر یا Document باشد، وجود PHP داخل آن اهمیت زیادی دارد.

برای مثال:

find /var/www \
-type f \
-path "*upload*" \
-name "*.php" \
-print 2>/dev/null

همچنین:

find /var/www \
-type f \
-path "*uploads*" \
-name "*.php" \
-print 2>/dev/null

وجود چنین فایلی لزوماً Web Shell نیست، اما باید علت آن مشخص شود.

فایل Upload شده فقط براساس Extension بررسی نشود

Filename ممکن است گمراه‌کننده باشد.

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

photo.jpg

داشته باشد، اما محتوای آن تصویر واقعی نباشد.

برای بررسی نوع فایل:

file /path/to/file

برای فایل‌های اخیر:

find /var/www \
-type f \
-mtime -2 \
-print0 2>/dev/null |
xargs -0 file

این روش کمک می‌کند Extension فایل با Content واقعی مقایسه شود.

چرا Upload Directory اهمیت دارد؟

Applicationهایی که File Upload دارند باید Uploaded Fileها را به‌درستی Validate و در Location مناسب ذخیره کنند.

در PHP، تابع move_uploaded_file() برای اطمینان از اینکه Source واقعاً از مکانیزم HTTP POST Upload آمده است طراحی شده است، اما امنیت Upload فقط به همین بررسی محدود نمی‌شود.

در عمل باید Extension، MIME، Content، Permission و محل Storage نیز براساس Application Policy کنترل شوند.

مرحله چهارم: Owner فایل‌ها را بررسی کنید

برای مشاهده Owner و Permission:

ls -lah /var/www/html

برای یک فایل خاص:

stat /var/www/html/example.php

اطلاعات مهم:

Owner
Group
Access
Modify
Change
Size

هستند.

فایل‌هایی که Web Server ساخته است

روی Ubuntu/Debian معمولاً Web Server ممکن است با Userهایی مانند:

www-data

اجرا شود.

در RHEL / AlmaLinux ممکن است:

apache

باشد.

برای مشاهده فایل‌های متعلق به www-data:

find /var/www \
-type f \
-user www-data \
-ls 2>/dev/null

یا:

find /var/www \
-type f \
-user apache \
-ls 2>/dev/null

این نتیجه به‌تنهایی نشانه Web Shell نیست؛ CMSها و Applicationها ممکن است به‌صورت قانونی فایل تولید کنند.

اما فایل PHP جدیدی که توسط Web Server User ایجاد شده باشد، می‌تواند نیازمند بررسی بیشتری باشد.

فایل‌های World-Writable را بررسی کنید

برای پیدا کردن فایل‌هایی که همه کاربران اجازه Write دارند:

find /var/www \
-type f \
-perm -0002 \
-ls 2>/dev/null

GNU find امکان جستجوی Permission Bitهای مشخص را با -perm فراهم می‌کند.

در Web Root بهتر است Permissionهای غیرضروری محدود باشند.

Directoryهای World-Writable

find /var/www \
-type d \
-perm -0002 \
-ls 2>/dev/null

Directoryهای قابل Write لزوماً اشتباه نیستند؛ مسیر Upload یا Cache ممکن است نیاز به Write داشته باشد.

اما باید دقیقاً مشخص باشد:

چه Directoryهایی واقعاً باید Writable باشند؟

مرحله پنجم: محتویات PHP مشکوک را جستجو کنید

Web Shellهای PHP ممکن است از Functionهایی استفاده کنند که قابلیت اجرای Command، Process یا Dynamic Code دارند.

برای Detection می‌توان به دنبال Functionهایی مانند:

eval
system
exec
shell_exec
passthru
proc_open
popen

گشت.

برای مثال:

grep -RInE \
'eval\s*\(|system\s*\(|shell_exec\s*\(|passthru\s*\(|proc_open\s*\(|popen\s*\(' \
/var/www \
--include="*.php" \
2>/dev/null

این Command فقط Candidateها را پیدا می‌کند.

وجود این Functionها الزاماً به معنی Web Shell نیست.

چرا grep ممکن است False Positive بدهد؟

Applicationهای قانونی نیز ممکن است Functionهایی مانند:

exec()
proc_open()

داشته باشند.

برای مثال:

• Backup Software
• Media Processing
• Deployment Tool
• Monitoring Script
• Plugin مدیریتی

ممکن است از Process Execution استفاده کنند.

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

جستجوی Encoding و Obfuscation

کدهای مخرب ممکن است Obfuscated باشند.

برای پیدا کردن Candidateها می‌توان عبارت‌هایی مانند:

base64_decode
gzinflate
str_rot13

را بررسی کرد:

grep -RInE \
'base64_decode|gzinflate|str_rot13' \
/var/www \
--include="*.php" \
2>/dev/null

MITRE نمونه‌هایی از Web Shellها را ثبت کرده که برای مخفی کردن Stringها از Encoding یا Obfuscation استفاده کرده‌اند.

اما این Functionها نیز در Applicationهای قانونی استفاده می‌شوند.

چند Indicator را کنار هم قرار دهید

برای مثال:

Recently Modified PHP File
        +
Located in Upload Directory
        +
Owned by Web Server User
        +
Obfuscated Content

بسیار مهم‌تر از مشاهده صرف:

base64_decode()

است.

مرحله ششم: فایل را با نسخه اصلی Application مقایسه کنید

اگر CMS یا Application از Package یا Source Control مشخصی استفاده می‌کند، فایل‌ها را با نسخه سالم مقایسه کنید.

برای مثال اگر Git Repository در اختیار دارید:

git status

و:

git diff

می‌توانند تغییرات Local را مشخص کنند.

در Production باید مطمئن شوید Repository واقعاً Baseline قابل اعتماد است.

Hash فایل مشکوک

برای ثبت Evidence:

sha256sum /var/www/html/example.php

خروجی:

SHA256  /var/www/html/example.php

را در Incident Record ذخیره کنید.

Metadata کامل فایل

stat /var/www/html/example.php

و:

file /var/www/html/example.php

همچنین Permission:

ls -lah /var/www/html/example.php

این اطلاعات باید قبل از حذف فایل ثبت شوند.

مرحله هفتم: Processهای Web Server را بررسی کنید

برای Apache:

ps auxf | grep -E 'apache2|httpd'

برای Nginx:

ps auxf | grep nginx

برای PHP-FPM:

ps auxf | grep php-fpm

روش بهتر:

pstree -ap

است.

در Process Tree دنبال چه چیزی بگردیم؟

در حالت عادی Web Server نباید دائماً Child Processهای غیرمنتظره ایجاد کند.

ساختاری مانند:

apache2
   |
   v
bash

یا:

php-fpm
   |
   v
sh

یا:

nginx / application
   |
   v
curl / wget

بدون کاربرد مشخص Application باید بررسی شود.

MITRE در Detection Strategy مربوط به Web Shell نیز روی رفتارهایی مانند ایجاد فایل غیرمجاز در Web Directory و سپس اجرای Shell یا Utilityهای غیرمنتظره توسط Web Server تأکید می‌کند.

پردازش‌های مربوط به Web Server User

روی Ubuntu/Debian:

ps -u www-data -f

روی AlmaLinux / RHEL:

ps -u apache -f

اگر Processهایی مانند:

bash
sh
curl
wget
python
perl

تحت Web Server User وجود دارند، باید مشخص شود Application چرا آنها را اجرا کرده است.

Command Line کامل Process

برای PID مشخص:

tr '\0' ' ' < /proc/PID/cmdline

Executable:

readlink -f /proc/PID/exe

Working Directory:

readlink -f /proc/PID/cwd

Parent PID:

grep PPid /proc/PID/status

این اطلاعات کمک می‌کنند Process Tree دقیق‌تری ساخته شود.

مرحله هشتم: Connectionهای شبکه را بررسی کنید

Web Shell ممکن است فقط از HTTP Request استفاده کند، اما در بعضی Incidentها Process ایجادشده ممکن است Connection خارجی نیز برقرار کند.

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

ss -plant

ss برای بررسی Socketها استفاده می‌شود و گزینه -p Process مرتبط با Socket را نمایش می‌دهد.

Connectionهای Established

ss -plant state established

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

Process
Remote IP
Remote Port
User

توجه کنید.

Connectionهای Web Server User

می‌توان ابتدا PIDهای Web Server را پیدا کرد و Connectionهای آنها را بررسی کرد.

همچنین:

sudo lsof -nP -i

در صورت نصب بودن lsof می‌تواند ارتباط Processها با Network Socketها را نشان دهد.

چه Connectionهایی مهم‌ترند؟

برای مثال:

php-fpm
   |
   v
Unknown External IP

یا:

apache2 child
   |
   v
Unexpected External Connection

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

اما Application ممکن است به‌صورت قانونی به:

Database
API
Payment Gateway
Object Storage
SMTP
Monitoring

متصل شود.

بنابراین Baseline ضروری است.

مرحله نهم: Apache Access Log را بررسی کنید

Apache Access Log درخواست‌های پردازش‌شده توسط Server را ثبت می‌کند و Location و Format آن با CustomLog و LogFormat قابل تنظیم است.

مسیرهای رایج:

Ubuntu / Debian:

/var/log/apache2/access.log

RHEL / AlmaLinux:

/var/log/httpd/access_log

اما Configuration واقعی Server را بررسی کنید.

آخرین Requestهای Apache

Ubuntu:

tail -100 /var/log/apache2/access.log

RHEL:

tail -100 /var/log/httpd/access_log

اگر فایل Web Shell احتمالی:

cache.php

است:

grep "cache.php" \
/var/log/apache2/access.log

تمام Logهای Rotate شده را بررسی کنید

فقط فایل فعلی را بررسی نکنید.

برای مثال:

zgrep -h "cache.php" \
/var/log/apache2/access.log* \
2>/dev/null

یا روی RHEL:

zgrep -h "cache.php" \
/var/log/httpd/access_log* \
2>/dev/null

در صورت فشرده بودن Logهای قدیمی، zgrep مفید است.

Apache Error Log

Apache مستندات Error Log را یکی از مهم‌ترین منابع برای بررسی مشکلات Server معرفی می‌کند.

Ubuntu:

tail -100 /var/log/apache2/error.log

RHEL:

tail -100 /var/log/httpd/error_log

به خطاهای PHP، Permission، File Not Found و Requestهای غیرمعمول نزدیک به Timeline Incident توجه کنید.

مرحله دهم: Nginx Access Log

Nginx درخواست‌ها را از طریق Directive:

access_log

ثبت می‌کند و Format و Location آن قابل تنظیم است.

مسیر رایج:

/var/log/nginx/access.log

اما Configuration واقعی را پیدا کنید:

nginx -T 2>/dev/null |
grep -E 'access_log|error_log'

بررسی Request به فایل مشکوک در Nginx

grep "cache.php" \
/var/log/nginx/access.log

Logهای قدیمی:

zgrep -h "cache.php" \
/var/log/nginx/access.log* \
2>/dev/null

Nginx Error Log

Directive error_log مسیر و Level مربوط به Error Logging را مشخص می‌کند.

معمولاً:

/var/log/nginx/error.log

بررسی:

tail -100 /var/log/nginx/error.log

چه چیزی را در Access Log بررسی کنیم؟

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

Source IP
Timestamp
HTTP Method
URI
Status Code
User-Agent
Request Frequency

مثلاً ممکن است تعداد زیادی Request به یک PHP File ناشناخته وجود داشته باشد.

Requestهای POST را بررسی کنیم

Web Shellها یا Endpointهای Upload ممکن است از POST استفاده کنند، اما POST در Web Application کاملاً عادی است.

برای بررسی اولیه:

grep '"POST ' \
/var/log/nginx/access.log |
tail -100

یا Apache:

grep '"POST ' \
/var/log/apache2/access.log |
tail -100

هدف پیدا کردن Requestهای غیرمنتظره در Timeline است، نه مشکوک دانستن تمام POSTها.

IP مربوط به Web Shell را پیدا کنیم

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

unknown.php

است:

grep "unknown.php" \
/var/log/nginx/access.log

ممکن است Source IP مشخص شود.

سپس تمام Requestهای همان IP:

grep "203.0.113.50" \
/var/log/nginx/access.log

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

User-Agent را بررسی کنید

برای Incident Timeline ممکن است User-Agent نیز سرنخ ایجاد کند.

اما:

User-Agent به‌راحتی قابل جعل است.

بنابراین نباید از آن به‌تنهایی برای Attribution یا نتیجه‌گیری استفاده شود.

مرحله یازدهم: Logهای PHP-FPM

بسته به Distribution و Configuration، PHP-FPM ممکن است Logهای جداگانه داشته باشد.

برای پیدا کردن Configuration:

grep -RInE \
'error_log|slowlog|access.log' \
/etc/php* \
/etc/php-fpm* \
2>/dev/null

همچنین:

journalctl \
-u php-fpm \
--since "24 hours ago"

یا Service نسخه‌ای:

journalctl \
-u php8.3-fpm \
--since "24 hours ago"

نام Service به Distribution و PHP Version بستگی دارد.

مرحله دوازدهم: Journal را بررسی کنید

برای Apache:

journalctl \
-u apache2 \
--since "24 hours ago"

یا:

journalctl \
-u httpd \
--since "24 hours ago"

برای Nginx:

journalctl \
-u nginx \
--since "24 hours ago"

این Logها را با Timestamp فایل مشکوک تطبیق دهید.

مرحله سیزدهم: فایل‌های مخفی را بررسی کنید

Web Shell ممکن است در Directory با Filename مخفی قرار گرفته باشد.

برای پیدا کردن فایل‌های مخفی PHP:

find /var/www \
-type f \
-name ".*.php" \
-ls 2>/dev/null

همچنین Directoryهای مخفی:

find /var/www \
-type d \
-name ".*" \
-print 2>/dev/null

وجود Directory مخفی لزوماً مخرب نیست؛ Frameworkها و Git نیز Directoryهای مخفی دارند.

PHP با Extension غیرمعمول

بسته به Configuration Server، Script ممکن است Extensionهای مختلفی داشته باشد.

برای Inventory فایل‌های Script:

find /var/www \
-type f \
\( -name "*.php" \
-o -name "*.phtml" \
-o -name "*.php5" \
-o -name "*.phar" \) \
-print 2>/dev/null

Extensionهای قابل اجرا باید براساس Configuration واقعی Web Server و PHP مشخص شوند.

بررسی Apache Handlerها

برای پیدا کردن Configurationهای مربوط به PHP:

grep -RInE \
'SetHandler|AddHandler|AddType' \
/etc/apache2 \
/etc/httpd \
2>/dev/null

اگر Extension غیرمعمول به PHP Handler متصل شده باشد، باید دلیل آن مشخص باشد.

بررسی Nginx PHP Location

nginx -T 2>/dev/null |
grep -nE 'fastcgi_pass|location.*php'

این Configuration مشخص می‌کند چه Requestهایی به PHP-FPM ارسال می‌شوند.

مرحله چهاردهم: .htaccess را بررسی کنید

در Apache، .htaccess می‌تواند رفتار Directory را تغییر دهد.

برای پیدا کردن:

find /var/www \
-type f \
-name ".htaccess" \
-print 2>/dev/null

فایل‌های اخیراً تغییرکرده:

find /var/www \
-type f \
-name ".htaccess" \
-mtime -7 \
-ls 2>/dev/null

داخل .htaccess به تغییرات غیرمنتظره Handler، Rewrite و Access Control توجه کنید.

مرحله پانزدهم: فایل‌های بسیار کوچک یا غیرعادی

بعضی Web Shellها ممکن است حجم بسیار کمی داشته باشند.

برای پیدا کردن PHPهای کوچک:

find /var/www \
-type f \
-name "*.php" \
-size -5k \
-ls 2>/dev/null

این روش صرفاً برای کاهش Search Space است.

بسیاری از فایل‌های PHP قانونی نیز کوچک هستند.

فایل‌های PHP بزرگ غیرعادی

همچنین:

find /var/www \
-type f \
-name "*.php" \
-size +1M \
-ls 2>/dev/null

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

اما Size به‌تنهایی Indicator امنیتی نیست.

مرحله شانزدهم: Comparison با Package Manager

اگر فایل مربوط به Package سیستم است، Integrity آن را بررسی کنید.

Ubuntu / Debian

Package مالک فایل:

dpkg -S /path/to/file

و Verify:

dpkg -V package-name

AlmaLinux / Rocky / RHEL

rpm -qf /path/to/file

و:

rpm -V package-name

این روش برای فایل‌های متعلق به Package Manager مفید است.

فایل‌های CMS که دستی Deploy شده‌اند الزاماً Package ندارند.

مرحله هفدهم: فایل‌های حذف‌شده ولی در حال اجرا

در Incidentهای پیچیده ممکن است فایل روی Disk حذف شده باشد اما Process همچنان آن را باز نگه داشته باشد.

در صورت وجود lsof:

lsof +L1

یا:

lsof | grep '(deleted)'

Processهای مربوط به فایل حذف‌شده باید بررسی شوند.

مرحله هجدهم: Cron و Persistence را بررسی کنید

Web Shell ممکن است فقط Initial Foothold باشد و مهاجم Persistence دیگری ایجاد کرده باشد.

Root Cron:

crontab -l

تمام Cronهای System:

ls -lah /etc/cron.d/

Timerها:

systemctl list-timers --all

Serviceهای Enabled:

systemctl list-unit-files \
--type=service \
--state=enabled

SSH Keys:

find /root /home \
-path '*/.ssh/authorized_keys' \
-type f \
-print 2>/dev/null

پیدا کردن Web Shell پایان Investigation نیست.

مرحله نوزدهم: User و sudo را بررسی کنید

Accountهای UID 0:

awk -F: '$3 == 0 {print}' /etc/passwd

Userهای دارای sudo:

Ubuntu:

getent group sudo

AlmaLinux / RHEL:

getent group wheel

همچنین:

ls -lah /etc/sudoers.d/

اگر مهاجم از Web Shell به Privilege Escalation رسیده باشد، ممکن است تغییرات دیگری نیز وجود داشته باشد.

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

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

مرحله اول: مشخص کردن Web Root

grep -RIn "DocumentRoot" \
/etc/apache2 \
/etc/httpd \
2>/dev/null

یا:

nginx -T 2>/dev/null |
grep -E '^\s*root\s+'

مرحله دوم: فایل‌های اخیر

find /var/www \
-type f \
-mtime -7 \
-printf '%TY-%Tm-%Td %TH:%TM %u %g %m %p\n' \
2>/dev/null |
sort

مرحله سوم: PHPهای اخیر

find /var/www \
-type f \
-name "*.php" \
-mtime -7 \
-ls 2>/dev/null

مرحله چهارم: PHP داخل Uploadها

find /var/www \
-type f \
-path "*upload*" \
-name "*.php" \
-print 2>/dev/null

مرحله پنجم: Patternهای مشکوک

grep -RInE \
'eval\s*\(|system\s*\(|shell_exec\s*\(|passthru\s*\(|proc_open\s*\(|popen\s*\(' \
/var/www \
--include="*.php" \
2>/dev/null

مرحله ششم: Process Tree

pstree -ap

مرحله هفتم: Web Server Processها

ps auxf |
grep -E 'apache2|httpd|nginx|php-fpm'

مرحله هشتم: Network

ss -plant

مرحله نهم: Web Logs

Apache:

tail -200 /var/log/apache2/access.log

یا:

tail -200 /var/log/httpd/access_log

Nginx:

tail -200 /var/log/nginx/access.log

مرحله دهم: Hash و Metadata

stat /path/to/suspicious.php

sha256sum /path/to/suspicious.php

file /path/to/suspicious.php

اکنون می‌توان File Evidence، Process Activity، Network و Web Requests را در یک Timeline قرار داد.

یک Audit سریع برای PHP Server

echo "=== RECENT PHP FILES ==="

find /var/www \
-type f \
-name "*.php" \
-mtime -7 \
-ls 2>/dev/null


echo
echo "=== PHP FILES IN UPLOAD PATHS ==="

find /var/www \
-type f \
-path "*upload*" \
-name "*.php" \
-print 2>/dev/null


echo
echo "=== SUSPICIOUS PHP FUNCTIONS ==="

grep -RInE \
'eval\s*\(|system\s*\(|shell_exec\s*\(|passthru\s*\(|proc_open\s*\(|popen\s*\(' \
/var/www \
--include="*.php" \
2>/dev/null


echo
echo "=== WEB PROCESSES ==="

ps auxf |
grep -E 'apache2|httpd|nginx|php-fpm'


echo
echo "=== NETWORK CONNECTIONS ==="

ss -plant

این مجموعه Commandها چیزی را از Server حذف نمی‌کند و برای Triage اولیه مناسب است.

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

برای مثال:

New PHP File
+
Upload Directory
+
Web Server Owner
+
Obfuscated Content

یا:

New PHP File
+
Repeated HTTP Requests
+
Web Server Process
+
Unexpected Shell Child Process

یا:

PHP-FPM
+
bash / sh
+
External Network Connection

چنین Correlationهایی اهمیت بیشتری از یک Indicator منفرد دارند.

Web Shell پیدا کردیم؛ آیا فوراً حذفش کنیم؟

در Incident جدی بهتر است ابتدا Evidence حفظ شود.

قبل از حذف:

stat /path/to/file

sha256sum /path/to/file

file /path/to/file

و در صورت امکان یک Copy برای Incident Analysis تهیه کنید.

همچنین URL مربوط به فایل را در Access Log جستجو کنید.

درخواست‌های مربوط به Web Shell را حفظ کنید

مثلاً اگر فایل:

unknown.php

است:

zgrep -h "unknown.php" \
/var/log/nginx/access.log* \
2>/dev/null \
> /root/IR-unknown-php-requests.log

برای Apache نیز همین کار را با Log Path واقعی انجام دهید.

Processهای مرتبط را ثبت کنید

ps auxf > /root/IR-processes.txt

Connectionها:

ss -plant > /root/IR-network.txt

Serviceها:

systemctl list-units \
--type=service \
--state=running \
> /root/IR-services.txt

فقط Web Shell را پاک نکنید

مهم‌ترین سؤال این است:

مهاجم چگونه توانسته فایل را ایجاد یا تغییر دهد؟

ممکن است Root Cause یکی از موارد زیر باشد:

Vulnerable Plugin
Vulnerable CMS
File Upload Vulnerability
Stolen Password
Compromised Control Panel
Compromised FTP Account
Remote Code Execution
Incorrect Permissions

اگر فقط Web Shell حذف شود، مهاجم ممکن است دوباره آن را Upload کند.

Credentialها را Rotate کنید

اگر Web Shell تأیید شده و مهاجم توانسته روی Server Command اجرا کند، باید احتمال دسترسی به Credentialهای موجود روی Server بررسی شود.

برای مثال:

Database Password
CMS Administrator Password
API Tokens
SSH Keys
Control Panel Credentials
Backup Credentials
Cloud Credentials

Rotation باید براساس Scope واقعی Incident انجام شود.

Application Secretها را فراموش نکنید

فایل‌های Application ممکن است شامل:

.env
config.php
wp-config.php
configuration.php
settings.php

باشند.

اگر Web Shell امکان File Read داشته باشد، Secretهای Application نیز ممکن است در معرض خطر قرار گرفته باشند.

Permissionهای Web Root را اصلاح کنید

Web Server User نباید بدون نیاز بتواند تمام Application را Write کند.

بهتر است فقط Directoryهایی که واقعاً نیازمند Write هستند، مانند بعضی:

uploads
cache
sessions
temporary data

Permission مناسب داشته باشند.

MITRE نیز Least Privilege و محدود کردن Accountهایی که اجازه تغییر Web Directory دارند را از Mitigationهای Web Shell معرفی می‌کند.

Upload Directory نباید محل اجرای Script باشد

در طراحی امن Application بهتر است فایل Upload شده به شکلی ذخیره شود که از طریق Web Server به‌عنوان Script سمت Server اجرا نشود.

این موضوع بسته به Stack می‌تواند با:

Web Server Configuration
Separate Storage
Object Storage
Non-executable Directory
Strict MIME / Extension Validation

کنترل شود.

File Integrity Monitoring

برای Serverهای حساس بهتر است Web Root Baseline داشته باشد.

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

AIDE
Wazuh
osquery
EDR
Git
Deployment Pipeline

می‌توانند تغییرات غیرمنتظره را سریع‌تر مشخص کنند.

به‌خصوص تغییر فایل PHP در Production بدون Deployment باید قابل شناسایی باشد.

آیا Antivirus کافی است؟

خیر.

Web Shell ممکن است:

• سفارشی باشد.
• Obfuscated باشد.
• فقط چند خط کد باشد.
• داخل فایل قانونی Inject شده باشد.

بنابراین Signature-based Detection باید با موارد زیر ترکیب شود:

File Integrity
Log Analysis
Process Monitoring
Network Monitoring
Application Baseline

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

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

• جستجو فقط برای shell.php
• بررسی نکردن Upload Directory
• اعتماد صرف به Extension فایل
• بررسی فقط mtime
• نادیده گرفتن Owner و Permission
• نتیجه‌گیری صرفاً براساس eval یا base64_decode
• بررسی نکردن Process Tree
• بررسی نکردن Connectionهای شبکه
• نادیده گرفتن Access Log
• بررسی نکردن Logهای Rotate شده
• حذف فوری فایل قبل از حفظ Evidence
• تغییر Permission بدون پیدا کردن Root Cause
• نادیده گرفتن Cron و systemd Persistence
• Rotate نکردن Credentialهای در معرض خطر

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

برای شناسایی و جلوگیری از Web Shell:

• Web Root را Baseline کنید.
• File Integrity Monitoring داشته باشید.
• Deploymentها ثبت و مستند شوند.
• Write Permission را محدود کنید.
• Upload Directory را از Script Execution جدا کنید.
• Uploadها را Validate کنید.
• Apache/Nginx Access Log را نگهداری کنید.
• Logها را به SIEM ارسال کنید.
• Processهای Web Server را مانیتور کنید.
• Child Processهای غیرمنتظره Web Server را Alert کنید.
• Outbound Connectionهای Web Server را Baseline کنید.
• CMS و Pluginها را Patch کنید.
• Admin Accountها را با MFA محافظت کنید.
• Credentialها را Least Privilege نگه دارید.
• Backup سالم و مستقل داشته باشید.

چک‌لیست

هنگام بررسی Web Shell در Linux Server موارد زیر را کنترل کنید:

• Web Root واقعی مشخص شده است.
• فایل‌های اخیر بررسی شده‌اند.
• PHPهای جدید بررسی شده‌اند.
• mtime بررسی شده است.
• ctime بررسی شده است.
• Upload Directoryها مشخص شده‌اند.
• PHP داخل Upload Directory بررسی شده است.
• File Type با Extension مقایسه شده است.
• Owner فایل‌ها بررسی شده است.
• Permissionها بررسی شده‌اند.
• فایل‌های World-Writable بررسی شده‌اند.
• Functionهای مشکوک PHP بررسی شده‌اند.
• Obfuscation Candidateها بررسی شده‌اند.
• فایل‌ها با Baseline مقایسه شده‌اند.
• Hash فایل مشکوک ثبت شده است.
• Process Tree بررسی شده است.
• Processهای Web Server User بررسی شده‌اند.
• Child Processهای غیرمنتظره بررسی شده‌اند.
• Connectionهای شبکه بررسی شده‌اند.
• Apache Access Log بررسی شده است.
• Apache Error Log بررسی شده است.
• Nginx Access Log بررسی شده است.
• Nginx Error Log بررسی شده است.
• Logهای Rotate شده بررسی شده‌اند.
• PHP-FPM Logها بررسی شده‌اند.
• .htaccess بررسی شده است.
• Persistenceهای دیگر بررسی شده‌اند.
• Credential Exposure بررسی شده است.
• Root Cause مشخص شده است.
• Evidence قبل از حذف حفظ شده است.

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

MITRE ATT&CK – Web Shell (T1505.003)
توضیح تکنیک Web Shell، Persistence، Detection Strategy و Mitigationهای مرتبط.

MITRE ATT&CK – Server Software Component
اطلاعات تکمیلی درباره سوءاستفاده از Web Server و Componentهای Server برای Persistence.

Apache HTTP Server – Log Files
مستندات رسمی Access Log، Error Log و نحوه ثبت Requestها در Apache.

Apache HTTP Server – mod_log_config
مستندات CustomLog و LogFormat برای بررسی Configuration مربوط به Access Log.

NGINX – ngx_http_log_module
مستندات رسمی access_log و Format مربوط به Request Logging در Nginx.

NGINX – Core Logging
مستندات error_log و Levelهای ثبت Log در Nginx.

Linux find Manual
مرجع find برای بررسی mtime، ctime، Permission، Owner و سایر ویژگی‌های فایل.

Linux ss Manual
مرجع ابزار ss برای بررسی Socketها و Processهای دارای Connection شبکه.

PHP – File Upload Handling
مستندات رسمی PHP درباره جابه‌جایی فایل‌های دریافت‌شده از HTTP POST Upload.

جمع‌بندی

Web Shell یکی از مهم‌ترین نشانه‌هایی است که می‌تواند پس از Compromise یک Web Application روی Linux Server مشاهده شود.

برای پیدا کردن آن نباید فقط به دنبال فایل‌هایی با نام:

shell.php

باشیم.

اولین قدم مشخص کردن Web Root واقعی و بررسی فایل‌های اخیراً تغییرکرده است:

find /var/www \
-type f \
-mtime -7 \
-ls

سپس PHPهای جدید:

find /var/www \
-type f \
-name "*.php" \
-mtime -7 \
-ls

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

Directoryهای Upload اهمیت ویژه‌ای دارند:

find /var/www \
-type f \
-path "*upload*" \
-name "*.php"

اما File Analysis به‌تنهایی کافی نیست.

باید:

File
+
Owner
+
Permission
+
Timestamp
+
Web Request
+
Process
+
Network

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

Process Tree نیز اهمیت زیادی دارد؛ برای مثال Web Server یا PHP-FPM که بدون دلیل:

bash
sh
curl
wget

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

MITRE نیز در Detection مربوط به Web Shell بر ارتباط میان ایجاد فایل غیرمجاز در Web Directory و اجرای Process یا Utility غیرمنتظره توسط Web Server تأکید می‌کند.

Access Logهای Apache و Nginx نیز کمک می‌کنند مشخص شود چه IPهایی فایل مشکوک را فراخوانی کرده‌اند و فعالیت آن از چه زمانی آغاز شده است.

اگر Web Shell تأیید شد، فقط فایل را حذف نکنید.

ابتدا Evidence را حفظ کنید، Hash و Metadata را ثبت کنید، Logها را نگه دارید، Processها و Connectionهای فعال را بررسی کنید و سپس Root Cause نفوذ را پیدا کنید.

حذف Web Shell بدون رفع آسیب‌پذیری یا Credential Compromise اولیه ممکن است فقط دسترسی فعلی مهاجم را حذف کند و مانع بازگشت او نشود.

کیان پور