یه شب، ۱۴ تا تب مرورگر باز بود فقط برای پیدا کردن ساب‌دامین‌های یه هدف

‎subfinder‎ زدی، بعد ‎httpx‎، بعد باید خروجی رو دستی می‌ریختی تو ‎naabu‎، بعد نتیجه رو کپی می‌کردی تو یه فایل برای ‎nuclei.‎ هر بار همین مسیر، هر بار همین کپی-پیست‌ها. یه جایی وسط این چرخه از خودت می‌پرسی: چرا این کارو خود ابزارها برام نمی‌کنن؟

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

یه ‎CLI‎ شخصی یعنی تو منطق ریکان خودتو کد می‌کنی، نه اینکه دنبال فلگ درست تو داکیومنت ابزار بقیه بگردی:

#!/bin/bash
subfinder -d $1 -silent | httpx -silent | tee live.txt | naabu -silent -o ports.txt
nuclei -l live.txt -t cves/ -o result.txt

حالا کل زنجیره‌ای که قبلاً ۲۰ دقیقه دستی انجام می‌دادی، شده یه دستور: ./recon.sh target.com. این فقط سرعت نیست — کنترله. تو می‌دونی دقیقاً چی داره اجرا میشه، کجا باگ می‌خوره، کجا باید فیلتر اضافه کنی. ابزار آماده رو هر کسی داره، منطق شخصی رو فقط تو داری.

#‎Automation‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

یکسری مقاله جدید تو بازی هانت و هک و باگ بانتی دارم مینویسم مثل همین میزارم تو سایت

یه فایل ‎main.js‎ دو مگابایتی، و یه ‎API‎ ‎Key‎ که کسی حواسش نبوده

یه بار روی یه تارگت بزرگ، بعد از دو روز گشتن تو صفحات وب و هیچی پیدا نکردن، رفتم سراغ همون فایل‌های ‎js‎ که همه رد می‌شن ازشون چون «خب فقط کده دیگه». نیم ساعت بعد یه ‎endpoint‎ داخلی پیدا کردم که تو هیچ صفحه‌ای لینک نشده بود — /‎api/v2/internal/debug.‎ همون یکی کل مسیر گزارش رو باز کرد.

فایل‌های ‎JS‎ بعد از ‎build‎ و ‎minify‎ شدن، برای چشم آدم یه بلوک بی‌شکل کدن. ولی برای ابزاری مثل ‎LinkFinder‎ فقط یه رشته‌ست که باید توش الگو پیدا کرد — مسیرهایی که با /‎api‎ یا /‎v1‎ شروع می‌شن، دامنه‌های ساب‌دامین داخلی، توکن‌هایی که با الگوی ‎base64‎ یا ‎JWT‎ جفت و جور می‌شن.

کار رو این‌جوری شروع کن:

python3 linkfinder.py -i https://target.com/static/main.js -o cli

ولی خروجی خام کافی نیست. باید فیلترش کنی — چون ۹۰٪ چیزی که پیدا می‌کنه یا ‎CDN‎ عمومیه یا مسیر استاتیک بی‌ارزش. اونجاست که اکثرا اشتباه می‌کنن: همه‌ی ‎endpoint‎ها رو دستی چک می‌کنن بدون اولویت‌بندی. دنبال الگوهایی باش که کلمات ‎admin‎، ‎internal‎، ‎debug‎، ‎v2‎، ‎config‎ توشونه — این‌ها معمولا اون چیزیه که تیم ‎dev‎ فراموش کرده مخفی کنه.

برای ‎secret‎ها هم اگه دنبال دستیه بیشتری هستی، ‎trufflehog‎ یا ‎gitleaks‎ رو مستقیم رو همون فایل ‎js‎ اجرا کن، نه فقط رو ریپو گیت. خیلی وقتا کلید ‎API‎ مستقیم تو کد فرانت هاردکد شده، چون کسی فکر نکرده مرورگر هم یه محیط عمومیه.

#‎JSRecon‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

یه ‎commit‎ حذف شده، ولی کلید هنوز زنده‌ست

یه محقق بگ‌بانتی یه ریپوی عمومی رو پیدا کرد که ۲ سال پیش یه بار ‎AWS‎ ‎key‎ توش ‎commit‎ شده بود، بعد یه ‎commit‎ دیگه اومده و فایل رو پاک کرده. تیم امنیتی شرکت فکر می‌کرد چون فایل حذف شده، مشکل حل شده. ولی کلید تو ‎history‎ گیت هنوز بود، فعال بود، و همون باگ‌بانتی چند هزار دلار پاداش گرفت.

اینجاست که اکثرا اشتباه می‌کنن: فکر می‌کنن ‎git‎ ‎history‎ یعنی چیزی که الان می‌بینی. ولی هر ‎commit‎ قبلی هنوز تو .‎git‎ هست، حتی اگه از ‎HEAD‎ حذف شده باشه. برای همینه ابزارهایی مثل trufflehog و gitleaks کل تاریخچه‌ی ‎commit‎ها رو اسکن می‌کنن، نه فقط فایل‌های فعلی. یه دستور ساده:

trufflehog git https://github.com/target/repo --only-verified

فلگ --only-verified مهمه — یعنی فقط سکرت‌هایی که واقعاً تست شدن و فعالن رو نشون بده، نه هر رشته‌ای که شبیه ‎API‎ ‎key‎ به نظر میاد. با gitleaks هم می‌تونی همین کار رو با یه ‎config‎ سفارشی برای پترن‌های خاص شرکت انجام بدی:

gitleaks detect --source . --report-format json

نکته‌ی طلایی: فورک‌ها و ‎pull‎ ‎request‎های بسته‌شده هم ‎history‎ خودشون رو دارن. خیلی از تیم‌ها ریپوی اصلی رو تمیز نگه می‌دارن ولی یادشون میره یه ‎PR‎ قدیمی که هیچوقت ‎merge‎ نشده، هنوز یه ‎commit‎ با کلید واقعی توش داره.

#‎SecretScanning‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

هر بار از صفر توضیح می‌دی، یعنی سیستمت خرابه

یه هفته با ‎Claude‎ ‎Code‎ رو یه پروژه هانت کار می‌کردی، هر ‎session‎ جدید که باز می‌کردی باید دوباره می‌گفتی «فقط تو ‎scope‎ بگرد، از ‎Burp‎ استفاده کن، خروجی رو تو ‎recon/‎ بریز». تا وقتی فهمیدی این کارو یه بار برای همیشه می‌شه انجام داد.

فایل ‎CLAUDE.md‎ دقیقاً همینه — یه حافظه‌ی دائمی برای پروژه‌ت. تو ریشه‌ی هر پروژه بگذارش، هر بار که ‎Claude‎ ‎Code‎ اجرا می‌شه، این فایل رو خودکار می‌خونه. یعنی قوانین بازی، ابزارهای مجاز، ساختار فولدرها، حتی سبک گزارش‌نویسیت رو یه بار می‌نویسی و تا آخر پروژه دیگه لازم نیست تکرار کنی.

مثال واقعی:

# CLAUDE.md
- Scope فقط *.target.com، ساب‌دامین‌های خارج از scope رو نادیده بگیر
- برای recon از subfinder + httpx استفاده کن، خروجی رو تو recon/subs.txt بریز
- هیچ exploit ای رو خودکار اجرا نکن، فقط PoC بساز و نشونم بده
- گزارش‌ها به فرمت Markdown، تو reports/ ذخیره شن

اینجاست که اکثرا اشتباه می‌کنن: فکر می‌کنن ‎CLAUDE.md‎ یه فایل توضیحاتیه برای خودشون. نه — این فایل قرارداد رفتاریه با مدل. هر خطش یعنی «این کارو همیشه همینطوری انجام بده، تا وقتی خودم عوضش کنم».

#‎ClaudeCode‎
@codacker_ir

هک یه ابزار نیست. یه طرز فکره.

وقتی ‎CVE‎ داغه ولی ‎nuclide‎ ‎template‎ نداره

‎CVE-2024-XXXX‎ یه ساعت پیش منتشر شده. توییتر پره از ‎PoC‎، ولی تو ‎nuclei‎ هنوز هیچ ‎template‎ ای براش نیست. تا فردا که ‎community‎ یکی بنویسه، صد نفر دیگه قبل از تو زدنش. اینجا دقیقاً جاییه که اکثرا منتظر می‌مونن — تو نباید بمونی.

اول ‎PoC‎ رو باز کن و دقیق ببین درخواست چیه: کدوم ‎endpoint‎، کدوم پارامتر، و ‎response‎ موفق چه شکلیه. مثلاً یه ‎LFI‎ ساده روی یه پلاگین وردپرس معمولاً یه ‎GET‎ با ‎path‎ ‎traversal‎ می‌زنه و تو ‎response‎ دنبال یه رشته‌ی خاص مثل ‎root‎:‎x‎:0:0 می‌گرده. این دقیقاً چیزیه که باید تبدیلش کنی به ‎matcher.‎

id: CVE-2024-XXXX
info:
  name: Plugin LFI
  severity: high
http:
  - method: GET
    path:
      - "{{BaseURL}}/wp-content/plugins/xyz/file.php?path=../../../../etc/passwd"
    matchers:
      - type: word
        words:
          - "root:x:0:0"

نکته‌ای که اکثرا نادیده می‌گیرن: ‎matcher‎ رو خیلی ‎generic‎ ننویس. اگه فقط دنبال ‎status‎ ‎code‎ 200 باشی، ‎false‎ ‎positive‎ میاد بارونی. همیشه یه ‎condition‎ ترکیبی بذار — هم ‎status‎، هم یه ‎word‎ خاص که فقط تو حالت آسیب‌پذیر پیدا میشه. همین چند خط، وقتی درست تست بشه، می‌تونه ساعت‌ها قبل از هرکس دیگه‌ای روی هزاران ‎target‎ اجرا بشه.

#‎Nuclei‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

۴۰۰ تا ‎XSS‎ پیدا کردی، ۳۹۷ تاش ‎false‎ ‎positive‎ بود

یه اسکن روی ساب‌دامین‌های یه شرکت زدی و ‎nuclei‎ برگشته با ۴۰۰ تا ‎finding.‎ حالا چیکار می‌کنی؟ می‌شینی همه رو دستی چک کنی و ۶ ساعت وقتت می‌ره برای چیزی که ۹۰ درصدش ‎reflected‎ ‎input‎ تو یه پارامتر بی‌مصرفه؟

اینجاست که اکثرا اشتباه می‌کنن: فکر می‌کنن ‎triage‎ یعنی خودشون بشینن رد کنن. در حالی که می‌تونی یه لایه‌ی ‎AI‎ بذاری وسط ‎pipeline‎ که قبل از چشم تو، یافته‌ها رو غربال کنه. مدل رو با ‎context‎ بده — نوع ‎endpoint‎، پارامتر، ‎response‎ ‎body‎، و ‎status‎ ‎code‎ — و ازش بخواه بگه این ‎finding‎ واقعاً ‎exploitable‎ هست یا نه، و چرا.

مثلاً یه اسکریپت ساده با ‎API‎ یه ‎LLM‎:

curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $KEY" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role":"user","content":"این finding رو بررسی کن: XSS در پارامتر q، پاسخ سرور رفلکت شده بدون encode. آیا واقعاً exploitable است یا false positive؟ دلیل بده."}]
  }'

خروجی این نیست که مدل بهت ‎PoC‎ بده — خروجی اینه که ۹۰٪ نویز رو حذف می‌کنه و فقط چیزی می‌مونه که ارزش دستی چک کردن داره. تفاوت بین بگ‌هانتری که خسته می‌شه و اونی که مقیاس می‌گیره، دقیقاً همینه.

#‎AI_BugBounty‎

@codacker_ir

هک یه ابزار نیست. یه طرز فکره.

یه ساب‌دامین که دیروز نبود

یه محقق روی یه هدف سه ماه کار کرده بود، همه‌چی رو زده بود، صفر باگ. یه روز صبح چک کرد، یه ساب‌دامین جدید بالا اومده بود: staging-api-v2.target.com. همون روز یه ‎IDOR‎ ساده توش پیدا کرد که تو نسخه‌ی قبلی اصلاً وجود نداشت. تفاوتش این بود که اون بار، رسن نکرده بود دستی — یه پایپ‌لاین داشت که هر شب براش گزارش می‌داد.

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

یه پایپ‌لاین ساده اینه: هر ۲۴ ساعت ‎subfinder‎ یا ‎amass‎ رو روی هدف بزن، خروجی رو با دیتای دیروز دیف بگیر، فقط ‎new‎ ‎entries‎ رو نگه دار، بعد ‎httpx‎ بزن ببین کدوم زنده‌ست و روی چه پورتی. اگه فرقی بود، بفرست تو یه چنل تلگرام یا دیسکورد.

subfinder -d target.com -silent > today.txt
diff yesterday.txt today.txt | grep '>' > new_subs.txt
cat new_subs.txt | httpx -silent -sc -title

بعد یه اسکریپت کوچیک کرون بزن که هر روز اینو اجرا کنه و نتیجه رو با ‎webhook‎ تلگرام بفرسته. کل بازی رو عوض می‌کنه، چون دیگه تو منتظر نمی‌مونی که هدف تغییر کنه و بعد بفهمی — اولین نفری هستی که می‌فهمی.

#‎ContinuousRecon‎

@codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

یه اسکن با ۲۰۰ تا ‎Critical‎ که هیچکدوم واقعی نبودن

یه بار روی یه دامنه ‎nuclei‎ رو با کل ‎template‎‌های ‎exposures‎ زدم، خروجی شد ۲۰۰ تا "‎vulnerable‎". رفتم سراغ گزارش‌نویسی، فهمیدم ۱۹۰ تاش رو یه صفحه ۲۰۰ برگردونده بوده که توش کلمه‌ی «‎error‎» یا «‎config‎» بوده — نه یه اکسپوژر واقعی. کل وقتم رفت رو باطل کردن یه چیزی که خودم باعثش شده بودم.

مشکل از ‎matcher‎ بود، نه از تارگت. وقتی فقط ‎status‎: 200 رو چک می‌کنی یا با یه ‎word‎ ساده مثل "‎admin‎" ‎match‎ می‌گیری، هر صفحه‌ای که این کلمه رو تو ‎HTML‎ یا حتی تو یه کامنت داشته باشه، برات مثبت می‌شه. اینجاست که اکثرا اشتباه می‌کنن: فکر می‌کنن ‎matcher‎ یعنی «یه نشونه پیدا کن»، در حالی که ‎matcher‎ یعنی «شرایطی بساز که فقط حالت واقعی توش صدق کنه».

راه‌حل: از ‎matchers-condition‎: ‎and‎ استفاده کن و چند تا شرط رو ترکیب کن — نه فقط ‎status‎ ‎code‎، بلکه ‎status‎ و ‎body‎ و حتی ‎negative‎ ‎matcher‎ برای رد کردن ‎false‎ ‎positive‎ های شناخته‌شده:

matchers-condition: and
matchers:
  - type: status
    status:
      - 200
  - type: word
    words:
      - "X-Powered-By: Express"
    part: header
  - type: word
    negative: true
    words:
      - "404 Not Found"
      - "page not found"
    part: body

هر خط اضافه‌ای که به ‎matcher‎ می‌زنی، یعنی یه ‎false‎ ‎positive‎ کمتر تو گزارش نهاییت. قبل از اجرای اسکن بزرگ، یه بار روی ۲-۳ تا تارگت شناخته‌شده تست کن که ‎matcher‎ دقیقاً همون چیزی رو می‌گیره که فکر می‌کنی، نه هر چیزی که شبیهشه.

#‎Nuclei‎

@codacker_ir

هک به ابزار نیست. به طرز فکره.

سه صبح، ساب‌دامین جدید زده بیرون — تو خوابی

یه بگ‌هانتر رو می‌شناسم که سه هفته دنبال یه ‎IDOR‎ روی یه ساب‌دامین می‌گشت که هنوز اصلاً وجود نداشت. چون فقط وقتی یادش می‌افتاد دستی ‎subfinder‎ می‌زد. وقتی خودکارش کرد، همون هفته‌ی اول یه ‎asset‎ جدید پیدا کرد که تو ‎recon‎ دستی هیچ‌وقت بهش نمی‌رسید — چون خب، آدم خسته میشه، یادش می‌ره، یا اصلاً وقت نداره هر روز یه دستور رو تکرار کنه.

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

0 3 * * * /usr/bin/subfinder -d target.com -o /home/user/recon/subs_$(date +\%F).txt

این یعنی هر شب ساعت ۳ صبح، بدون اینکه تو بیدار باشی، لیست ساب‌دامین‌ها آپدیت می‌شه. اما ‎cron‎ محدودیت داره — لاگ‌گیری ضعیفه، دیباگش سخته، و اگه بخوای منطق شرطی بذاری (مثلاً فقط وقتی چیزی تغییر کرد، دیف بگیر و به خودت تلگرام بفرسته) دستت بسته می‌مونه.

اینجا APScheduler تو پایتون وارد می‌شه. می‌تونی همون منطق رو با کنترل کامل بنویسی:

from apscheduler.schedulers.blocking import BlockingScheduler

def run_scan():
    # subfinder + httpx + diff check
    pass

sched = BlockingScheduler()
sched.add_job(run_scan, 'interval', hours=6)
sched.start()

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

#‎Automation‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

یه ساعت پورت‌اسکن رو یه ‎IP‎ که مال ‎Cloudflare‎ بوده، نه هدف

یه بار روی یه پروگرام ‎bug‎ ‎bounty‎، سه ساعت داشتم روی یه ‎IP‎ دیپ اسکن می‌زدم — پورت‌ها، سرویس‌ها، همه‌چی. آخرش فهمیدم اون ‎IP‎ مال ‎Akamai‎ بوده، نه سرور واقعی هدف. کل نتیجه‌ی اسکنم شده بود اطلاعات زیرساخت یه شرکت ‎CDN‎ که هیچ ربطی به ‎scope‎ نداشت.

اینجاست که اکثرا اشتباه می‌کنن: لیست ‎subdomain‎ رو ‎resolve‎ می‌کنن، ‎IP‎ می‌گیرن، و مستقیم می‌رن سراغ ‎nmap‎ و اسکن عمیق — بدون اینکه چک کنن این ‎IP‎ اصلاً پشت ‎CDN‎ هست یا نه. نتیجه؟ وقت، رقاله، و گاهی حتی ‎abuse‎ ‎report‎ از طرف ‎Cloudflare‎ یا ‎Akamai‎ بابت اسکن سرورهاشون.

راه‌حل ساده‌ست: قبل از هر اسکنی، ‎IP‎ رو در برابر رنج‌های شناخته‌شده‌ی ‎CDN‎ چک کن. با httpx می‌تونی مستقیم ‎CDN‎ ‎detection‎ بگیری:

httpx -l ips.txt -cdn -json | jq 'select(.cdn==false)'

یا با ابزار cdncheck از ‎ProjectDiscovery‎، یه پاس سریع رو کل لیست بزن و فقط ‎IP‎‌هایی که ‎false‎ برمی‌گردونن رو نگه دار — یعنی همونایی که واقعاً دارایی هدفن، نه یه ‎edge‎ ‎node‎ از یه شبکه‌ی توزیع‌شده.

این یه قدم، بین کسایی که وقتشون رو رو ‎noise‎ می‌سوزونن و کسایی که مستقیم می‌رن سراغ دارایی واقعی، خط می‌کشه.

#‎Recon‎

@‎codacker_ir‎

هک یه ابزار نیست. یه طرز فکره.

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

قراره هانت گروهی و استارتش و بزنیم تو دیسکورد اونایی که هستن و هانت و از متوسط به بالا بلدن تو pm قبلی اعلام کنن

اگر سوال بود که چرا اینجا انجامیش نمیدیم

از دوستان قدیم تا جدید رو مستر کلاس ازمون و مدرک اضافه شد برای تمام دوره‌ها 🤟

به تعداد آمار خوبیه صبر میکنم تا 2 روز پین میکنم این پیام و ....