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

مقدمه

در بسیاری از Incidentهای امنیتی، دسترسی اولیه مهاجم پایان کار نیست.

پس از نفوذ، مهاجم ممکن است تلاش کند روشی ایجاد کند که حتی بعد از:

• Reboot شدن Server
• بسته شدن Session
• Terminate شدن Process
• تغییر بعضی تنظیمات
• قطع اتصال اولیه

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

به این تکنیک‌ها:

Persistence

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

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

Cron Jobs
systemd Services
systemd Timers
SSH Authorized Keys
User Accounts
sudoers
Shell Startup Files
rc.local
Startup Scripts
at Jobs

MITRE ATT&CK نیز Cron، systemd Timer، systemd Service و SSH Authorized Keys را در میان تکنیک‌هایی قرار می‌دهد که ممکن است برای Persistence مورد سوءاستفاده قرار گیرند.

در این مقاله روش بررسی این نقاط در Linux Server را به‌صورت عملی بررسی می‌کنیم.

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

Persistence چیست؟

فرض کنید مهاجم از طریق یک آسیب‌پذیری Web Application وارد Server شده است.

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

Vulnerable Application
        |
        v
Temporary Access

اگر Server Restart شود یا Vulnerability برطرف شود، مهاجم ممکن است دسترسی خود را از دست بدهد.

بنابراین ممکن است تلاش کند یک Mechanism دیگری ایجاد کند:

Initial Access
      |
      v
Persistence Mechanism
      |
      v
Access After Reboot

برای مثال ممکن است یک Scheduled Job، Service یا SSH Key ناشناس روی سیستم باقی بماند.

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

خیر.

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

برای مثال:

Cron
systemd
SSH Keys
Startup Scripts

بخش طبیعی مدیریت Linux هستند.

مسئله اصلی این است:

آیا این مورد باید روی Server وجود داشته باشد؟

بنابراین Detection باید براساس:

Baseline
Owner
Purpose
File Path
Modification Time
Execution Command
User
Logs

انجام شود.

قبل از هر کاری Evidence را حفظ کنید

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

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

Path
Owner
Permissions
Timestamp
Hash
Content

را ثبت کنید.

برای مثال:

stat /path/to/suspicious-file

و:

sha256sum /path/to/suspicious-file

اگر فایل متنی است:

cat /path/to/suspicious-file

یا:

less /path/to/suspicious-file

سپس می‌توان نسخه‌ای از Evidence تهیه کرد.

مرحله اول: بررسی Cron Jobs

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

هر User می‌تواند Crontab مخصوص خود داشته باشد و Commandهای موجود در Crontab تحت همان User اجرا می‌شوند.

برای مشاهده Cron مربوط به User فعلی:

crontab -l

برای Root:

sudo crontab -l

Cron تمام کاربران را بررسی کنیم

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

cut -d: -f1 /etc/passwd

سپس به‌عنوان Root می‌توان Crontab کاربران را بررسی کرد:

for user in $(cut -f1 -d: /etc/passwd); do
    echo "===== $user ====="
    crontab -u "$user" -l 2>/dev/null
done

در Server Production باید Cron Jobهای فعال Owner و Purpose مشخص داشته باشند.

مسیرهای مهم Cron

فقط crontab -l کافی نیست.

مسیرهای System Cron نیز باید بررسی شوند:

/etc/crontab
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/

مشاهده:

cat /etc/crontab

و:

ls -lah /etc/cron.d/

همچنین:

ls -lah /etc/cron.hourly/
ls -lah /etc/cron.daily/
ls -lah /etc/cron.weekly/
ls -lah /etc/cron.monthly/

Cron Spool را بررسی کنیم

محل Crontabهای کاربران بسته به Distribution متفاوت است.

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

/var/spool/cron/
/var/spool/cron/crontabs/

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

بررسی:

ls -lah /var/spool/cron 2>/dev/null

و:

ls -lah /var/spool/cron/crontabs 2>/dev/null

فایل‌های این بخش معمولاً نباید مستقیماً Edit شوند، اما برای Investigation می‌توان آنها را به‌صورت Read-only بررسی کرد.

@reboot را فراموش نکنید

Cron قابلیت:

@reboot

دارد که Command را پس از Boot اجرا می‌کند. این قابلیت در Crontab مستند شده است.

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

grep -RIn "@reboot" /etc/cron* /var/spool/cron* 2>/dev/null

وجود @reboot لزوماً مخرب نیست.

اما Command مربوط به آن باید بررسی شود.

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

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

• Job ناشناس
• Script در /tmp
• Script در /dev/shm
• Executable داخل Home Directory غیرمنتظره
• Commandی که Network Connection ایجاد می‌کند
• File Name شبیه System Component
• Job متعلق به User غیرمنتظره
• Job تازه ایجادشده
• Job بدون Documentation
• اجرای Script با Root

زمان تغییر Cron Fileها را بررسی کنیم

برای مثال:

find /etc/cron.d /etc/cron.daily /etc/cron.hourly \
-type f -printf '%TY-%Tm-%Td %TH:%TM %u %g %p\n' 2>/dev/null | sort

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

stat /etc/cron.d/example

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

مرحله دوم: بررسی systemd Serviceها

روی Distributionهای جدید Linux، systemd یکی از مهم‌ترین نقاط Persistence است.

Service Unit فایل‌هایی با پسوند:

.service

هستند که Processها را تحت کنترل systemd اجرا می‌کنند.

ابتدا Serviceهای در حال اجرا را ببینید:

systemctl list-units --type=service --state=running

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

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

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

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

به نام Service اعتماد نکنید.

برای مثال نامی مانند:

system-update.service
network-helper.service
security-agent.service

ممکن است قانونی یا ناشناس باشد.

مسیر واقعی Executable اهمیت بیشتری دارد.

محل Unit File را پیدا کنیم

برای یک Service:

systemctl status example.service

سپس:

systemctl show example.service -p FragmentPath

مثلاً:

FragmentPath=/etc/systemd/system/example.service

systemd Unitها می‌توانند از چند مسیر Load شوند؛ از جمله /etc/systemd/system/، /run/systemd/system/ و مسیرهای System Unit مربوط به Distribution.

محتوای Service را بررسی کنیم

روش مناسب:

systemctl cat example.service

به‌خصوص بخش‌هایی مانند:

ExecStart=
User=
WorkingDirectory=
Environment=

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

برای مشاهده بعضی Propertyهای مهم:

systemctl show example.service \
-p FragmentPath \
-p User \
-p ExecStart

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

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

Service ناشناس
+
Enabled
+
Run as root
+
Executable غیرمعمول

یا:

ExecStart=/tmp/...

یا:

ExecStart=/dev/shm/...

یا:

ExecStart=/home/.../.hidden/...

همچنین Unitهای جدید داخل:

/etc/systemd/system/

باید با Change History سرور مقایسه شوند.

Serviceهای جدید را پیدا کنیم

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

find /etc/systemd/system \
-type f -mtime -7 -ls 2>/dev/null

برای جزئیات فایل:

stat /etc/systemd/system/example.service

و Hash:

sha256sum /etc/systemd/system/example.service

Symlinkهای systemd را بررسی کنیم

فعال شدن یک Service معمولاً می‌تواند با Symlinkهایی در Target Directoryها همراه باشد.

مشاهده:

find /etc/systemd/system -type l -ls

همچنین:

systemctl is-enabled example.service

مشخص می‌کند Unit موردنظر Enabled است یا خیر.

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

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

journalctl -u example.service

برای 24 ساعت اخیر:

journalctl -u example.service --since "24 hours ago"

journalctl ابزار استاندارد نمایش Logهای ذخیره‌شده توسط systemd journal است.

مرحله سوم: بررسی systemd Timerها

systemd Timerها می‌توانند مشابه Cron برای اجرای Taskهای زمان‌بندی‌شده استفاده شوند.

Timer Unitها پسوند:

.timer

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

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

systemctl list-timers --all

Timerهای Enabled را بررسی کنیم

systemctl list-unit-files --type=timer --state=enabled

برای هر Timer ناشناس:

systemctl status example.timer

و:

systemctl cat example.timer

سپس Service مرتبط را نیز بررسی کنید:

systemctl cat example.service

Timerهای User-level را فراموش نکنید

systemd فقط Serviceهای System-wide ندارد.

Userها نیز می‌توانند Unitهای خود را داشته باشند.

یکی از مسیرهای مهم:

~/.config/systemd/user/

است. مسیرهای User Unit نیز در مستندات systemd تعریف شده‌اند.

بررسی:

find /root /home \
-path '*/.config/systemd/user/*' \
-type f \
-print 2>/dev/null

برای User فعلی:

systemctl --user list-timers --all

و:

systemctl --user list-unit-files

مرحله چهارم: بررسی SSH Authorized Keys

یکی دیگر از نقاط مهم Persistence:

authorized_keys

است.

به‌صورت پیش‌فرض SSH می‌تواند Public Keyهای مجاز یک User را از:

~/.ssh/authorized_keys

بخواند.

MITRE ATT&CK نیز تغییر SSH Authorized Keys را به‌عنوان یکی از تکنیک‌های Account Manipulation برای Persistence ثبت کرده است.

SSH Keyهای Root را بررسی کنیم

sudo cat /root/.ssh/authorized_keys 2>/dev/null

برای بررسی Metadata:

sudo stat /root/.ssh/authorized_keys

همچنین:

sudo ls -lah /root/.ssh/

SSH Keyهای تمام کاربران را پیدا کنیم

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

برای نمایش Metadata:

find /root /home \
-path '*/.ssh/authorized_keys' \
-type f \
-exec stat {} \; 2>/dev/null

Fingerprint کلیدها را بررسی کنیم

برای مثال:

ssh-keygen -lf /root/.ssh/authorized_keys

این خروجی به مقایسه Keyها با Inventory سازمان کمک می‌کند.

هر SSH Key مدیریتی بهتر است Owner مشخص داشته باشد.

فقط authorized_keys را بررسی نکنید

Configuration واقعی sshd را نیز بررسی کنید:

sshd -T | grep -i authorizedkeys

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

authorizedkeysfile
authorizedkeyscommand

اهمیت دارند.

OpenSSH علاوه بر AuthorizedKeysFile از قابلیت AuthorizedKeysCommand نیز پشتیبانی می‌کند که می‌تواند برای دریافت Keyهای مجاز از یک Program خارجی استفاده شود.

اگر Configuration غیرمعمول مشاهده شد باید دلیل آن مشخص شود.

مرحله پنجم: بررسی Userهای مشکوک

Persistence ممکن است از طریق یک User Account جدید انجام شود.

تمام Accountها:

getent passwd

برای خروجی ساده‌تر:

cut -d: -f1,3,6,7 /etc/passwd

Userهای دارای Shell را بررسی کنیم

برای مثال:

awk -F: '
$7 !~ /(nologin|false|sync|shutdown|halt)$/ {
    print $1, $3, $6, $7
}' /etc/passwd

این خروجی Accountهایی را نشان می‌دهد که Shell آنها به‌وضوح nologin یا false نیست.

اما بسته به Distribution باید Baseline واقعی Server را در نظر گرفت.

Accountهای UID 0 را بررسی کنیم

در Linux، Root معمولاً UID:

0

دارد.

برای پیدا کردن تمام Accountهای دارای UID صفر:

awk -F: '$3 == 0 {print $1 ":" $3 ":" $6 ":" $7}' /etc/passwd

در بیشتر Serverها انتظار داریم فقط:

root

دارای UID صفر باشد.

اگر User دیگری UID 0 دارد، باید فوراً دلیل آن بررسی شود.

زمان تغییر فایل‌های Account را بررسی کنیم

stat /etc/passwd
stat /etc/shadow
stat /etc/group

این Timestampها به‌تنهایی مشخص نمی‌کنند چه Userی ایجاد شده است، اما برای Timeline مفید هستند.

Loginهای اخیر را بررسی کنیم

last

برای نمایش زمان آخرین Login کاربران:

lastlog

در Distributionهایی که Failed Login Database فعال باشد:

lastb

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

مرحله ششم: بررسی sudo و دسترسی Root

ممکن است مهاجم User جدید نسازد اما به یک User موجود دسترسی sudo بدهد.

ابتدا Groupهای مهم را بررسی کنید.

Ubuntu/Debian:

getent group sudo

RHEL/AlmaLinux/Rocky:

getent group wheel

فایل sudoers را بررسی کنیم

sudo less /etc/sudoers

همچنین:

sudo ls -lah /etc/sudoers.d/

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

sudo grep -RIn . /etc/sudoers.d/ 2>/dev/null

فایل‌های جدید یا Ruleهای ناشناخته باید بررسی شوند.

Syntax فایل sudoers را Validate کنیم

بدون تغییر Configuration:

sudo visudo -c

این Command صحت Syntax تنظیمات sudoers را بررسی می‌کند.

Timestamp فایل‌های sudo را بررسی کنیم

stat /etc/sudoers

و:

find /etc/sudoers.d \
-type f \
-printf '%TY-%Tm-%Td %TH:%TM %u %g %p\n' 2>/dev/null

مرحله هفتم: بررسی Shell Startup Fileها

Commandهایی که هنگام Login یا اجرای Shell اجرا می‌شوند نیز می‌توانند نقطه‌ای برای Persistence باشند.

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

/etc/profile
/etc/profile.d/*
/etc/bash.bashrc
/etc/bashrc
~/.profile
~/.bash_profile
~/.bashrc
~/.zshrc

وجود همه این فایل‌ها به Distribution و Shell بستگی دارد.

فایل‌های System-wide را بررسی کنیم

cat /etc/profile

سپس:

ls -lah /etc/profile.d/

برای فایل‌های تازه:

find /etc/profile.d \
-type f \
-mtime -7 \
-ls 2>/dev/null

Startup File کاربران را بررسی کنیم

برای مثال:

find /root /home \
\( -name '.bashrc' \
-o -name '.bash_profile' \
-o -name '.profile' \
-o -name '.zshrc' \) \
-type f \
-print 2>/dev/null

اگر فایل موردنظر اخیراً تغییر کرده است:

stat /home/user/.bashrc

و محتوای آن را بررسی کنید.

دنبال چه رفتارهایی بگردیم؟

داخل Startup Fileها موارد غیرمنتظره مانند:

• اجرای Binary ناشناس
• اجرای Script مخفی
• Network Command غیرضروری
• اجرای فایل از /tmp
• اجرای فایل از /dev/shm
• Background Process ناشناس
• تغییر PATH به Directory غیرقابل اعتماد

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

مرحله هشتم: بررسی rc.local

برخی Serverها همچنان از:

/etc/rc.local

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

بررسی:

ls -lah /etc/rc.local 2>/dev/null

و:

cat /etc/rc.local 2>/dev/null

اگر rc-local Service وجود دارد:

systemctl status rc-local.service

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

SysV Init Scriptها را بررسی کنیم

روی سیستم‌های قدیمی‌تر یا سیستم‌هایی که Compatibility دارند:

ls -lah /etc/init.d/

همچنین:

find /etc/rc*.d -type l -ls 2>/dev/null

Script جدید یا ناشناس در /etc/init.d/ باید با Package Inventory و Change History مقایسه شود.

مرحله نهم: بررسی at Jobs

Linux ابزار:

at

را نیز برای اجرای Job در زمان مشخص ارائه می‌کند و MITRE ATT&CK نیز سوءاستفاده از آن را در Scheduled Task/Job پوشش می‌دهد.

برای مشاهده Jobهای موجود:

atq

برای Root:

sudo atq

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

مرحله دهم: بررسی فایل‌های Dynamic Loader

یکی از نقاط حساس‌تر Linux:

/etc/ld.so.preload

است.

اگر این فایل وجود دارد، ابتدا فقط آن را بررسی کنید:

ls -lah /etc/ld.so.preload 2>/dev/null

و:

cat /etc/ld.so.preload 2>/dev/null

هر Library ناشناخته‌ای که در این فایل تعریف شده باشد باید به‌دقت بررسی شود.

برای فایل Library:

stat /path/to/library.so

و:

sha256sum /path/to/library.so

به دلیل حساسیت Dynamic Loader، تغییر این قسمت نباید بدون Change Record مشخص وجود داشته باشد.

مرحله یازدهم: بررسی PAM

PAM مسئول بخش مهمی از Authentication در Linux است.

Configuration معمولاً در:

/etc/pam.d/

قرار دارد.

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

find /etc/pam.d \
-type f \
-printf '%TY-%Tm-%Td %TH:%TM %u %g %p\n' 2>/dev/null | sort

اگر یکی از فایل‌ها اخیراً و بدون Change Plan تغییر کرده باشد، باید بررسی شود.

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

برای مشاهده Moduleهای Load شده:

lsmod

Configuration مربوط به Moduleهایی که در Boot Load می‌شوند می‌تواند در مسیرهایی مانند:

/etc/modules
/etc/modules-load.d/

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

بررسی:

cat /etc/modules 2>/dev/null

و:

ls -lah /etc/modules-load.d/ 2>/dev/null

هر Module ناشناخته باید با Package و Kernel Baseline سیستم مقایسه شود.

Processهای فعلی را بررسی کنیم

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

برای مشاهده Process Tree:

ps auxf

یا:

pstree -ap

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

Unknown Process
Unexpected Parent
Root Process
Executable from unusual path
External Network Connection

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

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

ss -plant

برای UDP:

ss -planu

اگر Process مربوط به Service یا Job ناشناس به IP خارجی متصل است، Investigation باید ادامه پیدا کند.

Executable واقعی Process را پیدا کنیم

فرض کنیم PID مشکوک:

6240

است.

مسیر Executable:

readlink -f /proc/6240/exe

Command Line:

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

Parent PID:

grep PPid /proc/6240/status

Working Directory:

readlink -f /proc/6240/cwd

این اطلاعات برای مشخص کردن منشأ Process بسیار مفید هستند.

فایل‌های تازه ایجادشده در مسیرهای Persistence

می‌توان چند مسیر مهم را همزمان بررسی کرد:

find \
/etc/systemd/system \
/etc/cron.d \
/etc/profile.d \
/etc/sudoers.d \
-type f \
-mtime -7 \
-ls 2>/dev/null

عدد:

7

یعنی فایل‌هایی که در هفت روز اخیر Modification داشته‌اند.

بازه را براساس Timeline Incident تغییر دهید.

فایل‌های مشکوک در /tmp و /dev/shm

این Directoryها به‌طور طبیعی فایل دارند، اما Executable یا Script ناشناس در آنها می‌تواند نیازمند بررسی باشد.

find /tmp /dev/shm \
-type f \
-mtime -7 \
-ls 2>/dev/null

فقط براساس وجود فایل نتیجه‌گیری نکنید.

باید Owner، Hash، Process و Usage آن را بررسی کنید.

Logهای Cron را بررسی کنیم

روی Ubuntu/Debian ممکن است Cron Activity در:

/var/log/syslog

دیده شود.

برای مثال:

grep CRON /var/log/syslog 2>/dev/null | tail -100

روی بعضی Distributionهای RHEL-based:

grep CROND /var/log/cron 2>/dev/null | tail -100

با systemd نیز می‌توان از Journal استفاده کرد:

journalctl --since "24 hours ago" | grep -i cron

Logهای SSH را بررسی کنیم

Ubuntu/Debian:

grep sshd /var/log/auth.log 2>/dev/null | tail -100

RHEL/AlmaLinux/Rocky:

grep sshd /var/log/secure 2>/dev/null | tail -100

یا:

journalctl -u ssh --since "24 hours ago"

و بسته به Distribution:

journalctl -u sshd --since "24 hours ago"

اگر SSH Key ناشناس پیدا کردید، Loginهای مربوط به همان User و Source IP را نیز بررسی کنید.

auditd چه کمکی می‌کند؟

اگر Linux Audit قبلاً روی Server فعال و Ruleهای مناسب تعریف شده باشند، می‌توان تغییرات فایل‌ها و Accountها را بهتر بررسی کرد.

ابزار:

ausearch

برای جستجو در Audit Eventها استفاده می‌شود و معمولاً داده‌های /var/log/audit/audit.log را Query می‌کند.

برای مثال بررسی تغییرات Account:

ausearch -m ADD_USER,DEL_USER,ADD_GROUP,DEL_GROUP -i

اما نکته مهم این است:

auditd فقط Eventهایی را نشان می‌دهد که در زمان وقوع قابل ثبت بوده‌اند؛ فعال کردن Auditing بعد از Incident، Eventهای گذشته را ایجاد نمی‌کند.

برای آینده مسیرهای حساس را Audit کنیم

در Serverهای حساس می‌توان تغییرات نقاط Persistence را مانیتور کرد.

مثلاً با Policy مناسب Audit Framework سازمان می‌توان مسیرهایی مانند:

/etc/systemd/system/
/etc/cron.d/
/etc/sudoers.d/
/root/.ssh/
/etc/ssh/

را تحت File Integrity Monitoring قرار داد.

برای محیط Production ابزارهایی مانند:

auditd
Wazuh
AIDE
osquery
EDR
SIEM

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

Package Integrity را بررسی کنیم

اگر فایل سیستمی مشکوک است، بررسی کنید متعلق به کدام Package است.

Ubuntu / Debian

dpkg -S /path/to/file

بررسی Package Fileها:

dpkg -V package-name

در صورت استفاده از debsums نیز می‌توان Integrity فایل‌های Package را بررسی کرد.

AlmaLinux / Rocky / RHEL

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

rpm -qf /path/to/file

بررسی Integrity Package:

rpm -V package-name

اگر فایل سیستمی تغییر کرده است، نتیجه را با Updateها و Change History مقایسه کنید.

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

اگر احتمال Compromise وجود دارد، می‌توان بررسی را با این ترتیب انجام داد.

مرحله 1: Process و Network

ps auxf

ss -plant

مرحله 2: Cron

crontab -l

sudo crontab -l

ls -lah /etc/cron.d/

مرحله 3: systemd Services

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

systemctl list-units --type=service --state=running

مرحله 4: systemd Timers

systemctl list-timers --all

مرحله 5: SSH Keys

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

مرحله 6: Userها

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

getent passwd

مرحله 7: sudo

getent group sudo

یا:

getent group wheel

سپس:

ls -lah /etc/sudoers.d/

مرحله 8: Shell Startup

find /root /home \
\( -name '.bashrc' \
-o -name '.bash_profile' \
-o -name '.profile' \
-o -name '.zshrc' \) \
-type f \
-print 2>/dev/null

مرحله 9: at

atq

مرحله 10: Recent Changes

find \
/etc/systemd/system \
/etc/cron.d \
/etc/profile.d \
/etc/sudoers.d \
-type f \
-mtime -7 \
-ls 2>/dev/null

یک Command خلاصه برای بررسی اولیه

می‌توان چند مورد اصلی را پشت سر هم نمایش داد:

echo "=== RUNNING SERVICES ==="
systemctl list-units --type=service --state=running

echo
echo "=== ENABLED SERVICES ==="
systemctl list-unit-files --type=service --state=enabled

echo
echo "=== TIMERS ==="
systemctl list-timers --all

echo
echo "=== ROOT CRON ==="
crontab -u root -l 2>/dev/null

echo
echo "=== UID 0 USERS ==="
awk -F: '$3 == 0 {print}' /etc/passwd

echo
echo "=== SSH AUTHORIZED KEYS ==="
find /root /home -path '*/.ssh/authorized_keys' -type f -print 2>/dev/null

echo
echo "=== AT JOBS ==="
atq 2>/dev/null

این دستورات فقط برای Inventory اولیه هستند و چیزی را از سیستم حذف نمی‌کنند.

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

به‌طور کلی ترکیب چند مورد از نشانه‌های زیر اهمیت بیشتری دارد:

Recently Created Service
+
Runs as root
+
Executable in /tmp
+
Unknown Owner
+
External Connection

یا:

Unknown SSH Key
+
Root Account
+
Recent Login
+
Unknown Source IP

یا:

New Cron Job
+
@reboot
+
Hidden Script
+
Network Activity

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

فایل یا Service مشکوک پیدا کردیم؛ چه کنیم؟

فوراً:

rm

نکنید.

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

مثلاً:

stat /path/to/file

sha256sum /path/to/file

file /path/to/file

اگر Process در حال اجرا است:

ps -fp PID

readlink -f /proc/PID/exe

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

و Network:

ss -plant

را ثبت کنید.

حذف فوری Persistence چه مشکلی دارد؟

اگر بلافاصله Service یا Cron Job را حذف کنید ممکن است بخشی از Evidence را از بین ببرید.

در Incident مهم ابتدا باید مشخص شود:

• چه زمانی ایجاد شده؟
• چه Userی آن را ایجاد کرده؟
• چه چیزی را اجرا می‌کند؟
• Executable کجاست؟
• به چه IPهایی متصل شده؟
• چه Credentialهایی درگیر بوده‌اند؟
• Initial Access چه بوده است؟

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

هدف پیدا کردن:

Root Cause

است.

بعد از تأیید Compromise

پس از حفظ Evidence و مشخص شدن Scope، ممکن است لازم باشد:

• Host ایزوله شود.
• Persistence Mechanism غیرفعال شود.
• Process مخرب متوقف شود.
• SSH Key غیرمجاز Revoked شود.
• Account غیرمجاز Disable شود.
• Passwordها Rotate شوند.
• API Tokenها Rotate شوند.
• SSH Keyهای مدیریتی بررسی شوند.
• Vulnerability اولیه Patch شود.
• Web Application بررسی شود.
• Server از Backup سالم Restore شود.

اگر اعتماد به Integrity سیستم از بین رفته باشد، در Incidentهای جدی Rebuild کردن Server از Image سالم می‌تواند از پاک‌سازی دستی قابل‌اعتمادتر باشد.

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

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

• بررسی فقط Cron
• بررسی نکردن systemd Timer
• بررسی نکردن User-level systemd
• اعتماد به نام Service
• بررسی نکردن ExecStart
• نادیده گرفتن SSH Authorized Keys
• بررسی فقط Root
• بررسی نکردن sudoers
• نادیده گرفتن Shell Startup Fileها
• بررسی نکردن at Jobها
• حذف فوری Evidence
• نتیجه‌گیری فقط براساس Timestamp
• بررسی نکردن Processهای فعال
• بررسی نکردن Network Connection
• پیدا نکردن Initial Access و Root Cause

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

برای کاهش خطر Persistence در Linux:

• Serviceهای Enabled را Baseline کنید.
• Cron Jobها را مستندسازی کنید.
• SSH Key Inventory داشته باشید.
• Root Login Policy مشخص داشته باشید.
• Userهای قدیمی را حذف یا Disable کنید.
• sudo Access را محدود کنید.
• /etc/systemd/system را مانیتور کنید.
• /etc/cron.d را مانیتور کنید.
• /etc/sudoers.d را مانیتور کنید.
• SSH Configuration را مانیتور کنید.
• File Integrity Monitoring استفاده کنید.
• Audit Logging را فعال کنید.
• Logها را به Server مرکزی یا SIEM ارسال کنید.
• Outbound Network Traffic را مانیتور کنید.
• Patch Management داشته باشید.
• Least Privilege را رعایت کنید.

چک‌لیست

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

• Processهای فعال بررسی شده‌اند.
• Connectionهای شبکه بررسی شده‌اند.
• Root Crontab بررسی شده است.
• Crontab تمام Userها بررسی شده است.
• /etc/crontab بررسی شده است.
• /etc/cron.d بررسی شده است.
• @reboot بررسی شده است.
• Serviceهای Enabled بررسی شده‌اند.
• Serviceهای Running بررسی شده‌اند.
• Unit Fileهای جدید بررسی شده‌اند.
• ExecStart Serviceهای ناشناس بررسی شده است.
• systemd Timerها بررسی شده‌اند.
• User-level systemd Unitها بررسی شده‌اند.
• SSH Authorized Keys تمام Userها بررسی شده‌اند.
• SSH Configuration بررسی شده است.
• Userهای دارای UID 0 بررسی شده‌اند.
• Userهای جدید بررسی شده‌اند.
• sudo و wheel Group بررسی شده‌اند.
• /etc/sudoers.d بررسی شده است.
• Shell Startup Fileها بررسی شده‌اند.
• rc.local بررسی شده است.
• at Jobها بررسی شده‌اند.
• /etc/ld.so.preload بررسی شده است.
• PAM Configuration بررسی شده است.
• Kernel Moduleهای غیرمنتظره بررسی شده‌اند.
• فایل‌های Recent در مسیرهای Persistence بررسی شده‌اند.
• Login Logها بررسی شده‌اند.
• Package Integrity بررسی شده است.
• Evidence قبل از حذف فایل‌ها ثبت شده است.
• Root Cause مشخص شده است.

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

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

MITRE ATT&CK – Persistence
تکنیک‌ها و Sub-techniqueهای مرتبط با Persistence در سیستم‌های Enterprise. MITRE ATT&CK – Persistence

MITRE ATT&CK – Cron
بررسی سوءاستفاده از Cron برای Scheduled Execution و Persistence. MITRE ATT&CK – Cron

MITRE ATT&CK – Systemd Timers
اطلاعات مربوط به استفاده از systemd Timerها در Persistence. MITRE ATT&CK – Systemd Timers

MITRE ATT&CK – SSH Authorized Keys
بررسی تغییر Authorized Keys برای حفظ دسترسی SSH. MITRE ATT&CK – SSH Authorized Keys

Linux Manual – systemd.unit
مستندات Unit Fileها و مسیرهای Load شدن Unitهای systemd. systemd.unit Manual

Linux Manual – systemd.service
مستندات رسمی ساختار systemd Service Unitها. systemd.service Manual

Linux Manual – systemd.timer
مستندات Timer Unitهای systemd. systemd.timer Manual

Linux Manual – crontab
ساختار Crontab و نحوه عملکرد Scheduled Jobهای Cron. crontab Manual

OpenSSH – sshd_config
مستندات AuthorizedKeysFile، AuthorizedKeysCommand و تنظیمات SSH Server. sshd_config Manual

Linux Manual – journalctl
مستندات بررسی Logهای systemd Journal. journalctl Manual

جمع‌بندی

Persistence در Linux محدود به یک مکان خاص نیست.

مهاجم ممکن است برای حفظ دسترسی از مکانیزم‌های قانونی سیستم مانند:

Cron
systemd
SSH
User Accounts
sudo
Startup Scripts

سوءاستفاده کند.

به همین دلیل بررسی Persistence باید از چند بخش انجام شود.

برای Cron:

crontab -l

و:

ls -lah /etc/cron.d/

برای Serviceها:

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

برای Timerها:

systemctl list-timers --all

برای SSH Keyها:

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

و برای Accountهای دارای UID صفر:

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

نقاط دیگری مانند:

/etc/sudoers.d
/etc/profile.d
/etc/rc.local
/etc/ld.so.preload
/etc/pam.d
~/.config/systemd/user

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

اما پیدا کردن یک Cron Job یا Service ناشناس به‌تنهایی اثبات Compromise نیست.

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

File
Owner
Timestamp
Hash
Process
Parent Process
Network Connection
Logs

در کنار یکدیگر تحلیل شوند.

اگر Persistence مشکوکی پیدا شد، قبل از حذف آن Evidence را حفظ کنید و سپس Initial Access را پیدا کنید؛ زیرا حذف Persistence بدون برطرف کردن Root Cause ممکن است فقط دسترسی فعلی مهاجم را قطع کند و مانع نفوذ مجدد نشود.

کیان پور