پاسخ کوتاه: درخواست را از مسیر مستقل تأیید کنید
برای تشخیص ایمیل فیشینگ، فقط به لوگو یا نام فرستنده اعتماد نکنید. درخواست فوری، لینک یا پیوست غیرمنتظره و تقاضای رمز یا تغییر پرداخت را بررسی کنید. اگر شک دارید، لینک را باز نکنید؛ از نشانی ذخیره‌شدهٔ سرویس یا شمارهٔ از قبل شناخته‌شده، اصل درخواست را تأیید و پیام را به مسئول فناوری اطلاعات گزارش کنید.
ایمیل جعلی ممکن است بدون غلط املایی و شبیه مکاتبهٔ روزمره باشد. هدف این راهنما دادن حکم قطعی از روی ظاهر نیست؛ قرار است قبل از ورود اطلاعات یا تأیید پرداخت، یک مسیر بررسی روشن داشته باشید. موضوع می‌تواند در پیام‌رسان، پیامک یا QR هم تکرار شود.
۱. فیشینگ چه چیزی از شما می‌خواهد؟
در فیشینگ، مهاجم با جا زدن خود به‌جای فرد یا سازمان مورد اعتماد، شما را به افشای اطلاعات یا انجام کار دلخواهش سوق می‌دهد. این کار ممکن است ورود رمز در صفحهٔ جعلی، بازکردن فایل یا تغییر شماره‌حساب یک فاکتور باشد. شناخت نام شرکت کافی نیست؛ باید خود درخواست و کانال تأیید را هم بررسی کرد. تعریف و راهنمای فیشینگ NCSC
بین پیام ناخواسته و حمله تفاوت وجود دارد، اما لازم نیست برای گزارش یک پیام، حمله‌بودن آن را ثابت کنید. کافی است دلیل شک را روشن بنویسید: «منتظر این فایل نبودم» یا «درخواست تغییر پرداخت با روال معمول فرق دارد». این گزارش برای بررسی تخصصی مفیدتر از حدس‌زدن نام بدافزار است.
۲. نشانه‌های مشکوک را کنار هم ببینید
| نشانه | چرا مهم است؟ | بررسی مناسب |
|---|---|---|
| تهدید به مسدودشدن فوری حساب | فشار زمانی فرصت فکرکردن را کم می‌کند. | سرویس را از مسیر شناخته‌شده باز کنید و وضعیت حساب را ببینید. |
| فایل یا فاکتور غیرمنتظره | موضوع آشنا می‌تواند پوشش درخواست ناسالم باشد. | بدون بازکردن پیوست، با فرستنده از کانال دیگر تماس بگیرید. |
| رمز، کد تأیید یا تأیید ورود ناآشنا | ممکن است دسترسی حساب هدف باشد. | کد را نفرستید و ورود ناشناخته را تأیید نکنید؛ گزارش بدهید. |
| تغییر شماره‌حساب تأمین‌کننده | حتی مکاتبهٔ آشنا می‌تواند دستکاری شده باشد. | از شمارهٔ قبلی قرارداد و تأیید مسئول مالی استفاده کنید. |
| آدرس واقعی با نام نمایشی فرق دارد | نام و تصویر فرستنده هویت را اثبات نمی‌کنند. | آدرس کامل و روال مکاتبه را بررسی و مورد مشکوک را ارجاع دهید. |
مایکروسافت فشار برای اقدام فوری، دامنهٔ ناهماهنگ و پیوست غیرمنتظره را از نشانه‌های قابل بررسی می‌داند. نبود این نشانه‌ها هم گواه سالم‌بودن نیست. برای پیام مشکوک، تأیید از راه مستقل مطمئن‌تر از پاسخ‌دادن در همان زنجیره است. راهنمای تشخیص پیام فیشینگ مایکروسافت
۳. فرستنده و لینک را چگونه بررسی کنیم؟
نام نمایشی را باز کنید تا آدرس کامل دیده شود. یک حرف شبیه، کلمهٔ اضافی یا نام تجاری در بخش نامربوط آدرس می‌تواند گمراه‌کننده باشد. برای اطمینان، نشانی رسمی را از مرجع شناخته‌شدهٔ قبلی بردارید؛ نه از شماره یا لینکی که خود پیام مشکوک معرفی می‌کند.
روی رایانه می‌توانید بدون کلیک، مقصد لینک را با نگه‌داشتن نشانگر ببینید؛ اگر نمایش آن روی گوشی روشن نیست، برای امتحان لینک را لمس نکنید. مسیر ذخیره‌شدهٔ سرویس را باز کنید. وجود HTTPS یا قفل، به‌تنهایی هویت و سلامت کسب‌وکار پشت صفحه را تضمین نمی‌کند.
فرض کنید دامنهٔ شناخته‌شدهٔ شما company.example است. دیدن company.example در عنوان یا متن پیام کافی نیست. نشانی company.example.login-check.invalid زیرمجموعهٔ همان دامنهٔ شرکت نیست. این آدرس‌ها صرفاً مثال‌اند و لینک قابل کلیک نیستند؛ برای تشخیص واقعی از مسئول فنی کمک بگیرید.
Outlook ممکن است برای فرستندهٔ تأییدنشده علامت سؤال یا تفاوت هویت نمایش دهد. این هشدار دلیل احتیاط است، اما هر پیام دارای هشدار الزاماً حمله نیست و نبود هشدار هم تضمین نیست. توضیح نشانگرهای فرستنده و گزارش در Outlook
۴. روال مناسب وقتی هنوز کلیک نکرده‌اید
- اقدام درخواستی را متوقف کنید؛ پاسخ ندهید و پیوست یا QR را باز نکنید.
- اگر درخواست کاری است، از شماره یا مسیر قبلی فرستنده تأیید بگیرید.
- طبق روال شرکت، پیام را با ابزار گزارش یا کانال تعیین‌شده به IT ارجاع دهید.
- برای انتقال نمونه، روش تیم امنیت را اجرا کنید؛ پیام را برای امتحان به همکاران نفرستید.
- پس از گزارش، دربارهٔ حذف یا نگهداری نسخهٔ اصلی از دستورالعمل شرکت پیروی کنید.
در Outlook و Outlook.com گزینهٔ Report > Report phishing از مسیرهای رسمی گزارش است؛ محل و دسترسی آن می‌تواند با نسخه و سیاست سازمان فرق کند. اگر گزینه را نمی‌بینید، از مسئول سامانه سؤال کنید. اسکرین‌شات می‌تواند ظاهر را نشان دهد، اما همهٔ سربرگ‌های لازم برای تحلیل پیام را ندارد.
۵. اگر کلیک کرده‌اید، دقیقاً چه چیزی اتفاق افتاده است؟
«پیام را دیدم»، «لینک باز شد»، «رمز وارد کردم» و «فایل اجرا کردم» یک وضعیت نیستند. زمان و کاری را که واقعاً انجام شده ثبت کنید و به IT بگویید. برای بازسازی ماجرا دوباره روی لینک نروید. اگر دادهٔ پرداخت وارد کرده‌اید، از کانال رسمی با مسئول مالی و مؤسسهٔ مربوط تماس بگیرید.
اگر رمز حساب کاری را وارد کرده‌اید، از دستگاه سالم و نشانی رسمی برای تغییر آن اقدام و فوراً تیم IT را مطلع کنید. برای حساب سازمانی، بررسی نشست‌ها، روش‌های MFA، برنامه‌های دارای رضایت و قانون‌های صندوق ایمیل هم لازم است؛ تغییر رمز به‌تنهایی همیشه کافی نیست. این بررسی‌ها باید با اختیار مدیر انجام شوند. راهنمای پاسخ به حساب ایمیل تسخیرشده
اگر فایل مشکوک اجرا شده یا نشانهٔ آلودگی دیده می‌شود، ارتباط دستگاه را از شبکه جدا و از کانال دیگری با تیم پاسخ‌گویی هماهنگ کنید. حذف فایل‌ها یا نصب ابزارهای تصادفی ممکن است بررسی را سخت کند. راهنمای اقدامات اولیه هنگام باج‌افزار را برای نشانه‌های رمزشدن گستردهٔ اطلاعات بخوانید.
۶. شرکت چه روالی آماده کند؟
کارمند باید بداند پیام مشکوک را کجا گزارش دهد و بعد از اشتباه چه بگوید. یک مسیر کوتاه برای اعلام زمان، حساب و اقدام انجام‌شده تعریف کنید. رمز و کد تأیید جزو گزارش نیستند. تغییر پرداخت نیز بهتر است یک تأیید مستقل از ایمیل داشته باشد.
آموزش، MFA مقاوم در برابر فیشینگ در صورت پشتیبانی و به‌روزرسانی ابزارها در کنار هم اهمیت دارند. هیچ‌کدام جای فرهنگ گزارش سریع را نمی‌گیرد. پرسش‌های آمادگی سازمان در راهنمای NIST برای مرور این بخش مناسب است. برای بررسی سیاست‌ها و دسترسی‌ها، خدمات امنیت شبکه و اطلاعات ویوان را ببینید.
پرسش‌های پرتکرار
ایمیل بدون غلط املایی می‌تواند فیشینگ باشد؟
بله. ظاهر حرفه‌ای یا متن درست هویت فرستنده و سلامت درخواست را اثبات نمی‌کند.
ایمیل از طرف همکار هم نیاز به بررسی دارد؟
اگر درخواست غیرمنتظره است، بله. جعل نام یا دسترسی غیرمجاز به حساب واقعی هر دو ممکن‌اند.
قفل HTTPS یعنی صفحه برای ورود رمز امن است؟
خیر. ارتباط رمزگذاری‌شده به‌تنهایی اصالت سرویس مقصد را اثبات نمی‌کند؛ نشانی رسمی و درخواست را هم بررسی کنید.
با دیدن ایمیل مشکوک حتماً آلوده شده‌ایم؟
این نتیجه از ظاهر پیام معلوم نمی‌شود. فرق دیدن، کلیک، ورود اطلاعات و اجرای فایل را در گزارش مشخص کنید.
برای بررسی، رمز یا فایل محرمانه را بفرستم؟
خیر. رمز و کد ورود را ارسال نکنید و نمونهٔ پیام را فقط از مسیر مجازِ تعیین‌شدهٔ تیم امنیت منتقل کنید.
منابع و حدود مقاله
منابع اصلی مایکروسافت، NCSC و NIST در بخش‌های مرتبط آمده‌اند. مثال دامنه ساختگی است. نشانه‌های این مقاله ابزار غربالگری‌اند؛ تعیین دامنهٔ رخداد به شواهد و بررسی تخصصی نیاز دارد.
روال مشخصی برای پیام‌های مشکوک ندارید؟
نیاز شرکت به آموزش، بررسی دسترسی و مسیر گزارش را توضیح دهید؛ پیام آلوده، رمز یا دادهٔ بانکی را در درخواست اولیه نفرستید.
ثبت درخواست بررسی