# وقتی یه آپستروف کل دیتابیس رو لو داد

سال ۲۰۰۸، هکری به اسم Alberto Gonzalez با تیمش بیش از ۱۳۰ میلیون شماره کارت اعتباری رو از شرکت Heartland Payment Systems دزدید. نقطه‌ی ورود؟ یه SQL Injection ساده روی یه فرم ورودی که کسی فکرش رو نمی‌کرد.

---

ماجرا اینجاست که SQL Injection یکی از قدیمی‌ترین آسیب‌پذیری‌هاست — ولی هنوز توی OWASP Top 10 جا داره. چرا؟ چون اکثر توسعه‌دهنده‌ها ورودی کاربر رو مستقیم می‌ریزن توی کوئری. وقتی یه فرم لاگین داری که این کوئری رو اجرا می‌کنه:

SELECT * FROM users WHERE username='$input' AND password='$pass'

کافیه تو فیلد username بنویسی:

' OR '1'='1' --

کوئری می‌شه:

SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='...'

شرط همیشه true می‌شه. رمز عبور چک نمی‌شه. تو داخلی.

---

اینجاست که اکثرا فکر می‌کنن تموم شد — ولی تازه شروع شده. وقتی توسعه‌دهنده‌ها می‌فهمن چه خبره، شروع می‌کنن به فیلتر کردن. کلماتی مثل SELECT`، `UNION`، --` رو بلاک می‌کنن. اینجا bypass فیلترها مطرح می‌شه.

یه تکنیک رایج اینه که از comment های inline استفاده کنی تا کلمات کلیدی رو بشکنی:

UN/**/ION SEL/**/ECT null, username, password FROM users--

یا از تغییر case استفاده کنی چون بعضی فیلترها case-sensitive هستن:

uNiOn SeLeCt null, table_name FROM information_schema.tables--

یا اگه فیلتر فضای خالی رو می‌گیره، از %09 یا /**/ به عنوان جایگزین استفاده کنی.

---

نکته‌ای که خیلی‌ها نادیده می‌گیرن اینه: **SQL Injection فقط توی فرم‌ها نیست.** هدرهای HTTP، کوکی‌ها، پارامترهای URL — هر جایی که داده از کاربر گرفته می‌شه و وارد کوئری می‌شه، سطح حمله‌ته. ابزاری مثل sqlmap همین سطح‌ها رو به صورت خودکار اسکن می‌کنه — ولی قبل از اینکه به ابزار تکیه کنی، باید بدونی دستی چطور کار می‌کنه. ابزار بدون درک، فقط سروصداست.

#WebHacking

@codacker_ir

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

برای اولین بار تو کداکر: دنبال مدرس‌های حرفه‌ای هک و امنیت می‌گردیم
چندتا از دوره‌های کداکر درخواستشون اونقدر بالا رفته . می‌خوایم این دوره‌ها رو با بیشترین پروژه، بیشترین تمرین عملی و بالاترین کیفیت به بچه‌ها بدیم — و برای این کار به همکاری با مدرس‌هایی نیاز داریم که خودشون تو میدون بودن، نه فقط تو کتاب.
اگه تو حوزه‌ای از هک و امنیت (فرقی نمی‌کنه شبکه، وب، بگ‌بانتی، لینوکس، هر چی) تجربه واقعی داری و آماده‌ای تدریس کنی، به پشتیبانی پیام بده تا هماهنگی‌ها رو انجام بدیم.
@codacker_support

یه عدد. همین.


۲۰۱۹، یه محقق امنیتی داشت تو پنل کاربری یه فروشگاه آنلاین ایرانی گشت می‌زد. رفت روی صفحه‌ی سفارش‌هاش. URL این بود:

```
/orders/detail?id=1047
```

یه چیزی توی ذهنش کلیک کرد. عدد رو عوض کرد:

```
/orders/detail?id=1046
```

سفارش یه نفر دیگه. اسم، آدرس، شماره‌ی موبایل. کامل.

---

این IDOR هست — Insecure Direct Object Reference. یعنی سرور مستقیم به یه آبجکت ارجاع می‌ده (مثل ID سفارش)، بدون اینکه چک کنه این کاربر **اجازه** داره اون رو ببینه یا نه. احراز هویت هست، Authorization نیست — اینجاست که اکثرا اشتباه می‌کنن.

---

IDOR فقط توی URL نیست. توی body درخواست‌های POST هم پیدا می‌شه:

```json
{
"user_id": 5821,
"action": "get_profile"
}
```

عدد رو عوض کن. اگه سرور جواب داد — آسیب‌پذیری پیدا کردی.

---

این باگ به‌قدری ساده‌ست که خیلی‌ها جدی نمی‌گیرنش — ولی توی گزارش‌های HackerOne، سال‌هاست جزو پردرآمدترین باگ‌هاست. چرا؟ چون تاثیرش مستقیمه. داده‌ی واقعی، آدم‌های واقعی.

وقتی داری یه اپلیکیشن تست می‌کنی، با دو تا اکانت مختلف وارد شو. ID‌های اکانت اول رو با اکانت دوم تست کن. همین.

#IDOR

@codacker_ir

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

**وقتی Burp داری ولی ترافیک نمی‌بینی**

یه نفر تو یه باگ‌بانتی request می‌فرسته، Burp باز داره، ولی Proxy هیچی نمی‌گیره. نه رهگیری، نه لاگ — هیچی. یه ساعت وقت تلف می‌کنه، بعد می‌فهمه مشکل از همون اول بوده: Burp ست نشده بود. درست.

---

Burp Suite یه پروکسیه — یعنی باید بین مرورگر تو و سرور بشینه. برای این کار، دو طرف باید بدونن این واسطه وجود داره. طرف اول مرورگره، طرف دوم سیستم‌عامل — و هر دو باید تنظیم بشن.

**مرحله اول — Listener رو چک کن:**
بعد از باز کردن Burp، برو:

```
Proxy → Options → Proxy Listeners
```

باید یه listener روی `127.0.0.1:8080` فعال باشه. اگه نیست، `Add` بزن و خودت اضافه‌اش کن. این پورت، دروازه‌ی همه‌چیزه.

**مرحله دوم — مرورگر رو هدایت کن:**
مرورگرت باید بدونه ترافیک رو کجا بفرسته. تو Firefox برو:

```
Settings → Network Settings → Manual Proxy
HTTP Proxy: 127.0.0.1 | Port: 8080
```

گزینه‌ی «Use this proxy for HTTPS» رو هم فعال کن — وگرنه نصف ترافیک رو از دست می‌دی.

**مرحله سوم — CA Certificate، اینجاست که اکثرا اشتباه می‌کنن:**
برای سایت‌های HTTPS، Burp باید ترافیک رمزنگاری‌شده رو رمزگشایی کنه. این کار رو با یه گواهی self-signed انجام می‌ده. مرورگر بهش اعتماد نداره — مگه اینکه تو بهش بگی.

از همون مرورگر برو:
```
http://burpsuite
```
گواهی رو دانلود کن، بعد تو Firefox:
```
Settings → Privacy → View Certificates → Import
```
گواهی رو import کن و هر دو گزینه‌ی trust رو تیک بزن.

---

حالا برو یه سایت باز کن. اگه Burp تب `Intercept` توش داره قرمز می‌شه و درخواست‌ها می‌ان — ست شدی. اگه نه، اول چک کن `Intercept is on` فعاله.

این پایه‌ایه، درسته — ولی هر تستی که بعداً می‌کنی، از همین چند خط شروع می‌شه.

#BurpSuite

@codacker_ir

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

اولین برنامه‌ات رو اشتباه انتخاب کردی


یه نفر تو دیسکورد پرسید: «شش ماهه روی HackerOne کار می‌کنم، هنوز هیچی پیدا نکردم — مشکل از منه؟»

وقتی پرسیدم روی کدوم برنامه کار می‌کنه، گفت: Google.


اینجاست که اکثرا اشتباه می‌کنن — نه تو تکنیک، تو انتخاب.

برنامه‌های بزرگ مثل Google، Apple، Facebook رو هزار نفر قبل از تو زیر و رو کردن. Attack surface هنوز هست، ولی باگ‌های سطحی مدت‌هاست که رفتن. تازه‌کار اگه بره سراغ اینا، نه باگ پیدا می‌کنه، نه یاد می‌گیره — فقط خسته می‌شه.


پس چی انتخاب کن؟

دنبال برنامه‌هایی بگرد که **عمر کمتری دارن** — برنامه‌هایی که تازه به پلتفرم اضافه شدن. روی HackerOne فیلتر بزن روی «Launched» و تاریخ رو مرتب کن. برنامه‌های جوون، scope گسترده‌تری دارن و رقیب کمتری. یه برنامه‌ی SaaS کوچیک که سه ماه پیش لانچ شده، به مراتب بهتر از یه غول شش‌ساله‌ست.

یه فاکتور مهم دیگه: **response rate** برنامه رو چک کن. بعضی برنامه‌ها گزارش می‌گیرن، جواب نمی‌دن. قبل از شروع، تو Disclosure tab ببین تیم چقد فعاله.


یه روش ساده برای فیلتر کردن برنامه‌های مناسب روی HackerOne:

```
فیلترها:
- Bounties: Yes
- Managed: Yes (تیم تریاژ داره — جواب سریع‌تره)
- Age: کمتر از ۱ سال
- Scope: Web Application
```

بعد برو تو scope برنامه، ببین wildcard دارن یا نه — مثلاً `*.example.com` یعنی سطح حمله‌ی بزرگ‌تر و شانس بیشتر.


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

#BugBounty

@codacker_ir

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

**وقتی یه باگ‌بانتی‌هانتر ۴۷۳ ساب‌دامین پیدا کرد که تیم امنیتی ازشون خبر نداشت**

یه پنتستر رو تصور کن که روی یه شرکت بزرگ کار می‌کنه. اسکوپ رسمی: فقط `app.example.com`. اما اون قبل از هر چیز دیگه‌ای، subdomain enum می‌زنه — و پیداش می‌کنه: `staging-internal.example.com`، روی یه سرور قدیمی، بدون احراز هویت، با دیتابیس باز.

---

**ساب‌دامین چیه و چرا مهمه؟**

هر سازمان بزرگ ده‌ها یا صدها ساب‌دامین داره — بعضیاشون فراموش‌شده، بعضیاشون تست، بعضیاشون production بدون هیچ hardening‌ای. همین ساب‌دامین‌های فراموش‌شده معمولاً بهترین entry point هستن. وقتی روی `example.com` کار می‌کنی، فقط روی `www` وقت نذار.

---

**دو ابزار اصلی: Amass و Subfinder**

**Subfinder** سریعه، سبکه، و با passive sources مثل VirusTotal، Shodan، CertSpotter و چند ده منبع دیگه کار می‌کنه.
**Amass** سنگین‌تره، قابلیت active enumeration هم داره، و برای کارهای جدی‌تر مناسب‌تره.

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

---

**نصب و اجرا:**

```bash
# نصب Subfinder
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# نصب Amass
go install -v github.com/owasp-amass/amass/v4/...@master

# اجرای ترکیبی و خروجی یکپارچه
subfinder -d example.com -o subfinder_out.txt
amass enum -passive -d example.com -o amass_out.txt

# ادغام و حذف تکراری‌ها
cat subfinder_out.txt amass_out.txt | sort -u > all_subs.txt
```

خروجی `all_subs.txt` رو مستقیم می‌تونی بدی به `httpx` تا ببینی کدوم‌ها live هستن — اینجاست که کار واقعی شروع می‌شه.

---

#Recon

@codacker_ir

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

🔐 وقتی پایتون مثل یه جاسوس مرورگرت رو تقلید می‌کنه

چرا بعضی اسکریپت‌ها بلاک می‌شن و بعضی نه؟ جواب تو HTTP Headers مخفیه.

---

وقتی با `requests.get()` یه سایت رو می‌زنی، سرور می‌فهمه که این یه اسکریپته نه یه انسان. چرا؟ چون User-Agent پیش‌فرض پایتون مثل این می‌مونه که با تابلو "من رباتم" وارد بشی. سرورهای هوشمند این درخواست‌ها رو فیلتر می‌کنن.

Header Spoofing یعنی درخواست HTTP خودت رو طوری بسازی که شبیه یه مرورگر واقعی به نظر برسه. این تکنیک هم تو Bug Bounty کاربرد داره، هم تو Web Scraping، هم وقتی می‌خوای WAF رو دور بزنی و ببینی پشتش چی هست.

نکته کلیدی اینه که فقط User-Agent کافی نیست. سرورهای پیشرفته‌تر Accept، Accept-Language و حتی ترتیب هدرها رو هم چک می‌کنن. یه درخواست واقعی Chrome ده‌ها هدر داره که همه باید منطقی باشن.

---

💻 مثال عملی:

```python
import requests

headers = {
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
'Accept-Language': 'en-US,en;q=0.5',
'Connection': 'keep-alive',
}

response = requests.get('https://target.com', headers=headers)
print(response.status_code)
```

---

🔗 ابزار/منبع: httpbin.org/headers برای تست هدرهایی که می‌فرستی

#python #webscraping #bugbounty #headers #هک_اخلاقی

@codacker

―――――――――――――――――
🎓 مسترکلاس یادگیری هک از صفر تا حرفه‌ای
🔗 codacker.ir/product/hs-masterclass

سه چیزی که یه سیستم رو تسخیر می‌کنن — و اکثرا با هم اشتباه گرفته می‌شن


سال ۲۰۱۶، شبکه‌ی یه بیمارستان بزرگ در آمریکا قفل شد. نه توسط یه هکر با هودی، بلکه توسط سه لایه بدافزار که ماه‌ها پیش نصب شده بودن — و کسی نفهمیده بود.


**Trojan** اولین لایه‌ست. یه فایل به ظاهر سالم — PDF، نرم‌افزار، آپدیت جعلی — که وقتی اجرا می‌شه، در پشتی باز می‌کنه. کارش اینه که وارد بشه. نه بیشتر. Trojan به خودی خود مخرب نیست؛ حامله. payload اصلی رو با خودش می‌آره یا download می‌کنه. همون بیمارستان؟ یه فایل Excel با ماکرو آلوده، نقطه‌ی ورود بود.

**RAT** — یعنی Remote Access Trojan — لایه‌ی دومه. بعد از ورود، این بدافزار به مهاجم یه کنسول کامل می‌ده: صفحه رو می‌بینه، کیبورد رو ضبط می‌کنه، فایل‌ها رو جابجا می‌کنه، حتی دوربین رو روشن می‌کنه. ابزارهایی مثل `njRAT`، `DarkComet` یا `Quasar RAT` سال‌هاست استفاده می‌شن. ارتباط معمولاً روی پورت‌های غیرمعمول یا حتی از طریق DNS tunneling برقراره — که فایروال‌های ساده ازش رد می‌شن.

**Rootkit** لایه‌ی سومه و خطرناک‌ترینه. اینجاست که اکثرا اشتباه می‌کنن — فکر می‌کنن Rootkit یه بدافزار مجزاست. نه. Rootkit یه مکانیزمه؛ مخفی‌کاری در سطح kernel. وقتی Rootkit نصبه، حتی آنتی‌ویروس‌ها فرآیندهای مخرب رو نمی‌بینن. چون Rootkit به سیستم‌عامل دروغ می‌گه. `ls`، `ps`، `netstat` — همه دستکاری‌شده‌ن. تشخیصش نیاز به ابزارهایی مثل `chkrootkit` یا `rkhunter` داره، یا آنالیز حافظه با `Volatility`.

---

یه نمونه‌ی ساده از رفتار RAT در ترافیک شبکه:

```
C2 Server → Victim
GET /cmd?id=victim_001&cmd=screenshot HTTP/1.1
Host: totally-normal-domain.com
```

این HTTP request به نظر معمولیه. اما `cmd=screenshot` داره دستور می‌ده. اگه ترافیک رمزنگاری نشده باشه، یه IDS خوب این pattern رو می‌گیره.

---

قان

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

‎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‎

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