Agentic Attack Tooling Research Series: A Guide to All Twelve Parts

What this series asks: when attack tooling moves from human-operated to agent-operated, does the defender's standing assumption still hold — that attackers err, stall, and give up? Our answer: it holds, and it is more valuable than ever. Because automation's failure modes are predictable regularities, not inscrutable cunning.

Why this series is worth reading

In October 2026, an open-source AI pentesting tool named ARTEX was linked to attacks on South Korean financial institutions; within 48 hours the developer pulled the source and went closed-source.

The value of that event is not another breach — it is that this is the first publicly attributed case of agent-driven attack tooling with readable source code. Previously we could only infer tradecraft from victim logs. This time the tool's own design logic was public: it can be dismantled layer by layer, and countered item by item.

The ten parts

Part one: understanding the event

01 · Case study: ARTEX and the rise of agentic attack tooling The timeline, the technical positioning, three mechanisms that lower the barrier — and three real bottlenecks the attacker exposed. → /en/discoveries/artex-agentic-attack-tooling

Part two: architecture design

02 · The double-graph architecture Most systems track state in one table, letting guesses contaminate facts. This piece unpacks the "truth store + reasoning chain" split, with a cross-domain mapping table. → /en/discoveries/double-graph-agent-architecture

03 · Multi-agent coordination Parallelism brings duplication, silos, and mis-ordering. Four techniques respond: role red lines, process-level exchange, a shared todo list, and a single intent generator. → /en/discoveries/multi-agent-coordination-patterns

Part three: technical principles

04 · Tunnel techniques explained How an attacker builds a channel when firewalls block and the target has no egress: SOCKS5 proxy, HTTP-disguised tunnel, TUN virtual adapter. → /en/discoveries/agent-tunnel-techniques-explained

05 · Credentials and AD concepts Why attackers fixate on the administrator password; Kerberos, hashes, pass-the-hash, lateral movement — explained plainly, plus why credential isolation has the highest return. → /en/discoveries/credentials-and-ad-concepts

09 · Supply chain and third-party risk (new in this series) From open-source packages to outsourced providers to cloud dependencies — much of a modern enterprise's attack surface sits outside its own control. → /en/discoveries/supply-chain-and-third-party-risk

10 · Cloud identity and permissions (new in this series) When workloads move to the cloud, credentials change shape: service principals, roles, temporary credentials, CI/CD secrets. → /en/discoveries/cloud-identity-and-permissions

11 · The economics of ransomware (new in this series) Analysing ransomware as a business: cost structure, revenue model, and three levers for making attacks unprofitable. → /en/discoveries/ransomware-economics

12 · Insider threat and access governance (new in this series) Three types of insider threat (malicious, negligent, coerced) need different responses — plus the problem of AI agents as a new insider identity. → /en/discoveries/insider-threat-and-access-governance

Part four: defense and practice

06 · Honeypots and anti-agent traps Four trap classes aimed at AI (attestation induction, reverse prompt injection, tarpit, egress leakage), plus three rules any team whose agents read external content should adopt. → /en/discoveries/honeypots-and-anti-agent-traps

07 · Defense lessons from a red-team postmortem A rare public postmortem honestly lists six root causes. This piece reads each in reverse as a defensive opportunity, distilled into a usable checklist. → /en/discoveries/defense-lessons-from-red-team-postmortem

08 · Isolated research practice Security research requires touching offensive tooling, but "can study" is not "may use". Five isolation layers and five red lines, from a real deployment. → /en/discoveries/isolated-research-practice

Suggested reading orders

Reader	Path
Just the event	01 → 07
Architecture-minded	02 → 03 → 04 → 05
Defense and risk	01 → 06 → 07 → 08 → 09 → 10 → 11 → 12
Everything (recommended)	01 → 02 → 03 → 04 → 05 → 06 → 07 → 08 → 09 → 10 → 11 → 12

One line

Defense does not need to block — it needs to lengthen. The attacker's weakness is the chain (credentials, scheduling, toolchain), not a single point. And automation's greatest gift to defenders is this: its failure modes are observable and predictable.

Next steps

• To start immediately: begin with 01 · case study
• For the defensive conclusion: jump to 07 · defense lessons from a red-team postmortem
• To study safely in isolation: read 08 · isolated research practice