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

یه هفته با ‎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 روز پین میکنم این پیام و ....

قبل از ورود زدن به هانت و دیسکورد که احتمالا هفته آینده خواهد بود ی خبر خوب دارم..

ی کیت رایگان شروع هک آماده کردیم برای یچه‌هایی که میخوان هک و شروع کنن

هم کامله هم جمع و جوره