بعد از Hack شدن چه کار کنیم؟ راهنمای جامع واکنش به هک سایت، سامانه، نرم‌افزار و حساب‌های کاربری

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

نوع واکنش پس از Hack نیز به سطح حادثه بستگی دارد. Hack یک حساب شبکه اجتماعی با نفوذ به سامانه مالی، آلوده شدن سرور به باج‌افزار یا نشت گسترده اطلاعات کاربران یکسان نیست. بااین‌حال، تقریباً تمام رخدادهای امنیتی باید با یک فرآیند مشخص مدیریت شوند:

1. تشخیص حادثه
2. حفظ شواهد
3. مهار نفوذ
4. تعیین دامنه خسارت
5. حذف عامل نفوذ
6. بازیابی امن
7. نظارت و جلوگیری از تکرار حادثه

در این مقاله، اقدامات بعد از Hack شدن را در چند سطح بررسی می‌کنیم: هک سایت، هک سامانه و سرور، هک نرم‌افزار و اپلیکیشن، سرقت حساب‌های کاربری، باج‌افزار، نشت اطلاعات، نفوذ به زیرساخت ابری و حملات زنجیره تأمین.

هشدار مهم:

اولین واکنش بسیاری از مدیران، حذف فوری فایل‌های آلوده یا نصب مجدد سیستم است. این اقدام ممکن است شواهد مهم را از بین ببرد و تشخیص مسیر ورود مهاجم را غیرممکن کند. قبل از پاک‌سازی، در صورت امکان از وضعیت فعلی سیستم، لاگ‌ها، حافظه، فایل‌ها و پایگاه داده نسخه شواهد تهیه کنید.

هک شدن دقیقاً به چه معناست؟

یک سیستم زمانی Hack شده یا دچار رخداد امنیتی شده است که شخص یا برنامه‌ای بدون مجوز بتواند به بخشی از اطلاعات، حساب‌ها، فایل‌ها، سرویس‌ها یا منابع آن دسترسی پیدا کند.

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

• دسترسی غیرمجاز به پنل مدیریت سایت
• اجرای کد مخرب روی سرور
• تزریق کد به دیتابیس یا صفحات سایت
• سرقت رمز عبور، توکن یا کلید API
• تغییر یا حذف اطلاعات
• استخراج اطلاعات کاربران
• نصب بدافزار، وب‌شل یا در پشتی(Backdoor)
• رمزگذاری اطلاعات توسط باج‌افزار
• تصاحب ایمیل یا حساب شبکه اجتماعی
• دست‌کاری نرم‌افزار یا فرایند انتشار آن
• نفوذ به فضای ابری، کانتینرها یا مخازن کد
• سوءاستفاده از دستگاه‌های شبکه، دوربین‌ها یا تجهیزات هوشمند

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

 اقدامات فوری بعد از هک شدن

۱. آرامش خود را حفظ کرده و رخداد را ثبت کنید

پیش از ایجاد تغییرات، اطلاعات اولیه را یادداشت کنید:

• حادثه چه زمانی کشف شد؟
• چه کسی آن را گزارش کرده است؟
• اولین نشانه چه بود؟
• چه سامانه‌هایی تحت تأثیر هستند؟
• چه تغییراتی اخیراً انجام شده است؟
• آیا اخطار امنیتی از هاست، آنتی‌ویروس یا سرویس ابری دریافت شده است؟
• آیا اطلاعات کاربران یا اطلاعات محرمانه در معرض خطر قرار گرفته‌اند؟

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

۲. سیستم آلوده را مهار کنید

مهار به معنی جلوگیری از ادامه فعالیت مهاجم است. بسته به نوع حادثه، اقدامات مهار می‌تواند شامل موارد زیر باشد:

• قراردادن موقت سایت در حالت تعمیر
• محدودکردن دسترسی به IPهای مورد اعتماد
• قطع ارتباط سیستم آلوده از شبکه
• متوقف‌کردن موقت یک سرویس آسیب‌پذیر
• غیرفعال‌کردن حساب‌های مشکوک
• لغو نشست‌ها و توکن‌های فعال
• مسدودکردن کلیدهای API لو رفته
• جداسازی سرور یا کانتینر آلوده
• جلوگیری از ارتباط بدافزار با اینترنت

خاموش‌کردن ناگهانی سیستم همیشه بهترین گزینه نیست. در رخدادهای مهم، اطلاعات موجود در حافظه می‌تواند برای تحلیل حادثه ضروری باشد. اگر تیم پاسخ‌گویی به رخداد دارید، پیش از خاموش‌کردن سرور با آن هماهنگ شوید.

۳. شواهد را حفظ کنید

حداقل از موارد زیر نسخه تهیه کنید:

• لاگ وب‌سرور
• لاگ سیستم‌عامل
• لاگ ورود کاربران
• لاگ اپلیکیشن
• لاگ دیتابیس
• فایل‌های سایت
• پایگاه داده
• تنظیمات فایروال و شبکه
• فهرست پردازش‌های در حال اجرا
• فهرست اتصال‌های شبکه
• زمان آخرین تغییر فایل‌ها
• گزارش سرویس‌های ابری
• هش فایل‌های مشکوک

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

sha256sum suspicious-file.php

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

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

ps auxf > processes.txt
ss -plant > network-connections.txt

این فایل‌ها باید در مکانی امن و ترجیحاً خارج از سیستم آلوده نگهداری شوند. دسترسی به شواهد را محدود و تمام جابه‌جایی‌های آن‌ها را ثبت کنید.

۴. رمزها را از یک دستگاه سالم تغییر دهید

تغییر رمز عبور از همان رایانه یا سرور آلوده خطرناک است؛ زیرا بدافزار می‌تواند رمز جدید را نیز ثبت کند. از یک دستگاه سالم برای تغییر این موارد استفاده کنید:

• رمز ایمیل اصلی
• حساب مدیر سایت
• پنل هاست
• حساب ثبت‌کننده دامنه
• حساب‌های ابری
• SSH و FTP/SFTP
• دیتابیس
• مخزن کد
• حساب‌های مالی
• سرویس ارسال ایمیل
• پنل پیامک
• کلیدهای API
• کلیدهای رمزنگاری و امضای دیجیتال

نکته: فقط تغییر رمز کافی نیست. تمام نشست‌های فعال، کوکی‌ها، توکن‌ها، رمزهای اپلیکیشن و کلیدهای دسترسی قبلی نیز باید باطل شوند.

سطح اول: بعد از هک سایت چه کار کنیم؟

Hack سایت، به‌خصوص سایت‌های وردپرسی، یکی از متداول‌ترین رخدادهای امنیتی است. نشانه‌های آن می‌تواند شامل انتقال کاربران به سایت‌های ناشناس، نمایش تبلیغات، ایجاد صفحات اسپم، ارسال ایمیل انبوه، هشدار مرورگر یا اضافه‌شدن مدیر ناشناس باشد.

سایت را موقتاً محدود کنید

اگر سایت در حال توزیع بدافزار یا سرقت اطلاعات کاربران است، ادامه فعالیت آن خسارت را بیشتر می‌کند. سایت را موقتاً از دسترس عمومی خارج کنید یا فقط دسترسی IP تیم فنی را مجاز نگه دارید.

در Nginx می‌توان به‌صورت موقت دسترسی را محدود کرد:

location / {
allow 203.0.113.10;
deny all;
try_files $uri $uri/ /index.php?$args;
}

پس از پایان بررسی، این محدودیت باید برداشته شود. IP نمونه را با IP واقعی تیم فنی جایگزین کنید.

فایل‌های تغییریافته را پیدا کنید

برای مشاهده فایل‌های PHP که در هفت روز گذشته تغییر کرده‌اند:

find /var/www/html -type f -name "*.php" -mtime -7 -print

این دستور اثبات نمی‌کند که فایل‌ها آلوده هستند، اما دامنه بررسی را محدود می‌کند. تاریخ فایل نیز قابل اعتماد مطلق نیست؛ زیرا مهاجم می‌تواند زمان آن را دست‌کاری کند.

در وردپرس، یکپارچگی فایل‌های هسته را می‌توان با WP-CLI بررسی کرد:

wp core verify-checksums

برای افزونه‌هایی که از مخزن رسمی وردپرس نصب شده‌اند:

wp plugin verify-checksums --all

هشدارها را بررسی کنید، اما فایل را صرفاً به دلیل ناشناخته‌بودن حذف نکنید. افزونه‌های تجاری یا سفارشی ممکن است checksum رسمی نداشته باشند.

 حساب‌های مدیر را بررسی کنید

فهرست مدیران وردپرس را مشاهده کنید:

wp user list --role=administrator

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

 دیتابیس را فراموش نکنید

پاک‌کردن فایل‌ها به‌تنهایی کافی نیست. کد مخرب ممکن است در دیتابیس، ابزارک‌ها، تنظیمات افزونه‌ها یا محتوای نوشته‌ها ذخیره شده باشد.

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

• کاربران مدیر
• آدرس سایت و خانه وردپرس
• وظایف زمان‌بندی‌شده
• محتوای جاوااسکریپت ناشناس
• صفحات و نوشته‌های اسپم
• تنظیمات افزونه‌ها
• جدول‌های ناشناخته
• رکوردهای اخیراً تغییریافته

از اجرای دستورهای گسترده `DELETE` یا `REPLACE` روی دیتابیس بدون نسخه پشتیبان خودداری کنید؛ زیرا ممکن است اطلاعات سالم نیز از بین برود.

 فایل‌های سالم را جایگزین کنید

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

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

wp-config.php
.htaccess
index.php
wp-settings.php
wp-includes/
wp-admin/
wp-content/uploads/
wp-content/mu-plugins/

وجود فایل PHP در پوشه `uploads` معمولاً مشکوک است، هرچند باید قبل از حذف بررسی شود.

کلیدهای امنیتی وردپرس را تغییر دهید

پس از نفوذ، کلیدهای `AUTH_KEY`، `SECURE_AUTH_KEY` و سایر Saltهای وردپرس را تغییر دهید. این کار نشست‌های موجود را بی‌اعتبار می‌کند.

همچنین رمز دیتابیس را تغییر دهید و مقدار جدید را در `wp-config.php` قرار دهید.

 سطح دوم: هک هاست، سرور یا سامانه سازمانی

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

سطح دسترسی مهاجم را مشخص کنید

باید مشخص شود مهاجم به کدام سطح رسیده است:

• فقط یک حساب کاربری
• حساب سرویس وب
• حساب دارای دسترسی `sudo`
• کاربر `root`
• پنل مدیریت سرور
• کنترل‌پنل هاست
• هایپروایزر یا زیرساخت مجازی‌سازی
• سرویس پشتیبان‌گیری
• حساب ابری

اگر دسترسی `root` یا Administrator تأیید شده باشد، اعتماد به سیستم‌عامل فعلی منطقی نیست. مهاجم می‌تواند سرویس، کاربر، کرنل ماژول، وظیفه زمان‌بندی‌شده یا در پشتی پنهان ایجاد کرده باشد. روش مطمئن‌تر، ساخت سرور جدید از یک منبع سالم و انتقال کنترل‌شده اطلاعات است.

 لاگ‌های ورود را بررسی کنید

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

/var/log/auth.log
/var/log/secure
/var/log/syslog
/var/log/messages
/var/log/nginx/
/var/log/apache2/

برای مشاهده ورودهای ثبت‌شده:

last -a

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

lastb -a

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

journalctl _COMM=sudo

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

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

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

getent passwd
sudo find /root /home -name authorized_keys -type f -print
sudo systemctl list-unit-files --state=enabled
sudo crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily

کلید SSH ناشناس، کاربر جدید، سرویس غیرمنتظره یا Cron Job نامعتبر می‌تواند نشان‌دهنده پایداری مهاجم در سیستم باشد.

از بازگردانی کورکورانه بکاپ خودداری کنید

ممکن است نسخه پشتیبان نیز آلوده باشد. ابتدا باید زمان تقریبی شروع نفوذ مشخص شود و بکاپی انتخاب شود که قبل از آن تاریخ تهیه شده باشد.

بازیابی باید در محیط جداگانه انجام شود. پس از اسکن و بررسی، اطلاعات لازم به زیرساخت جدید منتقل شود.

هشدار ویژه برای هاست اشتراکی

در هاست اشتراکی معمولاً به لاگ کامل سیستم‌عامل، پردازش‌ها، تنظیمات امنیتی و شواهد سطح سرور دسترسی ندارید. بنابراین نمی‌توانید به‌تنهایی سالم‌بودن کل سرور را تأیید کنید.

پس از مشاهده Hack در هاست اشتراکی:

• بلافاصله یک تیکت امنیتی با اولویت بالا ثبت کنید.
• زمان مشاهده حادثه را دقیق اعلام کنید.
• درخواست حفظ لاگ‌ها و شواهد کنید.
• از شرکت میزبان بخواهید دامنه نفوذ را بررسی کند.
• بپرسید آیا حساب دیگری روی همان سرور آلوده شده است.
• رمز پنل، FTP، ایمیل و دیتابیس را از دستگاه سالم تغییر دهید.
• تمام حساب‌های FTP قدیمی را حذف کنید.
• نسخه PHP و نرم‌افزارهای سایت را به‌روزرسانی کنید.
• دسترسی فایل‌ها و مالکیت آن‌ها را بررسی کنید.
• از بکاپ آلوده برای بازگردانی مستقیم استفاده نکنید.

در هاست اشتراکی اجرای اسکریپت‌های اسکن سنگین، دستورهای `find` گسترده یا ابزارهای مصرف‌کننده CPU ممکن است باعث تعلیق حساب شود. قبل از اجرای اسکن کامل با پشتیبانی هاست هماهنگ کنید.

اگر آلودگی چند بار تکرار می‌شود و شرکت میزبان گزارش فنی قابل قبولی ارائه نمی‌کند، انتقال به محیطی با جداسازی بهتر، لاگ‌های کامل‌تر و کنترل امنیتی بیشتر باید بررسی شود.

سطح سوم: هک نرم‌افزار و اپلیکیشن

Hack اپلیکیشن ممکن است از طریق SQL Injection، تزریق فرمان، آپلود فایل، دورزدن احراز هویت، آسیب‌پذیری API یا افشای کلیدهای محرمانه رخ دهد.

فقط آسیب‌پذیری را Patch نکنید

فرض کنید یک API به دلیل SQL Injection آسیب‌پذیر بوده است. اصلاح Query مشکل آینده را کاهش می‌دهد، اما پاسخ کامل به حادثه نیست. ابتدا باید مشخص شود:

• مهاجم چه درخواست‌هایی ارسال کرده است؟
• چه داده‌هایی مشاهده یا استخراج شده‌اند؟
• آیا اطلاعات تغییر کرده‌اند؟
• آیا حساب جدیدی ساخته شده است؟
• آیا رمزها یا توکن‌ها سرقت شده‌اند؟
• آیا مهاجم توانسته کد اجرا کند؟
• آیا سیستم‌های دیگر نیز با همان کلیدها قابل دسترسی هستند؟

نمونه ناامن:

$sql = "SELECT * FROM users WHERE email = '" . $_GET['email'] . "'";
$result = $pdo->query($sql);

نمونه اصلاح‌شده با Prepared Statement:

$stmt = $pdo->prepare(
'SELECT id, email, name FROM users WHERE email = :email'
);

$stmt->execute([
'email' => $_GET['email'],
]);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

پس از اصلاح کد، باید کلیدهای دیتابیس، توکن‌ها و حساب‌های دارای دسترسی به اطلاعات حساس نیز بازبینی و در صورت لزوم تعویض شوند.

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

اگر اپلیکیشن منتشرشده آلوده است، موارد زیر را کنترل کنید:

• مخزن Git
• حساب توسعه‌دهندگان
• Personal Access Tokenها
• Runnerهای CI/CD
• Secretهای Pipeline
• رجیستری پکیج و کانتینر
• سرور Build
• گواهی امضای نرم‌افزار
• فایل‌های خروجی منتشرشده

در صورت آلوده‌شدن زنجیره ساخت، صرفاً انتشار نسخه جدید کافی نیست. ابتدا باید محیط Build از نو ساخته، دسترسی‌ها چرخانده و صحت تاریخچه کد و وابستگی‌ها بررسی شود.

سطح چهارم: هک حساب کاربری، ایمیل یا شبکه اجتماعی

تصاحب ایمیل معمولاً از Hack یک حساب عادی خطرناک‌تر است؛ زیرا ایمیل مسیر بازیابی رمز سایر سرویس‌ها محسوب می‌شود.

اقدامات ضروری عبارت‌اند از:

1. رمز حساب را از دستگاه سالم تغییر دهید.
2. احراز هویت دومرحله‌ای را فعال کنید.
3. همه نشست‌های فعال را ببندید.
4. روش‌های بازیابی را بررسی کنید.
5. ایمیل و شماره تلفن ناشناس را حذف کنید.
6. قوانین Forwarding و Filterها را کنترل کنید.
7. برنامه‌های متصل و OAuth Appها را بازبینی کنید.
8. پوشه Sent، Trash و Archive را بررسی کنید.
9. به مخاطبانی که پیام جعلی دریافت کرده‌اند اطلاع دهید.
10. رمز سرویس‌هایی را که از همان رمز استفاده می‌کردند تغییر دهید.

مهاجم ممکن است یک قانون مخفی برای ارسال نسخه تمام ایمیل‌ها به آدرس دیگری ایجاد کرده باشد. بنابراین تغییر رمز بدون بررسی تنظیمات Forwarding کافی نیست.

 سطح پنجم: حمله باج‌افزاری

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

اقدامات اولیه:

• سیستم‌های آلوده را از شبکه جدا کنید.
• اشتراک‌های شبکه را موقتاً غیرفعال کنید.
• از اتصال هارد بکاپ سالم به سیستم آلوده خودداری کنید.
• پیام باج، پسوند فایل‌ها و زمان حادثه را ثبت کنید.
• لاگ‌های VPN، Active Directory و سرویس‌های راه دور را حفظ کنید.
• سلامت و تاریخ بکاپ‌ها را بررسی کنید.
• احتمال استخراج اطلاعات را جدی بگیرید.
• موضوع را با تیم امنیت، مدیریت، بیمه و مشاور حقوقی هماهنگ کنید.

پرداخت باج تضمینی برای بازگشت اطلاعات یا حذف نسخه سرقت‌شده نیست. تصمیم‌گیری درباره آن باید با ارزیابی فنی، حقوقی و مدیریتی انجام شود.

سطح ششم: نشت یا سرقت اطلاعات

اگر احتمال می‌دهید اطلاعات کاربران استخراج شده است، باید نوع و حساسیت داده‌ها مشخص شود:

• نام و اطلاعات تماس
• رمزهای عبور
• اطلاعات هویتی
• سوابق مالی
• اطلاعات پزشکی
• فایل‌های سازمانی
• توکن‌ها و کلیدهای دسترسی
• اطلاعات کارت بانکی
• مکاتبات محرمانه

اگر رمز عبور کاربران به‌صورت متن ساده یا با الگوریتم ضعیف ذخیره شده باشد، باید بازنشانی اجباری رمز انجام شود. حتی در صورت استفاده از الگوریتم مناسب مانند Argon2id یا bcrypt، ممکن است با توجه به شدت نشت، بازنشانی رمز ضروری باشد.

اطلاع‌رسانی به کاربران باید دقیق، شفاف و بدون ادعای تأییدنشده باشد. بهتر است شامل این موارد باشد:

• چه اتفاقی افتاده است؟
• حادثه چه زمانی کشف شده است؟
• چه اطلاعاتی احتمالاً درگیر بوده‌اند؟
• چه اقداماتی انجام شده است؟
• کاربر باید چه کاری انجام دهد؟
• مسیر ارتباطی برای دریافت اطلاعات بیشتر چیست؟

الزامات گزارش رخداد و اطلاع‌رسانی به افراد، بسته به کشور، صنعت، قراردادها و نوع داده متفاوت است. این بخش باید با مشاور حقوقی و مسئول حفاظت از داده هماهنگ شود.

سطح هفتم: هک فضای ابری، Docker و کانتینرها

در زیرساخت ابری، مهاجم ممکن است از کلید API افشاشده برای ساخت ماشین مجازی، استخراج اطلاعات یا افزایش هزینه‌ها استفاده کند.

پس از حادثه این موارد را بررسی کنید:

• رویدادهای حساب ابری
• کاربران IAM و نقش‌ها
• Access Keyها
• Secretها
• Security Groupها
• Snapshotها
• Object Storage عمومی
• ماشین‌های جدید
• هزینه‌های غیرعادی
• تغییرات DNS
• Imageها و رجیستری کانتینر

در محیط Docker، حذف کانتینر آلوده به‌تنهایی کافی نیست. Image، Volume، Secret، فایل Compose و میزبان Docker نیز باید بررسی شوند.

برای ثبت وضعیت اولیه:

docker ps --no-trunc
docker images --digests
docker inspect suspicious-container > container-inspect.json
docker logs --timestamps suspicious-container > container.log 2>&1

پس از حفظ شواهد، کانتینر سالم را از Image مورد اعتماد و ترجیحاً با Digest مشخص بسازید. اگر احتمال دسترسی مهاجم به Docker Socket یا میزبان وجود دارد، بازسازی کل Host ضروری است.

قرار دادن این فایل داخل کانتینر خطر بسیار بالایی دارد:

/var/run/docker.sock

دسترسی به Docker Socket در بسیاری از معماری‌ها عملاً می‌تواند معادل دسترسی مدیریتی به میزبان باشد.

یک سناریوی واقعی: Hack فروشگاه وردپرسی

فرض کنید کاربران یک فروشگاه اینترنتی هنگام ورود به صفحه پرداخت به دامنه دیگری منتقل می‌شوند.

بررسی اولیه نشان می‌دهد یک افزونه قدیمی دارای آسیب‌پذیری آپلود فایل بوده است. مهاجم یک فایل PHP در پوشه `uploads` قرار داده، از طریق آن مدیر جدید ساخته و کد JavaScript مخرب را در دیتابیس ذخیره کرده است.

در این سناریو، حذف فایل PHP کافی نیست. فرایند صحیح شامل این مراحل است:

1. محدودکردن دسترسی عمومی سایت
2. تهیه نسخه شواهد از فایل‌ها، دیتابیس و لاگ‌ها
3. بررسی تراکنش‌ها و احتمال سرقت اطلاعات پرداخت
4. حذف افزونه آسیب‌پذیر
5. بازنصب هسته، قالب و افزونه‌ها از منابع سالم
6. پاک‌سازی کد مخرب از دیتابیس
7. حذف حساب مدیر مهاجم
8. تغییر رمزها، Saltها، توکن‌ها و کلیدهای API
9. بررسی پنل هاست و سرویس ایمیل
10. بازیابی در محیط آزمایشی
11. اجرای تست امنیتی قبل از انتشار
12. نظارت بر لاگ‌ها پس از بازگشت سایت

این مثال نشان می‌دهد نفوذ معمولاً فقط یک فایل آلوده نیست؛ بلکه زنجیره‌ای از دسترسی‌ها و تغییرات است.

چگونه مطمئن شویم مهاجم کاملاً حذف شده است؟

هیچ اسکنر واحدی نمی‌تواند سالم‌بودن کامل سیستم را تضمین کند. اطمینان نسبی زمانی حاصل می‌شود که چند کنترل هم‌زمان انجام شده باشد:

• مسیر ورود مهاجم شناسایی و بسته شده باشد.
• تمام نقاط پایداری حذف شده باشند.
• حساب‌ها، نشست‌ها و کلیدهای قبلی باطل شده باشند.
• نرم‌افزارها از منابع سالم بازسازی شده باشند.
• اطلاعات با نسخه‌های معتبر مقایسه شده باشند.
• لاگ‌ها پس از بازیابی تحت نظارت قرار گرفته باشند.
• تست امنیتی انجام شده باشد.
• بکاپ سالم و قابل بازیابی وجود داشته باشد.

اگر مسیر ورود مشخص نشود، احتمال Hack مجدد بسیار بالاست.

اقدامات پیشگیرانه پس از بازیابی

پس از بازگشت سرویس، این کنترل‌ها را اجرا کنید:

• احراز هویت چندمرحله‌ای
• رمزهای منحصربه‌فرد و Password Manager
• به‌روزرسانی منظم سیستم‌عامل و نرم‌افزارها
• حذف افزونه‌ها و سرویس‌های غیرضروری
• اصل حداقل دسترسی
• تهیه بکاپ خارج از سرور
• آزمایش دوره‌ای بازیابی بکاپ
• مانیتورینگ تغییر فایل‌ها
• ثبت و نگهداری متمرکز لاگ‌ها
• فایروال اپلیکیشن وب
• محدودیت نرخ درخواست
• اسکن آسیب‌پذیری
• تست نفوذ دوره‌ای
• مدیریت امن Secretها
• تفکیک محیط توسعه، آزمایش و تولید
• تدوین برنامه پاسخ‌گویی به رخداد
• آموزش کارکنان در برابر فیشینگ

قاعده مناسب بکاپ، مدل `۳-۲-۱` است:

– حداقل سه نسخه از اطلاعات
– روی دو نوع رسانه یا محیط متفاوت
– حداقل یک نسخه خارج از زیرساخت اصلی

بکاپی که همیشه به سرور متصل است ممکن است همراه با سرور حذف یا رمزگذاری شود.

اشتباهات رایج بعد از Hack شدن

حذف فوری تمام فایل‌ها

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

تغییر رمز از دستگاه آلوده

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

بازگردانی اولین بکاپ موجود

ممکن است نسخه پشتیبان قبلاً آلوده شده باشد.

 اعتماد کامل به اسکنر امنیتی

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

تمرکز فقط روی نشانه ظاهری

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

استفاده مجدد از کلیدها

تمام رمزها، API Keyها، توکن‌ها، کلیدهای SSH و Secretهای در معرض خطر باید تعویض شوند.

اطلاع‌رسانی عجولانه یا پنهان‌کاری

اطلاع‌رسانی باید بر مبنای اطلاعات تأییدشده و با هماهنگی فنی، مدیریتی و حقوقی انجام شود.

 چک‌لیست نهایی اقدامات بعد از هک

• [√] حادثه و زمان کشف آن ثبت شده است.
• [√] سیستم‌های آلوده مهار شده‌اند.
• [√] شواهد و لاگ‌ها حفظ شده‌اند.
• [√] دامنه نفوذ مشخص شده است.
• [√] مسیر ورود مهاجم شناسایی شده است.
• [√] حساب‌ها و دسترسی‌های مشکوک غیرفعال شده‌اند.
• [√] رمزها و کلیدها از دستگاه سالم تغییر کرده‌اند.
• [√] نشست‌ها و توکن‌های قدیمی باطل شده‌اند.
• [√] آسیب‌پذیری اصلی اصلاح شده است.
• [√] سیستم از منبع سالم بازسازی شده است.
• [√] بکاپ قبل از بازیابی بررسی شده است.
• [√] احتمال نشت اطلاعات ارزیابی شده است.
• [√] الزامات حقوقی و قراردادی بررسی شده‌اند.
• [√] تست امنیتی پس از بازیابی انجام شده است.
• [√] مانیتورینگ مستمر فعال شده است.
• [√] گزارش نهایی و درس‌آموخته‌های حادثه ثبت شده‌اند.

سؤالات متداول

 آیا بعد از هک فقط تغییر رمز عبور کافی است؟

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

 آیا سایت Hack شده را می‌توان از بکاپ بازیابی کرد؟

بله، به شرطی که بکاپ پیش از زمان نفوذ تهیه شده و سالم‌بودن آن بررسی شده باشد. بازیابی بکاپ بدون اصلاح آسیب‌پذیری باعث Hack مجدد خواهد شد.

چگونه بفهمیم اطلاعات کاربران سرقت شده است؟

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

 آیا پس از دسترسی مهاجم به root می‌توان سرور را پاک‌سازی کرد؟

پاک‌سازی ممکن است، اما تضمین سالم‌بودن سیستم دشوار است. در رخدادهای جدی، ساخت سرور جدید از منبع مورد اعتماد، تعویض تمام کلیدها و انتقال کنترل‌شده اطلاعات روش مطمئن‌تری محسوب می‌شود.

چه زمانی باید از متخصص امنیت کمک بگیریم؟

در صورت دسترسی مدیریتی مهاجم، نشت اطلاعات، باج‌افزار، اختلال در سامانه‌های حیاتی، تکرار آلودگی، درگیری چند سرور یا نبود لاگ و تخصص کافی، باید از تیم پاسخ‌گویی به رخداد یا متخصص جرم‌یابی دیجیتال کمک گرفت.

جمع‌بندی

مهم‌ترین اقدام پس از Hack شدن، بازگرداندن سریع ظاهر سایت یا روشن‌کردن دوباره سرور نیست. ابتدا باید حمله مهار، شواهد حفظ و دامنه واقعی نفوذ مشخص شود. سپس عامل ورود مهاجم حذف، تمام دسترسی‌های احتمالی تعویض و سامانه از یک منبع سالم بازیابی شود.

در Hack سایت ممکن است مشکل از یک افزونه آسیب‌پذیر آغاز شود، اما به دیتابیس، پنل هاست و ایمیل گسترش پیدا کند. در Hack سرور، دسترسی مدیریتی می‌تواند اعتبار کل سیستم‌عامل را زیر سؤال ببرد. در Hack اپلیکیشن نیز اصلاح یک خط کد بدون بررسی نشت اطلاعات و کلیدهای سرقت‌شده کافی نیست.

یک پاسخ حرفه‌ای به رخداد باید به سه سؤال پاسخ دهد: مهاجم چگونه وارد شد، به چه چیزهایی دسترسی پیدا کرد و برای جلوگیری از بازگشت او چه تغییراتی انجام شده است؟ تا زمانی که پاسخ مستندی برای این سه سؤال وجود نداشته باشد، نمی‌توان حادثه را خاتمه‌یافته تلقی کرد.