اگر همین حالا با این سؤال به این صفحه رسیده‌اید که «چطور بفهمم سایت هک شده»، اول از همه یک نکته را بدانید: عجله در پاک کردنِ چیزی که می‌بینید، رایج‌ترین اشتباهی است که بازیابی را چند برابر سخت‌تر میکند. این مقاله دو کار میکند. اول یک چک‌لیست تریاژ می‌دهد که در پانزده دقیقه‌ی اول مشخص میکند واقعاً نفوذی رخ داده یا با یک خطای فنی طرفید. بعد هر نشانه‌ی هک شدن سایت را جداگانه توضیح می‌دهد: معنایش چیست، کجا را باید ببینید، و چه چیزی را نباید دست بزنید تا شواهد از بین نرود.
در یک نگاه
- پیش از هر اقدامی لاگ‌ها و یک نسخهی کامل از وضعیت فعلی را بردارید؛ شواهدِ پاک‌شده برنمی‌گردند و بدون آن‌ها نقطهی ورود پیدا نمی‌شود.
- خطرناک‌ترین نشانه‌ها آن‌هایی هستند که برای شما دیده نمی‌شوند: ریدایرکت مخصوص موبایل، محتوای اسپمِ فقط برای خزنده‌ی گوگل، و درِ پشتی در فایل‌های به‌ظاهر عادی.
- «سایت چینی شده» و «سایت ژاپنی شده» نام عامیانه‌ی یک حمله‌ی مشخص‌اند: تزریق محتوای اسپم برای ایندکس شدن، نه تغییر زبان سایت.
- حذف صفحه‌ی اسپم، بازگردانی بکاپ و تغییر فوری رمزها — هر سه اگر قبل از یافتن نقطهی ورود انجام شوند، به آلودگی دوباره منجر میشوند.
- هدف تریاژ، پاکسازی نیست؛ هدف این است که تصمیم بگیرید پاکسازی را از کجا و با چه ترتیبی شروع کنید.
چک‌لیست تریاژ: پانزده دقیقه‌ی اول
این هفت مرحله را به همین ترتیب انجام دهید. هیچ‌کدام تغییری در سایت ایجاد نمیکند — همه فقط «مشاهده» هستند و همین باعث می‌شود بی‌خطر باشند.
- سایت را از دید یک بازدیدکننده‌ی ناشناس ببینید. در حالت ناشناس مرورگر (بدون کوکی و بدون نشست مدیر) صفحه‌ی اصلی و دو سه صفحه‌ی داخلی را باز کنید. بسیاری از بدافزارها برای کاربر لاگین‌شده هیچ کاری نمی‌کنند.
- همان کار را با موبایل و با یک ارجاع‌دهنده‌ی جعلی تکرار کنید. ریدایرکت‌های شرطی معمولاً فقط روی
User-Agentموبایل یا فقط وقتی کاربر از نتایج جستوجو آمده باشد فعال میشوند. - در گوگل عبارت
site:example.comرا جستوجو کنید. اگر صفحاتی با عنوان‌های نامربوط، حروف چینی یا ژاپنی، یا نام دارو و شرط‌بندی می‌بینید، محتوای اسپم ایندکس شده است. - Google Search Console را باز کنید و بخش «Security & Manual Actions» را ببینید. این معتبرترین منبع بیرونی برای تأیید آلودگی است.
- فهرست کاربران مدیر را بشمارید. هر حساب مدیری که نمی‌شناسید، هر حسابی با ایمیل ناآشنا، و هر تغییر نقش اخیر، نشانه‌ی جدی است.
- لاگ دسترسی وبسرور و لاگ خطا را دانلود کنید — همین حالا، قبل از هر تغییری. لاگ‌ها روی هاست‌های اشتراکی معمولاً چرخش سریع دارند و ممکن است فردا وجود نداشته باشند.
- یک نسخهی کامل از فایلها و پایگاهداده بگیرید و آن را دست‌نخورده نگه دارید. این نسخه بکاپ نیست؛ شاهد است.
نقطهی ورود مهاجم تقریباً همیشه از دل لاگ‌ها و زمان تغییر فایلها پیدا می‌شود. اگر فایلها را ویرایش کنید، رمزها را عوض کنید یا بکاپ را بازگردانید، mtime فایلها و ردپای نشست مهاجم را از بین می‌برید و عملاً امکان یافتن مسیر نفوذ را نابود می‌کنید. توضیح کامل این فرایند را در راهنمای پاکسازی سایت هک شده آورده‌ایم.
هشدار امنیتی گوگل و Search Console
در بسیاری از موارد اولین کسی که به شما خبر می‌دهد سایت هک شده، گوگل است — نه چون گوگل سایت شما را می‌پاید، بلکه چون خزنده‌اش محتوای تزریق‌شده را می‌بیند یا Safe Browsing رفتار مخرب صفحه را تشخیص می‌دهد.
کجا را ببینید
- Search Console › Security & Manual Actions › Security issues: اینجا دستهی مشکل و نمونه‌ای از URLهای متأثر ذکر می‌شود. این گزارش دقیق‌ترین چیزی است که از بیرون می‌توانید دریافت کنید.
- صفحه‌ی هشدار قرمز مرورگر («Deceptive site ahead» یا «The site ahead contains malware») نشانه‌ی این است که دامنه در Safe Browsing علامت خورده است. کروم، فایرفاکس، سافاری و اج همه از همین سرویس تغذیه میشوند، پس هشدار در همه‌جا هم‌زمان ظاهر می‌شود.
- افت ناگهانی کلیک در گزارش Performance بدون افت جایگاه، معمولاً یعنی هشدار مرورگر بین کاربر و سایت شما ایستاده است.
دسته‌بندی‌ها، فرایند درخواست بازبینی و دلایل ردشدن آن را جداگانه در مقاله‌ی جریمه امنیتی گوگل و بلاک شدن در Safe Browsing توضیح داده‌ایم.
«Search Console چیزی نشان نمی‌دهد، پس سایت سالم است.» نبودِ هشدار هیچ چیزی را اثبات نمیکند. Safe Browsing فقط الگوهای مخربِ قابل تشخیص را می‌بیند؛ درِ پشتی خاموشی که منتظر درخواست مهاجم است، صفحه‌ی فیشینگی که فقط با پارامتر خاص فعال می‌شود، و سرقت خاموش داده هیچ‌کدام باعث هشدار گوگل نمی‌شوند. Search Console یک آشکارساز است، نه گواهی سلامت.
ریدایرکت‌های ناخواسته: موبایل‌محور و شرطی
این شایع‌ترین نشانه‌ای است که صاحب سایت آخرین نفر متوجهش می‌شود، چون بدافزار عمداً طوری نوشته شده که برای مدیر سایت اجرا نشود. شرط‌های رایج:
- فقط موبایل: بررسی
User-Agentو ریدایرکت کاربران اندروید و iOS به صفحه‌ی تبلیغاتی یا فروشگاه اپ جعلی. - فقط ترافیک ارگانیک: بررسی هدر
Refererو ریدایرکت فقط وقتی کاربر از گوگل آمده باشد. تایپ مستقیم آدرس، سایت سالم را نشان می‌دهد. - فقط یک بار برای هر IP: با کوکی یا کش سمت سرور، هر بازدیدکننده فقط یک بار ریدایرکت می‌شود؛ همین باعث می‌شود بازآزمایی شما «مشکل حل شده» به نظر برسد.
- عبور دادن ربات‌ها: بدافزار خزنده‌ی گوگل را شناسایی و بسته به هدف مهاجم، محتوای سالم یا اسپم به آن می‌دهد.
چه چیزی را بررسی کنید
- فایل‌های
.htaccessدر همه‌ی مسیرها، نه فقط ریشه. تزریق در.htaccessِ پوشه‌یuploadsبسیار رایج است. - کدهای تزریق‌شده در ابتدای فایل‌های PHP، معمولاً به‌شکل رشته‌ی base64 یا آرایه‌ای از کاراکترها که در زمان اجرا سرِهم می‌شود.
- در وردپرس: مقادیر
siteurlوhomeدر جدول تنظیمات، و اسکریپت‌های تزریق‌شده در گزینه‌های افزونه‌ها. جزئیات بیشتر در امنیت وردپرس.
curl -sI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" \
-e "https://www.google.com/" https://example.com/ | head -20این دستور فقط هدرهای پاسخ را با یک عاملِ کاربری موبایل و ارجاع‌دهنده‌ی گوگل می‌گیرد. اگر Location به دامنه‌ای غریبه اشاره کند، ریدایرکت شرطی را ثابت کرده‌اید.
صفحات اسپم ایندکس‌شده: «سایت چینی شده» و «سایت ژاپنی شده»
این دو عبارت در فارسی بسیار جستوجو میشوند و هر دو به یک خانواده از حملات اشاره دارند: مهاجم هزاران صفحه‌ی اسپم با محتوای چینی یا ژاپنی روی دامنهی شما تولید میکند تا از اعتبار دامنه برای رتبه گرفتن کلیدواژه‌های خودش استفاده کند. زبان سایت شما تغییر نکرده؛ صفحاتی اضافه شده که شما هرگز نساخته‌اید.
نشانه‌های مشخص
- در
site:example.comصدها یا هزاران URL ناشناس با عنوان‌های غیرفارسی ظاهر می‌شود. - تعداد صفحات ایندکس‌شده در Search Console بی‌دلیل چند برابر شده است.
- گزارش Performance برای کلیدواژه‌هایی نمایش می‌گیرد که هیچ ربطی به کسب‌وکار شما ندارند.
- باز کردن آن URLها با مرورگر ۴۰۴ می‌دهد، اما با عاملِ کاربری خزنده‌ی گوگل محتوا برمی‌گرداند — یعنی Cloaking.
مکانیزم فنی
در بیشتر موارد این حمله با یکی از این سه ابزار پیش می‌رود: یک اسکریپت تولید صفحه که با پارامتر مسیر، محتوای اسپم را از سرور مهاجم می‌گیرد؛ تزریق مستقیم به پایگاهداده و ساخت هزاران نوشته یا برگه؛ یا بازنویسی مسیر در .htaccess به یک فایل واحد. همه‌ی این‌ها یک پیش‌نیاز دارند: مهاجم قبلاً توانسته فایل بنویسد یا کد اجرا کند. یعنی صفحات اسپم نتیجه هستند، نه علت.
«صفحات اسپم را حذف می‌کنم و از گوگل حذفشان می‌کنم، مشکل تمام است.» صفحات اسپم خروجیِ یک درِ پشتی‌اند. تا وقتی سازوکار تولیدشان زنده باشد، فردا با آدرس‌های جدید برمی‌گردند. ابزار حذف URL در Search Console هم فقط نمایش در نتایج را موقتاً پنهان میکند و آلودگی را برنمی‌دارد.
حساب‌های مدیر ناشناس، فایل‌های تغییریافته و کران‌جاب‌ها
سه نشانه‌ای که مستقیماً به «دسترسی پایدار» مهاجم اشاره می‌کنند. مهاجم حرفه‌ای بعد از نفوذ اول، چند مسیر بازگشت برای خودش می‌سازد تا اگر یکی بسته شد بقیه باقی بمانند.
حساب کاربری غیرمنتظره
- کاربر مدیری که نمی‌شناسید، یا کاربری با نام مشابه کاربران واقعی (مثلاً
admlnدر برابرadmin). - ارتقای نقش یک کاربر عادی به مدیر — این را در لاگ تغییرات یا تاریخ ثبت‌نام ببینید. این همان ارتقای سطح دسترسی است.
- تغییر ایمیل حساب مدیر، برای مسدود کردن مسیر بازیابی رمز.
فایل‌های تغییریافته یا اضافه‌شده
مقایسه‌ی فایل‌های هسته‌ی سیستم مدیریت محتوا با نسخهی رسمی، سریع‌ترین راه تشخیص است. اگر افزونه یا هسته‌ای تغییر خورده باشد، ابزارهای رسمی خودشان این را نشان می‌دهند. نشانه‌های تکمیلی: فایل PHP در پوشه‌ی آپلود، فایل با نام تصادفی در ریشه، فایل تصویری با پسوند دوگانه، و فایل‌هایی با تاریخ تغییر یکسان در پوشه‌های مختلف.
# فایل‌های PHP تغییریافته در ۷ روز گذشته (فقط مشاهده)
find /var/www/html -type f -name "*.php" -mtime -7 -printf "%T+ %p\n" | sortکران‌جاب و وظایف زمان‌بندی‌شده
کران‌جاب، ابزار محبوب پایداری است چون حتی اگر فایل آلوده حذف شود، آن را دوباره می‌سازد. هم کران‌جاب سطح سیستم و کاربر هاست را ببینید، هم زمان‌بندهای داخلی خودِ برنامه (در وردپرس: WP-Cron). یک وظیفه‌ی زمان‌بندی‌شده با نام مبهم که هر پنج دقیقه اجرا می‌شود، تقریباً همیشه بدافزار است.
ارسال اسپم، مصرف غیرعادی منابع و دیفیس
این دسته نشانه‌ها از سمت زیرساخت و صورت‌حساب دیده میشوند، نه از سمت مرورگر.
- خروج ایمیل انبوه: سرور شما بدون اطلاع شما اسپم می‌فرستد. نشانه‌ها: صف ایمیل پرشده، هشدار میزبان، بازگشت انبوه ایمیل، و مهم‌تر از همه قرار گرفتن IP سرور یا دامنه در فهرست‌های سیاه ایمیل. اگر ایمیل‌های سازمانی شما ناگهان به هرزنامه می‌روند، اول از همه اینجا را بررسی کنید.
- افزایش بی‌دلیل مصرف CPU یا حافظه: استخراج رمزارز، ابزار جست‌وجوی گسترده، یا میزبانی فایل برای دیگران. اگر بار سرور بالا رفته اما بازدید تغییری نکرده، تناقض را جدی بگیرید.
- جهش ترافیک با الگوی نامتعارف: ترافیک زیاد به یک مسیر خاص، یا ترافیک خروجی سنگین به یک IP ثابت.
- دیفیس: جایگزینی صفحه‌ی اصلی با پیام مهاجم. آشکارترین نشانه و — برخلاف تصور — معمولاً کم‌خطرترین از نظر داده، چون هدف نمایش است نه سرقت. با این حال دیفیس ثابت میکند مهاجم توانسته فایل بنویسد، پس باید فرض کنید به همه چیز دسترسی داشته است.
- فهرست سیاه امنیتی: علاوه بر Safe Browsing گوگل، فهرست‌های دیگری هم وجود دارند که میزبان‌ها و فیلترهای شبکه از آن‌ها استفاده می‌کنند. حضور دامنه در این فهرست‌ها معمولاً پیش از هشدار مرورگر رخ می‌دهد.
یک نکته‌ی مهم درباره‌ی این دسته: مصرف بالای منابع همیشه نشانه‌ی هک نیست. خزنده‌ی جدید، افزونه‌ی بدنویسی‌شده، کوئری بهینه‌نشده و کش خراب هم همین اثر را دارند. تشخیص را با تلاقی چند نشانه بسازید، نه با یکی. رویکرد سیستماتیک این ارزیابی را در بررسی امنیت سایت شرح داده‌ایم.
جدول مرجع: هر نشانه یعنی چه و کجا را ببینم
| نشانه | یعنی چه | چه چیزی را بررسی کنید |
|---|---|---|
| هشدار در Search Console | گوگل محتوای مخرب یا فریب‌دهنده تشخیص داده | دستهی مشکل و نمونه‌ی URLها در گزارش Security issues |
| ریدایرکت فقط در موبایل | بدافزار شرطی؛ درِ پشتی فعال است | .htaccess در همه‌ی مسیرها، ابتدای فایل‌های PHP، اسکریپت‌های تزریقی |
| صفحات چینی/ژاپنی در نتایج گوگل | تولید انبوه صفحه‌ی اسپم روی دامنهی شما | پایگاهداده (نوشته/برگه/گزینه‌ها)، قواعد بازنویسی مسیر، نقشه‌ی سایت |
| کاربر مدیر ناشناس | پایداری دسترسی؛ نفوذ قبلاً موفق شده | جدول کاربران، لاگ ورود، تاریخ ثبت‌نام، ایمیل حساب‌ها |
| فایل هسته تغییریافته | تزریق کد یا درِ پشتی در فایل معتبر | مقایسه با نسخهی رسمی (checksum)، mtime فایلها |
| کران‌جاب ناشناس | سازوکار بازتولید بدافزار پس از پاکسازی | کران سطح سیستم و کاربر، زمان‌بند داخلی برنامه |
| خروج اسپم / IP در فهرست سیاه | سوءاستفاده از سرور برای ارسال انبوه | صف ایمیل، لاگ MTA، فرم‌های تماس، اسکریپت‌های ارسال |
| CPU یا ترافیک غیرعادی | ماینر، اسکن خروجی، یا میزبانی فایل مهاجم | فرایندهای در حال اجرا، ترافیک خروجی، فضای دیسک |
| دیفیس صفحه‌ی اصلی | مهاجم دسترسی نوشتن روی فایل دارد | زمان تغییر فایل ایندکس، لاگ دسترسی حول آن زمان |
| خطای پایگاهداده یا صفحه‌ی سفید ناگهانی | ممکن است تزریق ناموفق یا درگیری بدافزار باشد | لاگ خطا، آخرین تغییرات، حجم غیرعادی جداول |
کارهایی که در این مرحله نباید انجام دهید
این بخش ارزشمندترین قسمت این مقاله است. هر یک از این کارها با نیت خوب انجام می‌شود و هر یک بازیابی را سخت‌تر میکند.
- فقط صفحه یا فایلِ دیده‌شده را حذف نکنید. چیزی که می‌بینید علامت است، نه علت. حذف آن، مهاجم را از سایت بیرون نمیکند و شما را از تشخیص محروم میکند.
- بکاپ را قبل از یافتن نقطهی ورود بازنگردانید. اگر نمی‌دانید نفوذ چه زمانی و از کجا رخ داده، نمی‌دانید کدام بکاپ سالم است. بدتر: بازگردانی، شواهد را پاک میکند و اگر نقطهی ورود یک آسیبپذیری در کدِ خودتان بوده، آن آسیبپذیری هم برمی‌گردد.
- قبل از برداشتن شواهد، رمزها را عوض نکنید. تغییر رمز کار درستی است — اما ترتیبش مهم است. اول لاگ و نسخهی شواهد، بعد چرخش کامل اعتبارنامهها. تغییر عجولانه‌ی یک رمز، مهاجم را هشیار میکند و او با درِ پشتیِ دیگرش برمی‌گردد، در حالی که شما فکر می‌کنید مشکل حل شده.
- سایت را با اطمینان «حل شد» اعلام نکنید. تا وقتی نقطهی ورود مستند نشده، آلودگی دوباره فقط مسئله‌ی زمان است.
- روی نصب یک افزونه‌ی امنیتی بهعنوان درمان حساب نکنید. افزونه‌ی امنیتی روی سایتِ آلوده، در بهترین حالت بخشی از فایل‌های شناخته‌شده را علامت می‌زند؛ درِ پشتیِ سفارشی را نمی‌بیند و کدی که همین حالا در حال اجراست را متوقف نمیکند.
- WAF را راه‌حل نهایی ندانید. فایروال برنامه‌ی وب می‌تواند موج حملات خودکار را کم کند، اما ساختاراً نسبت به نقص کنترل دسترسی، منطق کسب‌وکار و درِ پشتی‌ای که همین الان داخل سایت است نابیناست. توضیح کامل در دانشنامه‌ی WAF.
- پایگاهداده را «تمیز» نکنید تا وقتی نسخهی شواهد را نگرفته‌اید. اطلاعات ارزشمند تشخیص — از جمله زمان و منبع تزریق — درون همان رکوردهاست.
«سایت من کوچک است و داده‌ی مهمی ندارد، پس هدف جذابی نیست.» تقریباً هیچ‌کدام از این حملات هدفمند نیستند. مهاجم در مقیاس اینترنت اسکن میکند و به دنبال یک نسخهی آسیب‌پذیرِ مشخص است؛ محتوای سایت شما برایش بی‌اهمیت است. آنچه ارزش دارد دامنهی معتبر، فضای میزبانی و توان پردازشی شماست. این را در سایت‌های ناامن با جزئیات آورده‌ایم.
تشخیص را تأیید کردم؛ قدم بعدی چیست؟
اگر پس از تریاژ به این نتیجه رسیدید که نفوذ رخ داده، مسیر درست یک ترتیب مشخص دارد و پرش از هیچ مرحله‌ای جایز نیست:
- ایزوله‌سازی و حالت تعمیر تا سایت به کاربران و به اعتبار دامنه آسیب بیشتری نزند.
- تثبیت شواهد — لاگ‌ها، نسخهی فایلها و پایگاهداده، و فهرست تغییرات.
- یافتن نقطهی ورود. این مرحله‌ای است که همه از آن می‌گذرند و دقیقاً همین است که باعث آلودگی دوباره می‌شود.
- پاکسازی یا بازسازی از منبع سالم، سپس چرخش کامل اعتبارنامهها و کلیدها.
- وصلهی نقطهی ورود و راستی‌آزمایی.
- درخواست بازبینی از گوگل و پایش پس از بازیابی.
هر شش مرحله را قدم‌به‌قدم در راهنمای پاکسازی سایت هک شده نوشته‌ایم، و بخش مربوط به رفع هشدار مرورگر و بازگشت سئو در جریمه امنیتی گوگل است. اگر سایت شما وردپرسی است، احتمال بسیار زیادی وجود دارد که نقطهی ورود یک افزونه یا قالب باشد؛ الگوهای رایج در آسیب‌پذیری‌های وردپرس فهرست شدهاند.
و اگر سایت شما درگاه پرداخت، داده‌ی مشتری یا سرویس فعال دارد و نمی‌خواهید ریسک آلودگی دوباره را بپذیرید، خدمات بازیابی سایت هک شده‌ی پی‌هانتر همین فرایند را با تحلیل ریشه‌ای نقطهی ورود انجام می‌دهد. پس از بازیابی هم منطقی است با یک تست نفوذ وب مطمئن شوید همان آسیبپذیری در جای دیگری از برنامه تکرار نشده است.
پرسش‌های متداول
سایت هک شده چیکار کنم؟
به این ترتیب: سایت را ایزوله کنید (حالت تعمیر)، پیش از هر تغییری لاگهای وبسرور و یک نسخهی کامل از فایلها و پایگاهداده را بهعنوان شاهد بردارید، سپس نقطهی ورود را پیدا کنید. تنها بعد از آن پاکسازی، چرخش رمزها و وصله معنا دارد. مسیر کامل در پاکسازی سایت هک شده آمده است.
چطور بفهمم سایتم هک شده یا فقط خطای فنی دارد؟
خطای فنی معمولاً برای همه یکسان است و در لاگ خطا اثر روشنی دارد. نفوذ معمولاً شرطی است: برای موبایل یا برای کاربری که از گوگل آمده متفاوت رفتار میکند، فایل‌های تغییریافته‌ی بی‌سابقه دارد، یا کاربر و کران‌جاب ناشناس ایجاد کرده است. چک‌لیست تریاژ ابتدای همین مقاله برای همین تمایز نوشته شده.
سایتم چینی شده یعنی چه؟
یعنی مهاجم روی دامنهی شما صفحات اسپم با محتوای چینی (یا ژاپنی) تولید کرده تا از اعتبار دامنهی شما برای رتبه گرفتن استفاده کند. زبان سایت شما تغییر نکرده — صفحاتی اضافه شدهاند که فقط در نتایج جستوجو یا برای خزنده دیده میشوند. حذف آن صفحات بدون بستن درِ پشتی، مشکل را حل نمیکند.
آیا تغییر رمز عبور برای رفع هک کافی است؟
نه. اگر مهاجم درِ پشتی نصب کرده یا از یک آسیبپذیری در کد استفاده کرده، رمز عبور اصلاً در مسیر او نبوده. چرخش کامل اعتبارنامهها یک مرحلهی ضروری اما ناکافی است و باید بعد از برداشتن شواهد و همراه با وصلهی نقطهی ورود انجام شود.
می‌توانم فقط بکاپ را برگردانم و کار تمام شود؟
تنها در صورتی که سه چیز را بدانید: زمان دقیق نفوذ، سالم بودن آن بکاپ، و نقطهی ورود. اگر نقطهی ورود یک آسیبپذیری در کد یا یک افزونه‌ی قدیمی بوده، بکاپ آن را هم برمی‌گرداند و در فاصله‌ی کوتاهی دوباره آلوده می‌شوید. بازگردانی بکاپ ابزار بازیابی است، نه ابزار رفع آسیبپذیری.
چند وقت طول میکشد تا بفهمم سایت هک شده است؟
متأسفانه معمولاً بسیار طولانی — چون بیشتر آلودگیها عمداً بیصدا هستند. تنها چیزی که این فاصله را کوتاه میکند، ثبت لاگ و هشداردهی است؛ همان چیزی که OWASP در دستهی A09:2025 «نقص ثبت رخداد و هشداردهی امنیتی» به آن اشاره میکند. راهاندازی پایش تغییر فایل، هشدار ورود مدیر و بازبینی دورهای لاگ، تفاوت بین کشف در چند ساعت و کشف در چند ماه است.
منابع
محمدرضا مقدم
مغز خودکارسازی تیم؛ ابزارها و زیرساخت داخلی پی‌هانتر را می‌سازد تا اسکن و گزارش‌گیری سریع‌تر و دقیق‌تر انجام شود.