SKILL: Fast Testing Checklist
Metadata
- Skill Name: fast-checking
- Folder: offensive-fast-checking
- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/fast-checking.md
Description
Speed-optimized offensive checklist for rapid assessment: quick-win vulnerability patterns, fast recon shortcuts, automated scanner configurations, and triage shortcuts. Use for time-boxed assessments, CTF-speed engagements, or initial rapid surface mapping.
Trigger Phrases
Use this skill when the conversation involves any of:
fast check, quick recon, rapid assessment, quick wins, fast triage, speed checklist, time-boxed, CTF, fast scan, quick vulnerability
Instructions for Claude
When this skill is active:
- Load and apply the full methodology below as your operational checklist
- Follow steps in order unless the user specifies otherwise
- For each technique, consider applicability to the current target/context
- Track which checklist items have been completed
- Suggest next steps based on findings
Full Methodology
Fast Testing Checklist
A combination of my own methodology and the Web Application Hacker's Handbook Task checklist, as a Github-Flavored Markdown file
- use lostsec
- maintain a personal payloads repo synced with BLNS/SecLists; keep a tiny “golden” set for smoke tests
Reconnaissance and Analysis
- Map visible content (Manually)
- Perform Functionality Mapping by browsing the application thoroughly.
- Check API Documentation (Public, Swagger/OpenAPI).
- Discover hidden & default content (Directory/File Bruteforce)
- Test for debug parameters
- Identify data entry points (Discover Dynamic Content in Burp Pro)
- Identify the technologies used (Wappalyzer or similiar)
- Research existing vulnerabilities in technology (Google ++)
- Gather wordlists for specific technology (Assetnote, SecList and Naughty Strings)
- Map the attack surface automatically (e.g Burp spider)
- Identify all javascript files for later analysis (in your proxy)
- Scope Discovery (DNS, IPs, Subdomains)
- Capture API contracts (OpenAPI/GraphQL) and diff against observed traffic
- Identify gateways/WAF/CDN (headers, cookies, control pages)
- Identify cache layers and behaviors (vary keys, CDN rules, edge rewrites)
Find Origin IP behind CDN/WAF
- Confirm WAF presence (IP Org check, headers, cookies, block pages).
- Check Historical DNS records (SecurityTrails, DNSDumpster).
- Enumerate Subdomains & check IPs (focus on dev/staging).
- Analyze SSL Certificates (Censys, Shodan - check SANs).
- Analyze Email Headers from target (Received, X-Originating-IP).
- Test potential IPs directly (
curl --resolve example.com:443:<IP> https://example.com/). - Verify potential origin IPs (compare content, headers, certs).
- Probe HTTP/3 Alt‑Svc leakage and SNI/Host mismatches.
Access Control Testing
Authentication
- Test password quality rules
- Minimum length, complexity, history, common password checks?
- Paste functionality disabled?
- Test for username enumeration
- Analyze response time, error messages, status codes for valid/invalid users.
- Check account recovery flow for enumeration.
- Test resilience to password guessing
- Is there rate limiting on login attempts?
- Is there account lockout mechanism?
- Test any account recovery function
- Weak security questions?
- Host header injection in reset emails?
- Token leakage via Referer?
- Lack of token validation?
- Predictable reset tokens?
- Test any "remember me" function
- Analyze token entropy, expiration, security attributes.
- Test any impersonation function
- Test username uniqueness
- Case sensitivity issues? (
adminvsAdmin) - Whitespace trimming issues?
- Case sensitivity issues? (
- Check for unsafe distribution of credentials
- Test for fail-open conditions
- Test any multi-stage mechanisms
- MFA bypasses (enrollment skip, verification manipulation, brute-force codes)?
- Can MFA be disabled easily?
- Parameter pollution vulnerabilities?
- Test OAuth Flows (see dedicated section).
- Test JWT implementations (see dedicated section).
- Check for API Key leakage (source code, client-side JS, mobile apps).
- Test API Key usage (URL, Header, Cookie).
- Test HTTP Basic Auth strength.
- Test HMAC signature implementation if used.
- Validate DPoP/mTLS token binding if advertised.
- Refresh‑token rotation and reuse detection.
- Passkeys/WebAuthn flows including recovery/fallbacks.
Session handling
- Test tokens for meaning
- Test tokens for predictability
- Check for insecure transmission of tokens
- Missing Secure flag on cookies?
- Sent over HTTP?
- Check for disclosure of tokens in logs and URL params
- Check mapping of tokens to sessions(can they be reused?)
- Check session termination
- Does logout fully invalidate the session token?
- Is there session rotation on login/logout/privilege change?
- Check session timeout enforcement (client/server).
- Token reuse across devices; device binding enforced?
- Cookie partitioning/CHIPS behavior in embedded/3rd‑party contexts.
- Check for session fixation
- Are session tokens retained pre/post-authentication?
- Can a specific token be forced on a user?
- Check for cross-site request forgery
- Presence and validation of Anti-CSRF tokens?
- Use of SameSite cookie attribute?
- Check if
LaxorStrict.NonerequiresSecure.
- Check if
- Check Referer/Origin header validation.
- Try removing token parameter.
- Try switching request method (POST -> GET).
- Try changing Content-Type.
- Use Burp CSRF PoC generator.
- Test login CSRF and OAuth state parameter integrity.
- Validate
OriginandSec-Fetch-*headers on state‑changing requests.
- Check cookie scope
- Domain and Path attributes too broad?
- HttpOnly flag missing?
Access controls
- Understand the access control requirements
- Test effectiveness of controls, using multiple accounts if possible
- Can User A access User B's data (same privilege)?
- Can a lower-privileged user access higher-privileged resources/functions?
- Pay attention to features returning sensitive info or modifying data.
- Create accounts for each role.
- Test for insecure access control methods (request parameters, Referer header, etc)
- Check for IDs in URL params, body, cookies, headers (id, user_id, account_id, etc.).
- Try modifying numerical IDs (1 -> 2).
- Try replacing UUIDs/GUIDs.
- Decode/modify encoded IDs (Base64, Hex).
- Add missing IDs (e.g., add
user_idto/api/messages). - Manipulate arrays/objects in JSON/XML requests.
- Change request method (GET -> POST/PUT).
- Change file types (
/resource/1->/resource/1.json). - Wrap IDs in arrays (
id:1->id:[1]) or objects (id:1->id:{id:1}). - Test parameter pollution (
id=attacker&id=victim). - Test wildcard access (
/users/*).
- Test Broken Object Property Level Authorization (BOPLA) / Mass Assignment:
- Can read-only properties be modified via request?
- Can sensitive properties seen in responses be added to update requests?
- Try JSON Patch/Merge Patch content types to sneak forbidden fields.
- Test Broken Function Level Authorization (BFLA):
- Can user A access functions intended only for user B (e.g., admin functions)?
- Try accessing admin endpoints directly (
/admin,/dashboard). - Test different HTTP methods on endpoints (e.g., GET -> PUT/DELETE).
- Check older API versions (
/v1/vs/v3/).