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

اوسینت دامنه چیست؟

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

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

دامنه چه سرنخ‌هایی نشان می‌دهد؟

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

چرا زمینه پرونده مهم است؟

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

مسیر امن برای بررسی دامنه

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

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

مثال عملی اوسینت دامنه: بررسی example.org با RDAP و DNS

تاریخ مشاهده: ۷ سپتامبر ۲۰۲۶. این یک تمرین واقعی خواندن رکورد عمومیِ دامنهٔ آموزشی IANA است؛ پروندهٔ مشتری یا سنجش دقت گزارش اوسینت جت نیست. پرسش محدود است: از رکورد ثبت دامنه و دو نوع رکورد DNS چه نتیجه‌ای می‌توان گرفت؟

۱. اول کاربرد دامنه را از منبع اصلی روشن کنید

توضیح IANA می‌گوید example.org برای مثال‌های مستندات نگهداری می‌شود و برای ثبت یا انتقال معمول در دسترس نیست. این توضیح از سازمان مسئول می‌آید؛ ظاهر سایت، قدمت دامنه یا نام ارائه‌دهندهٔ DNS به‌تنهایی چنین کاربردی را ثابت نمی‌کند.

۲. رکورد ثبت دامنه را از RDAP بخوانید

RDAP دادهٔ ثبت را به شکل ساختارمند ارائه می‌کند؛ ICANN نقش آن را توضیح داده است. در این تمرین، سرویس پسوند org را از فهرست راه‌انداز IANA پیدا کردیم و حدود ساعت 05:18 UTC، رکورد عمومی رجیستری برای example.org را خواندیم.

• فیلد ldhName برابر example.org بود؛ پس رکورد به دامنهٔ مورد نظر مربوط می‌شد.
• رویداد registration مقدار 1995-08-31T04:00:00Z داشت. این تاریخِ رویداد ثبت در پاسخ دریافتی است؛ تاریخ ساخت سایت فعلی یا شروع فعالیت یک فرد در شرکت نیست.
• نام‌سرورها katelyn.ns.cloudflare.com و mitch.ns.cloudflare.com بودند. این نام‌ها سرنخ زیرساخت DNS هستند و مالکیت کسب‌وکار توسط Cloudflare را اثبات نمی‌کنند.

زمان دریافت را نگه دارید، چون رکورد ممکن است تغییر کند. رجیستریِ پسوند، شرکت ثبت‌کننده، دارندهٔ دامنه و ارائه‌دهندهٔ نام‌سرور نقش‌های متفاوتی دارند. خالی یا پوشانده‌شدن اطلاعات تماس به‌تنهایی نشانهٔ کلاهبرداری نیست.

۳. دو نوع رکورد عمومی DNS را مقایسه کنید

این دستورهای PowerShell ویندوز فقط DNS را می‌خوانند؛ ایمیل ارسال نمی‌کنند و پورت سرویس‌ها را نمی‌آزمایند:

Resolve-DnsName -Name example.org -Type NS -DnsOnly
Resolve-DnsName -Name example.org -Type MX -DnsOnly

حدود ساعت 05:20 UTC، پاسخ NS همان دو نام‌سرورِ موجود در RDAP را نشان داد. پاسخ MX یک رکورد داشت: اولویت 0 و مقصد .. این حالت null MX است. مطابق RFC 7505، دامنه با آن اعلام می‌کند ایمیل دریافت نمی‌کند. این وضعیت با نبودن رکورد MX فرق دارد. در این تمرین ایمیل نفرستادیم، صندوقی را تست نکردیم و صاحب ایمیلی را شناسایی نکردیم.

۴. فقط نتیجه‌ای را بنویسید که شواهد پشتیبانی می‌کنند

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

قالب قابل استفاده برای یادداشت شواهد

پرسش تحقیق:
دامنه و URL دقیق منبع / دستور DNS:
زمان دریافت به UTC:
فیلد و مقدار مشاهده‌شده:
نقش منبع و وابستگی احتمالی آن:
نتیجهٔ قابل پشتیبانی:
نتیجه‌ای که هنوز ثابت نشده:
بررسی بعدی یا دلیل توقف:

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

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

بررسی دامنه وقتی خطرناک می‌شود که سیگنال‌های ضعیف مثل مدرک قطعی تفسیر شوند. از این اشتباهات دوری کنید:

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

OSINT Jet چطور در اوسینت دامنه کمک می‌کند؟

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

استخراج ساختارمند سرنخ‌ها

OSINT Jet ورودی خام را به موجودیت‌هایی مثل دامنه، ایمیل، شرکت، یوزرنیم، شماره، URL و زمینه پرونده تقسیم می‌کند تا بررسی، مرور و ادامه تحقیق ساده‌تر شود.

گزارش متمرکز بر ریسک

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

بررسی دستی VIP

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