​

Attack Methodology

Golem follows a structured, phase-based methodology modeled on real-world external-attacker operations. Deep audits run the full chain; shallow audits run the deterministic phases and a focused probe; autonomous audits steer the chain with your brief.

​

Phase 0 — Baseline scan (deterministic, always)

Before any agent runs, a deterministic baseline scanner executes:

• Security headers — HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and similar, with specific remediation guidance per missing header
• Common-path probe — well-known sensitive paths: .env, /.git/config, /wp-admin/, /actuator/env, /api/swagger, swagger/openapi documents, and others
• Nuclei templates — pinned template sets run in parallel with the agent, capped to the remaining time budget so they can never overrun the audit

Baseline findings are deterministic and fully structured. They’re deduplicated against agent findings before the final audit is written.

​

Phase 1 — Asset discovery

Golem maps the target’s external surface using passive OSINT only — nine sources including crt.sh, CertSpotter, HackerTarget, AlienVault OTX, Anubis, URLScan.io, Wayback Machine, and RapidDNS, merged and deduplicated. Every candidate is then validated: does it resolve, is anything answering, does it respond meaningfully, and what stack is it running? See Subdomain Enumeration.

​

Phase 2 — Live probing

Each live asset is probed: HTTP fingerprinting, tech-stack identification, and a first-pass exposure check. This produces the working target set and feeds the stack-fingerprint registry that later validates agent claims.

​

Phase 3 — Agent assessment (deep / autonomous)

The Golem agent takes over inside the darkops sandbox. It plans its own chain, informed by everything the deterministic phases found:

• Recon & surface mapping — crawling (katana), content discovery (ffuf, feroxbuster), endpoint and parameter discovery
• Stack-aware exploitation — claims about specific stacks (WordPress, Firebase, Spring, Django, etc.) are only allowed if the stack was actually observed in recon
• Injection testing — SQLi (sqlmap), SSTI, XXE, SSRF, deserialization, CORS misconfiguration, HTTP smuggling, ASP.NET-specific attacks
• Authentication attacks — JWT abuse, OAuth flow analysis, session handling, OTP and password-reset flaws
• Custom probes — dedicated tooling at /opt/giga/ for high-frequency checks: ssti_probe.sh, jwt_attack.sh, oob_manager.sh, smuggle_test.sh, and more

Out-of-band callbacks (interactsh) confirm blind vulnerabilities. A browser (Chrome + selenium) handles JavaScript-heavy targets and authenticated flows.

​

Phase 4 — Finding validation

Every agent claim is checked at submission time (execution ledger + stack registry), deduplicated against baseline results, and re-verified post-hoc — including replaying read-only curl commands to compare live responses against what the agent claimed. See Findings & Evidence.

​

Phase 5 — Reporting

Score calculation, coverage summary, and the Markdown report. The agent is force-stopped before the wall-clock budget expires so reporting always completes.

​

What’s deliberately excluded

Audits run as an external attacker. No customer-supplied stack hints, credentials, environment files, or distinguishing audit headers are sent to the sandbox — if external recon discovers internal information, the agent may use it, but it starts blind like any real adversary. Internal-network tooling (Active Directory attack paths, LAN lateral movement) doesn’t apply to the external web attack surface.

​

Phase ordering and pivots

The methodology is not strictly linear. Golem continuously re-plans: an exposed admin panel found in live probing becomes the agent’s first target; a credential captured mid-chain unlocks authenticated testing; a new subdomain discovered late still gets probed.

​

Modes recap

​

Next steps