0FFensive_H0riz0n

ابزار دوم Large-Scale OSINT؛ SpiderFoot خب دوستان، بریم سراغ ابزار دوم. اگر در پروژه‌های OSINT بخوایم یک هدف رو از منابع مختلف بررسی کنیم، جمع‌آوری دستی اطلاعات خیلی زود زمان‌بر می‌شه. اینجاست که SpiderFoot می‌تونه کمکمون کنه. SpiderFoot یک ابزار Automated OSINT هست که می‌تونه با استفاده از تعداد زیادی Module، اطلاعات مختلفی رو از منابع عمومی جمع‌آوری کنه. مثلاً یک Target بهش می‌دیم؛ می‌تونه Domain، IP، Username، Email یا موارد دیگه باشه و بعد بر اساس Moduleهای فعال، شروع به جمع‌آوری اطلاعات مرتبط می‌کنه. ✓ اطلاعات مربوط به Domain و DNS ✓بررسی IP و زیرساخت مرتبط ✓ اطلاعات مربوط به Username و Email ✓ بررسی Subdomain ✓ اطلاعات عمومی سرویس‌ها و منابع مختلف یکی از جذابیت‌های SpiderFoot اینه که لازم نیست برای هر مورد، تک‌تک ابزارها رو جداگانه اجرا کنیم. می‌تونیم یک Scan تعریف کنیم و ابزار از چندین منبع مختلف اطلاعات جمع‌آوری کنه و نتایج رو در یک محیط واحد در اختیارمون بذاره. از نظر Workflow هم تقریباً با این روند روبه‌رو هستیم: Target ➜ Modules ➜ Collection ➜ Correlation ➜ Results مثلاً یک Domain در اختیار داریم. SpiderFoot می‌تونه از منابع مختلف اطلاعات مربوط به اون Domain رو جمع‌آوری کنه و بعد نتایج رو در کنار هم قرار بده تا تحلیلگر دید کامل‌تری نسبت به Target داشته باشه. البته اینجا هم یک نکته مهم وجود داره: خروجی SpiderFoot به معنی تأیید شدن اطلاعات نیست. ما باید نتایج رو بررسی کنیم، موارد تکراری یا کم‌اهمیت رو کنار بذاریم و اطلاعات مهم رو با منابع دیگه اعتبارسنجی کنیم. پس SpiderFoot بیشتر کمک می‌کنه مرحله Collection سریع‌تر و گسترده‌تر انجام بشه و تحلیلگر به‌جای انجام تعداد زیادی جست‌وجوی دستی، زمان بیشتری برای تحلیل و ارتباط دادن داده‌ها داشته باشه. در Large-Scale OSINT دقیقاً همین موضوع اهمیت پیدا می‌کنه: هرچقدر حجم اطلاعات بیشتر بشه، Automation و مدیریت درست Collection اهمیت بیشتری پیدا می‌کنه. #اوسینت https://t.me/oFHoz

ابزار اول Large-Scale OSINT؛ Maltego Monitor خب دوستان بریم سراغ اولین ابزار. Maltego Monitor بیشتر زمانی به کارمون میاد که بخوایم یک موضوع یا مجموعه‌ای از منابع رو به‌صورت مداوم رصد کنیم و حجم اطلاعاتی که تولید می‌شه زیاد باشه. فرض کنید چندین منبع، صفحه یا حساب رو زیر نظر داریم و هر روز تعداد زیادی محتوا منتشر می‌شه. اینجا به‌جای اینکه هر روز دستی تک‌تک منابع رو بررسی کنیم، می‌تونیم Monitoring تعریف کنیم تا اطلاعات جدید مربوط به موضوع موردنظر جمع‌آوری و در اختیارمون قرار بگیره. مثلاً می‌تونیم روی یک موضوع، Keyword یا مجموعه‌ای از منابع مشخص تمرکز کنیم و محتواهای جدیدی که مرتبط با اون هستن رو در طول زمان دنبال کنیم. بعد از جمع‌آوری، داده‌ها رو می‌تونیم بر اساس مواردی مثل زمان، منبع یا موضوع مرتب و بررسی کنیم تا از بین حجم زیاد اطلاعات، موارد مهم‌تر رو پیدا کنیم. یک کاربرد جالبش هم زمانی هست که می‌خوایم تغییرات یک موضوع رو در طول زمان ببینیم؛ یعنی فقط دنبال یک پست یا یک اتفاق خاص نیستیم، بلکه می‌خوایم ببینیم در یک بازه زمانی چه روندی شکل گرفته. در واقع اینجا با یک Workflow ساده روبه‌رو هستیم: Source ➜ Collection ➜ Monitoring ➜ Filtering ➜ Analysis مثلاً فرض کنید یک موضوع مشخص رو در چند منبع عمومی رصد می‌کنیم. سیستم می‌تونه اطلاعات جدید رو جمع کنه و ما به‌جای بررسی هزاران مورد، روی مواردی تمرکز کنیم که برای تحقیق ما اهمیت بیشتری دارن. البته یک نکته مهم: هر چیزی که ابزار پیدا می‌کنه الزاماً مرتبط یا معتبر نیست و اینجاست که تحلیلگر باید داده‌ها رو بررسی و اعتبارسنجی کنه. پس Maltego Monitor بیشتر برای جایی مناسبه که حجم اطلاعات بالاست و می‌خوایم به‌جای جست‌وجوی دستی و پراکنده، یک فرایند مداوم برای جمع‌آوری و پایش داشته باشیم. در پست بعدی می‌ریم سراغ یک ابزار دیگه که بیشتر به درد پردازش و کار با حجم بالای داده می‌خوره. #اوسینت https://t.me/oFHoz

گاهی به عنوان یک کارشناس OSINT، یک پروژه سنگین به ما داده می‌شود... فرض کنید یک پروژه به شما سپرده شده که باید یک موضوع، فرد، مجموعه یا جامعه آنلاین رو در چندین پلتفرم مختلف رصد و بررسی کنید. ممکنه با چندین صفحه و حساب در Instagram، کانال و گروه در Telegram، انجمن‌ها، سایت‌ها و پلتفرم‌های مختلف طرف باشیم. حالا فقط یکی از این منابع رو در نظر بگیرید؛ مثلاً یک گروه عمومی که روزانه هزاران پیام داخلش منتشر می‌شه. کنار اون، ممکنه هزاران کامنت، واکنش، پست، تصویر، ویدئو و محتوای دیگه هم وجود داشته باشه. حالا سؤال اینجاست: واقعاً می‌تونیم بشینیم و تک‌تک این اطلاعات رو دستی بررسی کنیم؟ اینجاست که وارد بحث Large-Scale OSINT می‌شیم. در پروژه‌های کوچک، شاید جمع‌آوری اطلاعات به‌صورت دستی کاملاً قابل انجام باشه؛ اما وقتی حجم داده زیاد می‌شه، مسئله کاملاً تغییر می‌کنه. دیگه فقط پیدا کردن اطلاعات مهم نیست؛ باید بتونیم حجم زیادی از اطلاعات رو جمع‌آوری، ذخیره، مرتب، فیلتر و تحلیل کنیم. اما اینجا با چند چالش مهم روبه‌رو می‌شیم: ✓ حجم بسیار زیاد داده ✓ انتشار مداوم اطلاعات جدید ✓ وجود داده‌های تکراری ✓ تفاوت ساختار داده‌ها در پلتفرم‌های مختلف ✓ سختی پیدا کردن اطلاعات مهم در میان حجم زیادی از داده ✓ محدودیت‌های دسترسی و API هر پلتفرم ✓ حذف یا تغییر محتوای آنلاین ✓ و مهم‌تر از همه، زمان فرض کنید در یک پروژه هزاران پیام و پست در اختیار داریم. قرار نیست تحلیلگر تک‌تک اون‌ها رو از ابتدا تا انتها بخونه. اینجاست که ابزارها وارد فرایند می‌شن. ما ممکنه به ابزارهایی برای Collection، Monitoring، Processing و Analysis نیاز داشته باشیم تا بتونیم این حجم اطلاعات رو مدیریت کنیم. برای مثال، داده‌های چند منبع مختلف می‌تونن جمع‌آوری بشن، بعد داده‌های تکراری حذف بشن، اطلاعات بر اساس تاریخ یا موضوع دسته‌بندی بشن و موارد مرتبط برای بررسی دقیق‌تر جدا بشن. در مرحله بعد حتی می‌تونیم داده‌های منابع مختلف رو کنار هم قرار بدیم تا ببینیم آیا بین اون‌ها ارتباطی وجود داره یا نه. مثلاً یک Username در چند پلتفرم مختلف دیده شده، یک موضوع مشخص در چند منبع تکرار شده یا یک الگوی خاص در طول زمان شکل گرفته. اینجا ابزارهایی مثل KNIME می‌تونن برای پردازش، یکپارچه‌سازی و تحلیل حجم بالای داده مفید باشن و ابزارهای تخصصی‌تر هم بسته به نوع پروژه برای Collection و Monitoring مورد استفاده قرار بگیرن. اما یک نکته خیلی مهم: ابزار قرار نیست به جای تحلیلگر OSINT تصمیم بگیره. ابزار می‌تونه حجم زیادی از داده رو جمع‌آوری و مرتب کنه، اما اینکه کدوم داده مهمه، چه ارتباطی بین اطلاعات وجود داره، کدوم اطلاعات قابل اعتماد هست و در نهایت چه نتیجه‌ای می‌شه از اون‌ها گرفت، همچنان به تحلیلگر بستگی داره. پس در Large-Scale OSINT، ما با این زنجیره روبه‌رو هستیم: Collection ↓ Processing ↓ Integration ↓ Analysis ↓ Correlation ↓ Intelligence ↓ Report در واقع هدف این نیست که بیشترین مقدار دیتا رو جمع کنیم. هدف اینه که بتونیم از میان حجم بسیار زیادی از داده‌های عمومی، اطلاعات مرتبط و ارزشمند رو پیدا کنیم و اون‌ها رو به یک خروجی قابل استفاده تبدیل کنیم. انشالله در ادامه میرسیم به معرفی و کار با ابزار های جمع آوری اطلاعات در مقیاس و حجم بالایی از دیتا و تحلیل و یکپارچه سازی دیتای هدف فعلا تا همین حد بدونید که همیشه دنبال یک شخص یا یک آی پی یا لوکیشن داخل عکس نیستیم و ممکنه هدف ما قرار باشه از دل چند ملیون داده بهم ریخته و متفاوت به دست بیاد اینایی که میگیم حاصل تجربه شخصی هست. #اوسینت https://t.me/oFHoz

این چند روز درگیر یک پروژه ای هستم انشالله در هفته جدید چند تا پست آموزشی تاپ باهم میریم.

لطفاً لینوکس رو هم در حد lpic1 کار کنید جزو واجباته. Lpic1 Network+ English language Git برای کار با ابزار های دیگران به این ها احتیاج دارید. از ما گفتن بود

سلام دوستان این هم کد ابزاری که در بخش asn استفاده کردم در فیلم آموزشی. یک فایل بش به هر نامی مثلا cidr.sh بسازید. nano cidr sh بعد دسترسی کامل بش بدید chmod 777 cidr.sh مابقی ابزار هام که میشد asnmap در گیت هاب هست میتونید دانلود کنید. دوستانی که در گروه عضو هستند و فعالیت دارند زودتر ابزار ها و یکسری تریک هارو میگیرند. #!/bin/bash # File: cidr_reverse_dns_multithread.sh if [ -z "$1" ]; then     echo "Usage: $0 <CIDR> [THREADS]"     echo "Example: $0 195.178.2.0/23 50"     exit 1 fi CIDR="$1" THREADS=${2:-50} export OUTPUT_FILE="found_domains.txt" > "$OUTPUT_FILE" echo "[*] Scanning PTR records for $CIDR" echo "[*] Threads: $THREADS" echo "------------------------------------" check_ip() {     local addr="$1"     local result     result=$(host "$addr" 2>/dev/null)     if [[ $result == *"pointer"* ]]; then         local hostname         hostname=$(echo "$result" | awk '{print $5}')         echo "[+] $addr -> $hostname"         echo "$hostname" >> "$OUTPUT_FILE"     fi } export -f check_ip ip2int() {     local a b c d     IFS=. read -r a b c d <<< "$1"     echo $(( (a<<24) + (b<<16) + (c<<8) + d )) } int2ip() {     local ip=$1     echo "$(( (ip>>24)&255 )).$(( (ip>>16)&255 )).$(( (ip>>8)&255 )).$(( ip&255 ))" } IFS=/ read base mask <<< "$CIDR" start=$(ip2int "$base") hosts=$(( 2 ** (32 - mask) )) end=$(( start + hosts - 1 )) for ((ip=start; ip<=end; ip++)); do     int2ip "$ip" done | xargs -P "$THREADS" -I {} bash -c 'check_ip "{}"' echo "------------------------------------" echo "[+] Done. All found domains saved in $OUTPUT_FILE"

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

رصدگر یا کارشناس OSINT؟ تفاوت دقیقاً کجاست؟ حالا که با مفهوم رصد و پایش آشنا شدیم، بیایید یک قدم جلوتر بریم. رصدگر و کارشناس OSINT ممکنه در خیلی از پروژه‌ها کنار هم کار کنن، اما الزاماً یک کار انجام نمی‌دن. ✓ رصدگر بیشتر دنبال اینه که «چه چیزی در حال اتفاق افتادنه؟» ✓ کارشناس OSINT بیشتر دنبال اینه که «این اطلاعات چه چیزی درباره موضوع مورد بررسی به ما می‌گه؟» فرض کنید یک سازمان، یک فرد، یک گروه یا یک موضوع خاص رو به‌صورت مداوم زیر نظر داریم. رصدگر ممکنه هر روز منابع مشخص رو بررسی کنه، اطلاعات جدید رو ثبت کنه و وقتی اتفاق قابل توجهی رخ داد، اون رو به تیم مربوطه اطلاع بده. اما وقتی یک مورد مهم شناسایی شد، ممکنه کار به مرحله بعد برسه. اینجاست که کارشناس OSINT وارد تحقیق عمیق‌تر می‌شه. مثلاً یک حساب جدید پیدا شده. رصدگر می‌گه: «این حساب جدید ایجاد شده و فعالیتش با موضوعی که ما زیر نظر داریم مرتبطه.» حالا کارشناس OSINT می‌تونه سؤال‌های بیشتری مطرح کنه: این حساب متعلق به چه کسیه؟ چه ارتباطاتی با حساب‌های دیگه داره؟ چه سابقه‌ای داره؟ اطلاعات موجود در منابع مختلف چطور با هم ارتباط پیدا می‌کنن؟ کدوم اطلاعات قابل تأییده و کدوم فقط یک ادعاست؟ و در نهایت، این اطلاعات چه چیزی به ما می‌گه؟ این دقیقاً همون جاییه که «رصد» می‌تونه تبدیل به «تحقیق و تحلیل اطلاعات» بشه. در مدل‌های حرفه‌ای Intelligence هم جمع‌آوری، پردازش و تحلیل مراحل متفاوتی از یک فرایند به حساب میان و در عمل دائماً به هم برمی‌گردن. بنابراین قرار نیست بگیم: «رصدگر فقط دیتا جمع می‌کنه و کارشناس OSINT همه‌چیز رو تحلیل می‌کنه.» دنیای واقعی به این سادگی نیست و وظایف بسته به سازمان و پروژه می‌تونن با هم هم‌پوشانی داشته باشن. نکته اصلی اینه که بدونیم: رصد = آگاهی مستمر از آنچه در حال رخ دادنه اوسینت = استفاده از منابع عمومی برای پاسخ دادن به یک سؤال اطلاعاتی و تولید یک نتیجه قابل اتکا و اتفاقاً یکی از بهترین حالت‌ها اینه که این دو در کنار هم کار کنن: رصد → شناسایی اتفاق مهم → تحقیق OSINT → تحلیل → گزارش اینجاست که یک رصد ساده می‌تونه تبدیل به یک Intelligence واقعی بشه. #رصد https://t.me/oFHoz

رصدگر دقیقاً چه کاری انجام می‌دهد؟ خب دوستان، دیروز گفتم که می‌خوام نقش یک «رصدگر» رو در مقابل کارشناس OSINT براتون توضیح بدم. ما قبلاً درباره وظایف کارشناس OSINT صحبت کردیم، اما در دنیای واقعی خیلی از فعالیت‌هایی که انجام می‌شن، ممکنه در حیطه «رصد و پایش» قرار بگیرن و الزاماً یک پروژه کامل OSINT محسوب نشن. پس باید این دو رو از هم تفکیک کنیم. رصدگر بیشتر با «پایش مستمر» سر و کار داره. یعنی به جای اینکه منتظر بمونه یک سؤال یا پرونده مشخص برای تحقیق به وجود بیاد، یک موضوع، فرد، سازمان، رسانه، شبکه اجتماعی یا حتی یک کلیدواژه مشخص رو به‌صورت مداوم زیر نظر می‌گیره. مثلاً یک سازمان رو در نظر بگیرید که می‌خواد بدونه در فضای عمومی اینترنت درباره خودش چه اتفاقی در حال رخ دادنه. رصدگر می‌تونه مواردی مثل: ✓ انتشار محتوای جدید ✓ تغییرات مهم در صفحات و کانال‌ها ✓ افزایش ناگهانی صحبت درباره یک موضوع ✓ اخبار و گزارش‌های مرتبط ✓ واکنش کاربران ✓ تغییر در روند یا الگوی انتشار محتوا ✓ ظهور یک حساب یا منبع جدید رو زیر نظر داشته باشه. اینجا هدف اصلی لزوماً این نیست که از همان ابتدا یک پرونده کامل OSINT تشکیل بدیم. هدف اینه که: «اتفاق مهم رو به‌موقع ببینیم، ثبت کنیم و در صورت نیاز برای بررسی عمیق‌تر به تحلیلگر یا تیم مربوطه منتقل کنیم.» این مدل کار واقعاً در دنیا وجود داره؟ بله. برای مثال، EUvsDisinfo که یک پروژه وابسته به European External Action Service است، از Data Analysis و Media Monitoring برای شناسایی، جمع‌آوری و تحلیل موارد اطلاعات نادرست استفاده می‌کنه و نتایج رو در یک پایگاه داده عمومی ثبت می‌کنه. از طرف دیگه، Bellingcat نمونه متفاوتیه؛ این مجموعه بیشتر روی Open Source Investigation تمرکز داره و از داده‌های عمومی برای تحقیقات عمیق، راستی‌آزمایی و ساختن پرونده‌های مستند استفاده می‌کنه. حتی در روش‌شناسی Bellingcat برای تحقیقات Open Source، ثبت مراحل تحقیق، حفظ محتوای مشاهده‌شده و دنبال کردن مسیرهای مختلف تحقیق به‌صورت سیستماتیک مورد توجه قرار گرفته. پس می‌تونیم یک تفاوت ساده در ذهن داشته باشیم: رصدگر می‌پرسه: «چه اتفاقی در حال رخ دادنه؟» کارشناس OSINT می‌پرسه: «با اطلاعاتی که داریم، چطور می‌تونیم درباره این موضوع تحقیق کنیم و به یک نتیجه قابل استناد برسیم؟» و البته این دو نقش می‌تونن در یک تیم کنار هم کار کنن و حتی در بعضی سازمان‌ها وظایفشون با هم هم‌پوشانی داشته باشه. به همین دلیل، اگر در پروژه‌های بزرگ OSINT دیدید یک تیم دائماً در حال جمع‌آوری، پایش و دسته‌بندی اطلاعاته، نباید تصور کنیم همه اعضای اون تیم الزاماً «کارشناس OSINT» به یک معنی واحد هستن؛ ممکنه بخشی از اون‌ها وظیفه Monitoring و بخشی وظیفه Analysis و Investigation داشته باشن. و دقیقاً همین تفاوت، موضوعیه که در ادامه می‌خوایم بیشتر بازش کنیم. #رصد https://t.me/oFHoz

می‌خوام در مورد رصد و پایش بهتون بگم و نقش یک رصد گر رو در مقابل یک کارشناس اوسینت بگم

یک نکته مهم در ادامه بحث این مطلب آخر ما رو می‌رسونه به یکی از بخش‌های مهم و فنی OSINT؛ یعنی ردگیری Domain و IP. وقتی در جریان بررسی یک حمله به یک IP یا Domain می‌رسیم، چیزی که می‌بینیم همیشه لزوماً هدف اصلی ما نیست. مثلاً اگر یک Domain پشت Cloudflare یا سرویس‌های مشابه باشه، IPای که ما مشاهده می‌کنیم ممکنه مربوط به Cloudflare باشه، نه سرور اصلی. اینجاست که در OSINT، با استفاده از روش‌ها و ابزارهای مختلف، سعی می‌کنیم ببینیم آیا می‌شه سرنخی از IP و زیرساخت واقعی پشت اون Domain پیدا کرد یا نه. البته همیشه هم قرار نیست به IP اصلی برسیم؛ ممکنه زیرساخت به‌درستی محافظت شده باشه و هیچ اطلاعات قابل اتکایی در منابع عمومی وجود نداشته باشه. پس در OSINT فقط پیدا کردن یک IP مهم نیست؛ مهم اینه که بفهمیم این IP واقعاً متعلق به کجاست و چه ارتباطی با هدف تحقیق ما داره. این موضوع خودش یکی از بخش‌های جذاب OSINT تکنیکال هست و روش‌ها و ابزارهای مخصوص خودش رو داره. #اوسینت https://t.me/oFHoz

نقش کارشناس OSINT در بررسی یک حمله سایبری تا اینجا بیشتر درباره OSINT به‌عنوان روشی برای جمع‌آوری و تحلیل اطلاعات عمومی صحبت کردیم. اما یک سؤال جالب‌تر: اگر یک حمله سایبری اتفاق بیفته، کارشناس OSINT دقیقاً کجای ماجرا وارد می‌شه؟ فرض کنیم یک سازمان با یک Incident امنیتی مواجه شده. تیم DFIR / Incident Response سیستم آلوده رو بررسی می‌کنه، بدافزار رو تحلیل می‌کنه و از داخل نمونه بدافزار، لاگ‌ها یا شواهد موجود، به چند Indicator of Compromise (نشانه‌های به‌خطر افتادن سیستم) می‌رسه. مثلاً مشخص می‌شه بدافزار با یک IP یا Domain ارتباط داشته. از اینجا به بعد، برای ساده‌تر شدن متن، از همون واژه Indicator استفاده می‌کنیم. ✓ مرحله اول؛ گرفتن سرنخ از تیم فنی تیم Incident Response ممکنه چند Indicator در اختیار کارشناس OSINT قرار بده: IP → Domain → URL → Hash کارشناس OSINT قرار نیست دوباره بدافزار رو تحلیل کنه؛ بلکه روی اطلاعات بیرونی مربوط به این Indicatorها تحقیق می‌کنه. ✓ مرحله دوم؛ بررسی سابقه Indicator حالا بررسی می‌کنیم این Indicator قبلاً جایی دیده شده یا نه. مثلاً: ✓ آیا در گزارش‌های امنیتی قبلی وجود داشته؟ ✓ آیا قبلاً با یک بدافزار خاص مرتبط بوده؟ ✓ آیا Domainهای دیگری به همین زیرساخت ارتباط داشتن؟ ✓ آیا در تحقیقات امنیتی قبلی از این Indicator نام برده شده؟ ✓ این زیرساخت در چه بازه‌ای فعال بوده؟ اینجا کم‌کم یک Indicator ساده تبدیل می‌شه به یک سرنخ اطلاعاتی. ✓ مرحله سوم؛ Correlation حالا یکی از مهم‌ترین قسمت‌های کار شروع می‌شه. فرض کنیم تیم فنی فقط یک IP پیدا کرده. کارشناس OSINT بررسی می‌کنه و متوجه می‌شه همین IP در گذشته با چند Domain مختلف ارتباط داشته. بعد مشخص می‌شه یکی از اون Domainها در یک گزارش امنیتی قدیمی کنار یک نمونه بدافزار خاص دیده شده. حالا چند تکه اطلاعات داریم: IP ↓ Domain ↓ بدافزار ↓ Incident قبلی وقتی این ارتباط‌ها از منابع معتبر و مستقل تأیید بشن، می‌تونیم Context خیلی بیشتری درباره Incident داشته باشیم. ✓ مرحله چهارم؛ ساختن تصویر بزرگ‌تر اینجا OSINT می‌تونه به تیم Threat Intelligence کمک کنه. ممکنه از چند Indicator مختلف متوجه بشیم که: چند IP به چند Domain مرتبط هستن و بعضی از اون‌ها قبلاً در رخدادهای مشابه دیده شدن. حالا به‌جای اینکه فقط بگیم:

این IP مشکوکه

می‌تونیم بگیم:

«این Indicator در چند منبع مستقل با زیرساخت‌ها و رخدادهای قبلی ارتباط داشته و این ارتباط‌ها در یک بازه زمانی مشخص مشاهده شده.»

این تفاوت بین جمع‌آوری اطلاعات و تحلیل اطلاعاته. ✓ یک نکته خیلی مهم اینجا نباید سریع نتیجه بگیریم: IP = مهاجم چون یک IP می‌تونه متعلق به یک سرور واسطه، سرور هک‌شده، VPN، Proxy یا زیرساخت دیگری باشه. بنابراین کارشناس OSINT باید بین این دو تفاوت قائل بشه: «این IP در حمله دیده شده» با «مالک این IP همان مهاجم است» این دو تا اصلاً یک معنی ندارن. ✓ در نهایت چه چیزی تحویل تیم امنیتی می‌شه؟ خروجی کارشناس OSINT می‌تونه یک گزارش تحلیلی باشه که مثلاً شامل این موارد باشه: Indicator: IP / Domain First Seen: اولین مشاهده شناخته‌شده Related Infrastructure: زیرساخت‌های مرتبط Historical References: سوابق و گزارش‌های قبلی Related Malware: بدافزارهای مرتبط، در صورت وجود شواهد Confidence: میزان اطمینان به ارتباط Sources: منابعی که اطلاعات از اون‌ها به دست اومده این گزارش دوباره به تیم‌های Threat Intelligence، DFIR و Incident Response برمی‌گرده و به اون‌ها کمک می‌کنه تصویر کامل‌تری از اتفاقی که افتاده داشته باشن. جمع‌بندی پس کارشناس OSINT در یک Incident لزوماً کسی نیست که «حمله رو پیدا می‌کنه». تیم فنی شواهد رو از داخل محیط پیدا می‌کنه؛ کارشناس OSINT کمک می‌کنه این شواهد رو با اطلاعات بیرونی و سوابق قبلی تطبیق بدیم و Context بیشتری به دست بیاریم. در واقع: DFIR → چه اتفاقی داخل سیستم افتاده؟ OSINT / Threat Intelligence → این Indicatorها بیرون از سازمان چه سابقه و ارتباطی دارن؟ و وقتی این دو کنار هم قرار می‌گیرن، تیم امنیتی می‌تونه تصویر بسیار کامل‌تری از Incident به دست بیاره. #اوسینت https://t.me/oFHoz

نقش کارشناس OSINT در بررسی یک حمله سایبری تا اینجا بیشتر درباره OSINT به‌عنوان روشی برای جمع‌آوری و تحلیل اطلاعات عمومی صحبت کردیم. اما یک سؤال جالب‌تر: اگر یک حمله سایبری اتفاق بیفته، کارشناس OSINT دقیقاً کجای ماجرا وارد می‌شه؟ فرض کنیم یک سازمان با یک Incident امنیتی مواجه شده. تیم DFIR / Incident Response سیستم آلوده رو بررسی می‌کنه، بدافزار رو تحلیل می‌کنه و از داخل نمونه بدافزار، لاگ‌ها یا شواهد موجود، به چند Indicator of Compromise (نشانه‌های به‌خطر افتادن سیستم) می‌رسه. مثلاً مشخص می‌شه بدافزار با یک IP یا Domain ارتباط داشته. از اینجا به بعد، برای ساده‌تر شدن متن، از همون واژه Indicator استفاده می‌کنیم. ✓ مرحله اول؛ گرفتن سرنخ از تیم فنی تیم Incident Response ممکنه چند Indicator در اختیار کارشناس OSINT قرار بده: IP → Domain → URL → Hash کارشناس OSINT قرار نیست دوباره بدافزار رو تحلیل کنه؛ بلکه روی اطلاعات بیرونی مربوط به این Indicatorها تحقیق می‌کنه. ✓ مرحله دوم؛ بررسی سابقه Indicator حالا بررسی می‌کنیم این Indicator قبلاً جایی دیده شده یا نه. مثلاً: ✓ آیا در گزارش‌های امنیتی قبلی وجود داشته؟ ✓ آیا قبلاً با یک بدافزار خاص مرتبط بوده؟ ✓ آیا Domainهای دیگری به همین زیرساخت ارتباط داشتن؟ ✓ آیا در تحقیقات امنیتی قبلی از این Indicator نام برده شده؟ ✓ این زیرساخت در چه بازه‌ای فعال بوده؟ اینجا کم‌کم یک Indicator ساده تبدیل می‌شه به یک سرنخ اطلاعاتی. ✓ مرحله سوم؛ Correlation حالا یکی از مهم‌ترین قسمت‌های کار شروع می‌شه. فرض کنیم تیم فنی فقط یک IP پیدا کرده. کارشناس OSINT بررسی می‌کنه و متوجه می‌شه همین IP در گذشته با چند Domain مختلف ارتباط داشته. بعد مشخص می‌شه یکی از اون Domainها در یک گزارش امنیتی قدیمی کنار یک نمونه بدافزار خاص دیده شده. حالا چند تکه اطلاعات داریم: IP ↓ Domain ↓ بدافزار ↓ Incident قبلی وقتی این ارتباط‌ها از منابع معتبر و مستقل تأیید بشن، می‌تونیم Context خیلی بیشتری درباره Incident داشته باشیم. ✓ مرحله چهارم؛ ساختن تصویر بزرگ‌تر اینجا OSINT می‌تونه به تیم Threat Intelligence کمک کنه. ممکنه از چند Indicator مختلف متوجه بشیم که: چند IP به چند Domain مرتبط هستن و بعضی از اون‌ها قبلاً در رخدادهای مشابه دیده شدن. حالا به‌جای اینکه فقط بگیم:

«این IP مشکوکه.»

می‌تونیم بگیم:

«این Indicator در چند منبع مستقل با زیرساخت‌ها و رخدادهای قبلی ارتباط داشته و این ارتباط‌ها در یک بازه زمانی مشخص مشاهده شده.»

این تفاوت بین جمع‌آوری اطلاعات و تحلیل اطلاعاته. ✓ یک نکته خیلی مهم اینجا نباید سریع نتیجه بگیریم: IP = مهاجم چون یک IP می‌تونه متعلق به یک سرور واسطه، سرور هک‌شده، VPN، Proxy یا زیرساخت دیگری باشه. بنابراین کارشناس OSINT باید بین این دو تفاوت قائل بشه: «این IP در حمله دیده شده» با «مالک این IP همان مهاجم است» این دو تا اصلاً یک معنی ندارن. ✓ در نهایت چه چیزی تحویل تیم امنیتی می‌شه؟ خروجی کارشناس OSINT می‌تونه یک گزارش تحلیلی باشه که مثلاً شامل این موارد باشه: Indicator: IP / Domain First Seen: اولین مشاهده شناخته‌شده Related Infrastructure: زیرساخت‌های مرتبط Historical References: سوابق و گزارش‌های قبلی Related Malware: بدافزارهای مرتبط، در صورت وجود شواهد Confidence: میزان اطمینان به ارتباط Sources: منابعی که اطلاعات از اون‌ها به دست اومده این گزارش دوباره به تیم‌های Threat Intelligence، DFIR و Incident Response برمی‌گرده و به اون‌ها کمک می‌کنه تصویر کامل‌تری از اتفاقی که افتاده داشته باشن. جمع‌بندی پس کارشناس OSINT در یک Incident لزوماً کسی نیست که «حمله رو پیدا می‌کنه». تیم فنی شواهد رو از داخل محیط پیدا می‌کنه؛ کارشناس OSINT کمک می‌کنه این شواهد رو با اطلاعات بیرونی و سوابق قبلی تطبیق بدیم و Context بیشتری به دست بیاریم. در واقع: DFIR → چه اتفاقی داخل سیستم افتاده؟ OSINT / Threat Intelligence → این Indicatorها بیرون از سازمان چه سابقه و ارتباطی دارن؟ و وقتی این دو کنار هم قرار می‌گیرن، تیم امنیتی می‌تونه تصویر بسیار کامل‌تری از Incident به دست بیاره. #اوسینت https://t.me/oFHoz

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