First Commit

docs/defense-en.md

@@ -0,0 +1,389 @@
+# Defending Against and Detecting Autonomous AI Attacks
+
+> This document helps **defenders** understand how an **autonomous AI penetration agent** such as ARTEX operates, so that you can build the capability to **detect and block** such attacks. It is not a guide to carrying out attacks. Use everything here only to protect systems you own or have explicit written authorization to test. Probing or attacking someone else's information and communications network without authorization is itself a crime (see the [security and misuse warning in the top-level README](../README.en.md)).
+>
+> 한국어판: **[자율 AI 공격 방어·탐지 가이드 (defense-ko.md)](defense-ko.md)**.
+
+An autonomous AI attack tool turns a penetration test — once a manual process a single operator ran by hand — into a 24/7 automated process in which an LLM agent **breaks goals down on its own, executes real tools, and accumulates discoveries**. The adversary a defender faces shifts from "one skilled attacker" to "a swarm of agents that never tire and never rest." This guide sets out what that shift demands of detection and response.
+
+---
+
+## 1. How an autonomous AI attack differs from a traditional scanner
+
+A traditional vulnerability scanner (for example a fixed-signature tool) fires a predefined checklist in order and stops. An autonomous agent like ARTEX is structured differently. As described in the [system architecture](../README.en.md#system-architecture), the following elements combine to **run multi-stage attack chains to completion without human intervention**:
+
+- **Role-separated multi-agents.** The work is split across `goals` (which decomposes objectives), a `planner` (the only producer of intents, which decides the next direction), multiple `worker`s (each of which executes one intent with real tools), and a `mainagent` (the human-in-the-loop point). The planner is the sole intent generator, and the workers carry those intents out in parallel.
+- **State accumulated in a dual graph.** "What exists" (the asset graph) and "how far it has been tested" (the exploration graph) are built separately and joined by anchors. As a result the attack **deepens incrementally**, revisits the same asset from new angles, and builds each next step on prior observations.
+- **An event-driven closed loop.** Every time the graph changes, the planner wakes, assigns the next intent, and the worker's writes trigger the next round in turn. This cycle does not stop until a goal is proven.
+- **Stable progression of serial attack chains.** The planner records dependency ordering — "find an injection point → obtain credentials → move laterally → escalate privileges" — once into a shared todolist, and only assigns an intent to the next step once its predecessor is satisfied. So the attack chain runs to completion without derailing, even in a stateless session environment.
+- **The LLM varies payloads per context.** Because the tools and payloads it executes are not fixed constants in code but values the LLM generates by reading the situation, the shape of each individual request varies slightly.
+
+### Why this is harder to detect
+
+- **Fixed signatures match poorly.** Because payloads change with context, rules that match a known malicious string exactly (WAF signatures) are easy to slip past.
+- **It can proceed slowly, and in human-like bursts.** The agent rests between rounds and changes direction based on findings, so detection based purely on rate ("many requests in a short window") can miss it.
+- **Reconnaissance and intrusion run as one flow.** The gap in which a human reviews recon results and then attacks manually days later disappears, so the time from first contact to data exfiltration shrinks dramatically.
+
+### Why it can still be detected — behavior is hard to hide
+
+Static fingerprints (the User-Agent, a specific payload string) can be changed at the operator's discretion. But the **behavioral pattern of an autonomous agent** is the essence of the attack and is hard to change. Sections 2 through 4 below weight this behavior-based view.
+
+- A single source (or a small set of rotating sources) **chains requests of several different characters** (reconnaissance → enumeration → authentication attempts → exploitation) **within a coherent session**.
+- Exploration that **continues without pause** even during hours when a human would stop out of fatigue.
+- Adaptive, non-random progression that **systematically mutates the next request** using hints from failed responses.
+
+---
+
+## 2. Fingerprints a defender can observe (IoCs and signatures)
+
+Split the fingerprints into two views. **(a) The target (victim) view** — what you can see in ARTEX traffic aimed at your system. **(b) The operator/forensic view** — what you can see on a host where ARTEX actually ran (or on a compromised relay). It is important not to mix the two. The static fingerprints visible from the target side are limited; the behavioral fingerprints are the core.
+
+### (a) Target view — traffic aimed at your system
+
+- **The enrichment lookup User-Agent `artex-enrich/1.0`.** When ARTEX automatically enriches an asset (DNS and HTTP checks), it sends a direct `GET` to the target with this User-Agent (`enrich/enrich.go`). This path is generated by ARTEX itself, independent of the LLM, and is characterized by **not following redirects, disabling keep-alive, and reading only the start of the response to extract the `<title>`**. The default concurrency is 4. So when lookups with the `artex-enrich/1.0` UA that **open a short-lived connection, issue a single GET, read only the title, and disconnect** arrive at several assets at once, they strongly suggest ARTEX-family enrichment traffic. However, the operator can change the UA, so **its absence does not mean safety**.
+- **The actual attack traffic follows the tool's default fingerprint.** The worker sends requests through the real tools it runs (external tools executed via Bash, plus HTTP). To route this traffic through its own recording proxy, ARTEX injects `HTTP_PROXY` and the proxy CA path into the subprocess environment variables — but it **does not force an ARTEX-specific User-Agent onto attack traffic**. So the User-Agent and headers the target sees are **the defaults of whatever tool ran at that moment** (the default UA of the various command-line tools). If the operator did not customize it, a common automation-tool fingerprint remains; if they did customize it, the traffic may be disguised to look like a normal browser. Therefore, **do not rely on single-UA matching; combine it with behavior-based detection**.
+- **The worker's built-in WebFetch tool leaves a `norma/0.4` User-Agent.** Unlike the external tools the worker runs via Bash (above), the HTTP lookups ARTEX performs directly through the norma SDK (`github.com/Autumn-27/norma`) — its WebFetch tool — carry that SDK's default User-Agent `norma/0.4` during the attack phase. It is observable on the wire where traffic is plaintext HTTP (or inspected at a TLS-terminating point), and a [Suricata rule (sid 1000003)](../detections/suricata/) matches this prefix (`norma/`). However, this UA is **not ARTEX-unique** — other tools built on the norma SDK share it — so, like `artex-enrich/1.0`, it is a supporting clue rather than proof, and because Bash-run tools use their own UAs, **its absence does not mean safety**.
+- **There is no built-in rate limit.** ARTEX itself has no target-traffic rate limiting, and the request rate is decided by the external tools the LLM drives. Instead, by default 3 workers per task run in parallel, so **several intents may proceed against one target simultaneously**. That means the attack can appear as a "slow single session" or as "multiple angles running at once," so a single fixed threshold is hard to catch it with.
+- **Behavioral signatures (most important).** The **co-occurrence** of the patterns below points to an autonomous agent:
+  - From one source (or a small set of rotating sources), **reconnaissance → directory/endpoint enumeration → parameter probing → authentication/injection attempts chain at short intervals**.
+  - Consecutive requests to the same endpoint that **mutate systematically in response to the status code and length** of the reply (adaptive, not random fuzzing).
+  - A session that **continues without pause for long stretches**, outside normal human operating hours.
+  - Persistence that keeps trying **bypass variations** even after failures (401/403/429) instead of stopping.
+
+### (b) Operator/forensic view — a host where ARTEX ran
+
+Use these when, during an intrusion investigation, you look for traces of ARTEX installed and run on a relay/transit host.
+
+- **Default listening port `:8787`.** This is the default HTTP listening address of the ARTEX server (`cmd/artex/main.go`, changeable with `--addr`). If an internal host is serving the management UI (dashboard, tasks, asset graph) on this port, that is grounds to suspect an ARTEX instance.
+- **The recording MITM proxy `127.0.0.1:8788`.** This is the default address of the local proxy that intercepts and records every worker Bash/HTTP execution end to end (the default of `--proxy` in `cmd/artex/main.go`, loopback only). Because it generates its own CA to decrypt and record TLS (`mitmproxy-ca-cert.pem`), two clues help: whether the host carries **a trusted CA certificate installed by ARTEX**, and whether there are traces of `HTTP_PROXY` and proxy-CA-path environment variables being injected into subprocesses. This injection goes into every worker tool ARTEX spawns and the variable names are hard-coded in the source (`agent/worker.go`), so **a running process carrying a proxy var together with a mitmproxy CA-trust var** is a more specific tell than the bare port. The [host-triage tool](../detections/triage/README.md) checks for this combination in `/proc` (or, for a forensic image, a captured env dump).
+- **The self-update callback `artex-selfupdate`.** This is the User-Agent used when the self-updater queries GitHub releases (`selfupdate/`). If egress logs show requests leaving for a code-repository host with this UA, that suggests the presence of an ARTEX binary.
+- **The dual graph in PostgreSQL.** A database with tables such as `exploration_nodes`, `assets`, `companies`, and `activity`, plus an `agent_prompts` seed, is characteristic of the ARTEX data store.
+- **DB-backed regex approval rules and audit log.** The intercept rules that evaluate tool calls are stored in the DB and evaluated by priority as regular expressions (`intercept/`). Blocked calls are recorded in the audit log (`GET /api/audit`) together with a control framing that begins with `【ARTEX 平台管控·非目标防御】` (a "platform control / non-target defense" framing). So if this string appears in a compromised host's audit records, it supports the conclusion that ARTEX ran there.
+- **Destructive-command hunting indicators.** The command patterns ARTEX's own guard embeds as block targets are, in effect, the mirror image of the command family an autonomous agent **might attempt**. In host command auditing, treat the following as hunting indicators: `rm -rf`, `mkfs`, `dd of=/dev/`, `shred`/`wipe`, SQL `DROP DATABASE`/`DROP TABLE`/`TRUNCATE`, MongoDB `drop`/`dropDatabase`, Redis `FLUSHALL`/`FLUSHDB`, `-X DELETE` on `curl`/`wget`, and data-exfiltration pipes of the form `curl … | nc …`. That said, the data-exfiltration pipe at the end is different in kind. It is not a destruction command but a signal that data is being carried out (exfiltration), and unlike the destruction patterns above, ARTEX's guard embeds this one rule disabled by default (its curl/wget/nc pipe pattern misfires on legitimate pentest reverse-shell and data-transfer pipes). The deployable destructive-command hunting rule ([`destructive_command_hunting.yml`](../detections/sigma/destructive_command_hunting.yml)) is scoped to destruction and does not include it, so hunt the exfiltration pipe as a separate, heavily tuned indicator rather than blocking it outright.
+
+> In short: **anchor target-side defense on behavioral fingerprints, and use static UAs (`artex-enrich/1.0`, `norma/0.4`, and the like) only as supporting clues.** The operator/forensic fingerprints (`:8787`, `127.0.0.1:8788`, `artex-selfupdate`, the DB schema, the audit-log framing) are valid **when investigating a compromised transit host**.
+
+### Why IP-address blocking is a weak first line of defense
+
+When a security incident becomes known, posts that say "here is a shared list of attacker IPs — block them at your firewall" commonly circulate on social media and community forums. Whatever the good intent of those sharing them, **we do not recommend dropping an unofficial IP list of unclear provenance straight into your block rules** — and this holds especially against autonomous AI attacks.
+
+- **The source is hard to verify.** For an unofficial list posted by an individual, there is no way to confirm who collected it or on what basis, and no way to filter out the IPs unrelated to the incident that may be mixed in.
+- **It ages quickly.** An autonomous agent constantly rotates its origin IP through VPNs, cloud instances, and hijacked relay servers (the "small number of rotating sources" in (a) above). An attack IP observed yesterday was likely already discarded today, so blocking the list still lets the attacker return from a different IP.
+- **The false-blocking risk is high.** If the list mixes in shared ranges, CDNs, or legitimate cloud IPs, the moment you block them you also cut off healthy customer traffic or internal services. Combined with automatic blocking (section 6 below), the false-block damage spreads even faster.
+
+This does not mean IP blocking is useless. It becomes meaningful **when you receive official indicators of compromise (IoCs) from a response agency or trusted threat intelligence and apply them after reviewing their validity window and false-positive potential.** But blocking a single IP line is only a stopgap that chases a rotating origin; what lasts is the **behavior** that is hard to change (the behavior-based detection in sections 2–4) and the **reduction of attack surface** (the hardening in sections 3 and 5 — trimming exposed assets, patching, MFA). This guide's premise — fingerprints can change, but behavior is hard to hide — applies here too.
+
+---
+
+## 3. Entry points attackers target, and hardening
+
+An autonomous agent targets the **same weaknesses** a human attacker does, but repeats them faster and more relentlessly. Below are the priority hardening points from a defender's view.
+
+### 3.1 Externally exposed attack surface and known (n-day) vulnerabilities
+
+The first and most reliable entry point an autonomous agent targets is not a clever zero-day but a **known, already-disclosed vulnerability left exposed and unpatched**. Typical targets are perimeter devices (VPNs, firewalls), externally reachable management/operations consoles, application servers, middleware, and frameworks (for example widely exploited WebLogic- or Struts-class software), and **auxiliary systems attached for partners, recruitment, or employees rather than the main service**. An autonomous agent enumerates the exposed surface automatically from its asset graph, then targets n-days with public exploits (PoCs) **before the patch is applied**, across hundreds of assets at once. The speed of this find-an-exposed-weakness-and-try-it loop is where the asymmetry with a human attacker opens up.
+
+- **Reduce the attack surface.** Continuously maintain an inventory of internet-exposed assets, management consoles, and auxiliary systems, and move anything that does not need to be external behind the internal network, a VPN, or an allowlist.
+- **Patch known vulnerabilities fast.** Disclosed vulnerabilities (n-days) in perimeter devices, web servers, application servers, and middleware are an autonomous agent's top target, so keep the patch-application interval as short as possible, starting with components that have public PoCs. To decide what to patch first, use a catalog of vulnerabilities with confirmed in-the-wild exploitation as a prioritization input: cross-reference the [CISA KEV (Known Exploited Vulnerabilities) catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) with the domestic advisories in 7.1 (KISA / Boho Nara). Relying on a living official list like this, rather than pinning specific CVE numbers in a document, keeps you from falling behind as an autonomous agent shifts to whichever n-day is circulating next.
+- **Tighten interfaces that must stay exposed.** For management/operations interfaces you cannot avoid exposing, add source restrictions (IP allowlists), MFA, and a VPN to block unauthenticated enumeration itself.
+- **Manage auxiliary systems to the same standard as the main service.** Keep partner, recruitment, and employee auxiliary systems at the same patch and monitoring level as the main service. The entry point an autonomous agent works through is often one of these auxiliary paths rather than the main service. Hardening of the authentication flow itself continues in 3.2 below.
+
+For detection, requests that target a specific vulnerability's known path (URL, parameters) arriving from outside in a short-interval chain are a signal of n-day scanning. This signal shows up best when combined with the behavioral fingerprints in Section 2 and the same-source multi-stage correlation rule in Section 4.
+
+### 3.2 Auxiliary authentication and identity-verification flows
+
+**Authentication and identity-verification flows attached through a different path than the main service** — add-on services, partner channels, recruitment channels — are often loosely validated and become bypass targets. An autonomous agent enumerates these paths automatically and reads response differences to find bypass conditions systematically.
+
+- Unify identity-verification and authentication steps **to the same strength as the main service**, and audit every auxiliary path that could be bypassed.
+- **Re-verify authentication state transitions** (unauthenticated → authenticated, user → privileged) **on the server**, and do not blindly trust the trust markers the client sends (cookies, headers, parameters).
+- Check the **lifetime, reuse, and guessability** of identity-verification tokens and one-time codes.
+
+### 3.3 API authentication and authorization (IDOR and privilege escalation)
+
+- Enforce a **server-side ownership/authorization check** on every object access (block IDOR, where changing only an identifier opens someone else's resource).
+- Enumerate horizontal and vertical privilege-escalation paths yourself. Because an autonomous agent mechanically increments and decrements identifiers and tries them in bulk, it quickly finds **holes that a single manual test missed**.
+
+### 3.4 Credential stuffing
+
+Attacks that replay leaked ID/password lists are amplified by an autonomous agent through **speed and distribution**.
+
+- Apply **adaptive rate limiting** (based on IP, account, device, and behavior) to login and identity-verification endpoints.
+- Enforce **multi-factor authentication (MFA)** on sensitive operations. Even if stuffing lands a correct password, the second factor blocks it.
+- Block preemptively with **compromised-credential detection** (checking against known leak lists; anomalous login location/velocity).
+- Alert on **distribution shifts** in login failures and successes (a sudden low-and-wide attempt).
+
+### 3.5 Session, token, and secret management
+
+- Minimize the **scope, lifetime, and renewal** of session tokens, and re-authenticate at every sensitive transition.
+- **Do not expose** API keys or internal tokens in responses, logs, or error messages (an autonomous agent actively harvests clues from error responses).
+
+---
+
+## 4. Detection rules and log patterns (practical)
+
+Written as product-independent **pseudo-rules**. Translate them into your own WAF/IPS/SIEM syntax. The rules below that rest on static fingerprints are shipped as ready-to-deploy [Sigma rules (`detections/sigma/`)](../detections/). The core behavior and correlation detection (4.1 and 4.2) does not reduce to a single rule either, but the behavioral indicators grounded in ARTEX's source are shipped as deployable [Sigma correlation rules (`detections/sigma/correlation/`)](../detections/) — enrichment velocity, enrichment fan-out, guard-block burst, and the guard marker co-occurring with a destructive command on one host. The pure web multi-stage correlation (enumerate → probe → authenticate) still needs base rules specific to your environment, because that multi-stage pattern does not reduce to a single ARTEX-unique User-Agent; a ready-to-tune generic Sigma base template for it is provided in 4.2 below — adapt it to your SIEM and baseline as a starting point. The two ARTEX User-Agents observable on the wire — the enrichment prober's `artex-enrich/1.0` (sid 1000001–1000002) and the norma SDK WebFetch tool's attack-phase `norma/0.4` (sid 1000003) — are also shipped as [Suricata rules (`detections/suricata/`)](../detections/suricata/).
+
+### 4.1 WAF/IPS (behavior-based)
+
+- When **requests of different characters** from a single source (a low share of static-resource requests, a high share of enumeration, parameter probing, and authentication attempts) **continue as one session**, raise the score.
+- Weight **consecutive requests that mutate in response** to status code and body length (high entropy but an adaptive, non-random pattern).
+- Tag a known automation UA such as `artex-enrich/1.0` as **immediately high-risk**, but do not read the absence of a UA as safety.
+
+### 4.2 SIEM correlation rules
+
+- **Same-source multi-stage correlation:** when (a) directory/endpoint enumeration, (b) parameter probing, and (c) authentication/injection attempts are **all observed within a short window** from the same IP/ASN/session, raise an "autonomous attack suspected" alert.
+- **Time-of-day anomaly:** a single session that **continues without pause for a long stretch**, outside the service's normal traffic distribution.
+- **Persistence after failure:** a source that receives 403/429 and keeps going with **bypass variations** instead of stopping.
+
+A deployable base template for the **same-source multi-stage correlation** above follows. Because the attack traffic carries no ARTEX-unique User-Agent, this template is a **generic behavioral rule**, unlike the ARTEX-source-grounded rules under `detections/sigma/`. It watches only the behavior — "one source runs enumeration, probing, and authentication within a short window" — not any attack tool's fingerprint. It is self-contained: three sub-rules plus a temporal correlation that fires only when one client satisfies all three within the window.
+
+```yaml
+# ── Generic behavioural template (NOT an ARTEX-specific signature) ──
+# The same-source multi-stage web pattern in defense guide section 4.2
+# (enumeration -> probe -> auth). ARTEX's attack traffic carries no ARTEX
+# fingerprint, so unlike the rules under detections/sigma/ this is a generic
+# behavioural starting point, not grounded in ARTEX source. Field names
+# (SigmaHQ webserver taxonomy) and the thresholds/window WILL need tuning to
+# your own logs and baseline. Self-contained: three sub-rules plus a temporal
+# correlation that fires only when all three occur from one client in the window.
+title: Web Endpoint Enumeration Burst From One Source
+id: f03c360c-dc33-4a8a-afa8-821b1ff5c4e3
+status: experimental
+description: |
+    Stage 1 of the same-source multi-stage pattern in the ARTEX defense guide section 4.2: a
+    burst of endpoint or directory enumeration from a single client, seen as a high rate of 404
+    and 400 responses in a short window. This is generic behaviour, not an ARTEX-specific
+    signature; tune the count and window to your own baseline. On its own this leg is low signal
+    and earns weight only inside the correlation below.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.reconnaissance
+    - attack.t1595
+logsource:
+    category: webserver
+detection:
+    enum_misses:
+        sc-status:
+            - 404
+            - 400
+    condition: enum_misses
+falsepositives:
+    - Broken links, authorised vulnerability scanners, or misconfigured clients that generate
+      many 404 responses.
+level: low
+---
+title: Web Parameter Or Path Injection Probe From One Source
+id: f9296e55-6b7a-4030-b5f7-5f7b146233be
+status: experimental
+description: |
+    Stage 2 of the same-source multi-stage pattern: parameter or path probing, matched here as
+    query strings carrying common injection or traversal markers. This leg is unavoidably
+    signature-like and noisy on its own, so it is scored low and earns weight only inside the
+    correlation below. Extend the marker list to your own probe corpus and WAF categories; it is
+    a coarse proxy for the broader "adapts requests to responses" behaviour the guide describes.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.initial-access
+    - attack.t1190
+logsource:
+    category: webserver
+detection:
+    probe_markers:
+        cs-uri-query|contains:
+            - '../'
+            - "' or "
+            - ' union select '
+            - '<script'
+            - '; drop '
+    condition: probe_markers
+falsepositives:
+    - Legitimate request payloads that resemble probe markers; tune the marker list to your
+      application.
+level: low
+---
+title: Authentication Or Identity-Verification Attempt From One Source
+id: 2614cacb-7455-46ad-9af2-7b9633f12d7b
+status: experimental
+description: |
+    Stage 3 of the same-source multi-stage pattern: requests to login, authentication, or
+    identity-verification endpoints, or 401 and 403 responses. Map the paths and your own
+    authentication-event fields to your application; auxiliary, affiliate, and broker channels
+    often expose weaker identity-verification endpoints than the main service and belong here
+    too. This leg is broad by design and is only meaningful inside the correlation below.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.credential-access
+    - attack.t1110
+logsource:
+    category: webserver
+detection:
+    auth_path:
+        cs-uri-stem|contains:
+            - '/login'
+            - '/auth'
+            - '/verify'
+            - '/otp'
+    auth_deny:
+        sc-status:
+            - 401
+            - 403
+    condition: auth_path or auth_deny
+falsepositives:
+    - Ordinary users signing in; this leg is broad and only meaningful inside the correlation.
+level: low
+---
+title: Same-Source Multi-Stage Web Attack (Enumeration, Probe, Auth)
+id: 9b7c7b86-702f-42b8-be99-3e60a188ec5b
+status: experimental
+description: |
+    The behaviour-based core of ARTEX defense guide section 4.2 as a deployable template: one
+    client runs endpoint enumeration, parameter or path probing, and an authentication or
+    identity-verification attempt within the same short window. This is the pattern an autonomous
+    agent drives at machine speed and keeps driving past 403 and 429 responses. It is UA-free and
+    carries no ARTEX fingerprint, so it is a GENERIC behavioural rule, not one of the
+    ARTEX-source-grounded rules under detections/sigma/. Normalise the client field (c-ip, or a
+    session identifier if you have one) and tune the window to your baseline. If three legs are
+    too strict and miss cases, relax to any two of the three.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.initial-access
+    - attack.t1190
+correlation:
+    type: temporal
+    rules:
+        - f03c360c-dc33-4a8a-afa8-821b1ff5c4e3
+        - f9296e55-6b7a-4030-b5f7-5f7b146233be
+        - 2614cacb-7455-46ad-9af2-7b9633f12d7b
+    group-by:
+        - c-ip
+    timespan: 10m
+falsepositives:
+    - An authorised vulnerability scan or QA run from a single source; allow-list its address.
+level: high
+```
+
+Notes for using this template:
+
+- This block was validated with the same tooling the detection pack uses: `sigma check` with the full SigmaHQ convention set passes with 0 errors and 0 issues, and `sigma convert -t splunk` produces a query (the three sub-rules binned to a 10-minute window, grouped by `c-ip`, firing when all three are present). It is kept out of the tested `detections/` rule tree because it cannot be grounded in ARTEX source — that preserves the tree's promise to ship only what is "confirmed in this repository's source, not assumed."
+- Because this template is a correlation rule, whether `sigma convert` emits the whole template or only the three sub-rules depends on the backend's support for Sigma correlation conversion. Measured with the same pinned `sigma-cli` 3.1.0: the whole template converts on Splunk (`-t splunk`), Elasticsearch EQL (`-t eql`), and Grafana Loki (`-t loki`). On the Microsoft `kusto` backend (Sentinel and Defender) and Elasticsearch Lucene (`-t lucene`) the correlation does not convert (`Backend does not support correlation rules`), so convert the three sub-rules only and express the 10-minute, same-`c-ip` correlation natively in the product (for example, a Sentinel scheduled-analytics `summarize ... by bin(TimeGenerated, 10m), <client>`). This is the same portability the detection pack documents; the measured support matrix is in [Sigma backend portability](../detections/README.md#sigma-backend-portability).
+- Stage 2 (probing) rests on a list of injection/traversal markers and is a coarse, noisy signal on its own. That is why the three sub-rules are scored `low` and only the correlation — all three from one source — raises a high alert.
+- The client is grouped by `c-ip`. Behind a proxy or CDN, switch to the real client address recovered from `X-Forwarded-For`, or to a session identifier. If requiring all three stages is too strict and misses cases, relax it to any two of the three.
+
+### 4.3 Authentication logs
+
+- **Sudden shifts in the login failure rate** per account/IP, **slow distributed attempts** spread across a wide range of accounts (characteristic of stuffing), and an **abnormal failure-to-success transition speed**.
+- **Enumeration-style access** to identity-verification and one-time-code endpoints.
+
+### 4.4 Egress and forensics
+
+- Requests leaving an internal host for a code-repository host with the `artex-selfupdate` UA.
+- Processes bound internally to `:8787` (the management UI) or `127.0.0.1:8788` (the recording proxy).
+- A DNS/HTTP enrichment pattern that looks up a large number of external assets in a short time with the `artex-enrich/1.0` UA.
+
+---
+
+## 5. Hardening checklist
+
+Summarized so a defending team can check it right away.
+
+- [ ] Applied **adaptive rate limiting** (IP, account, device, behavior) to login, identity-verification, and sensitive APIs.
+- [ ] Enforces **MFA** on sensitive operations.
+- [ ] Has a **server-side ownership/authorization check** on every object access (blocks IDOR).
+- [ ] **Re-verifies authentication state transitions on the server** and does not blindly trust client trust markers.
+- [ ] Unified the identity-verification strength of **auxiliary/partner/recruitment channels** with the main service.
+- [ ] Operates **compromised-credential detection/matching** for leaked credentials.
+- [ ] Runs the WAF in **behavior-based mode** and does not rely on fixed signatures alone.
+- [ ] **Does not apply circulating unofficial IP block lists as-is**, and instead takes official indicators of compromise (IoCs) from a trusted source and applies them after reviewing their validity window and false-blocking risk.
+- [ ] Added a **same-source multi-stage correlation rule** to the SIEM.
+- [ ] **Retains authentication, access, and egress logs for a sufficient period** (autonomous attacks are fast, so after-the-fact tracing material matters).
+- [ ] Maintains an **inventory of internet-exposed assets, management consoles, and auxiliary systems to reduce the attack surface**, and **patches known (n-day) vulnerabilities fast** in perimeter devices, application servers, and middleware.
+- [ ] Reduced the blast radius of lateral movement and privilege escalation with network **segmentation**.
+- [ ] **Does not expose** secrets (keys, tokens) in responses, logs, or error messages.
+- [ ] Prepared **automatic blocking/isolation** response (waiting only on human approval cannot keep up with autonomous attack speed).
+
+---
+
+## 6. Incident response summary
+
+The defining trait of an autonomous AI attack is **speed**. An agent can run to completion, in a far shorter time, the intrusion and exfiltration that would take a person a year. Design your response on the premise of this speed.
+
+- **Automatic blocking first.** Set up measures such as isolating a suspect source, invalidating sessions, and sharply cutting the rate so they can **fire automatically** before human approval. Binding everything to a human-approval loop cannot keep up with the attack's speed.
+- **Decide in advance which logs to retain.** Authentication logs, access logs (including request bodies within the extent you can capture), egress logs, DNS queries. Autonomous attacks accumulate traces quickly, so this material is what you need to reconstruct the attack chain afterward.
+- **Track the scope of compromise asset by asset.** Because the attack spreads along the asset graph, you must reconstruct the **entire path** from the initial entry asset through lateral movement and privilege escalation to prevent re-intrusion.
+
+### 6.1 Triage procedure for a suspected host or traffic
+
+This lays out, in order, what to check first when ARTEX involvement is suspected. As Section 2 split the fingerprints into two perspectives, triage also splits into **(a) whether your service was targeted** and **(b) whether ARTEX ran on a given host**. At any step, do not conclude from a single hit alone; judge by whether several indicators and behavioral signals appear together. Even if the static indicators are all absent, keep investigating when a behavioral signal shows up.
+
+**(a) Target side — was your service targeted by ARTEX**
+
+1. Query your access/authentication logs for the enrichment User-Agent `artex-enrich/1.0`. Check whether single `GET` requests that do not follow redirects arrive across several assets at once in a short interval (Section 2 (a)). Since an operator can change the User-Agent, move to the next step even if nothing matches.
+2. Look for a **multi-stage chain** from the same source (or a few rotating sources): reconnaissance leading to endpoint enumeration, parameter probing, and authentication/injection attempts in short succession, adapting to response codes and lengths, and not stopping its evasive variations even after 401/403/429. This behavioral signal lasts longer than a static User-Agent (Section 2 (a) behavioral signatures).
+3. If you run a SIEM, catch this behavior with the [Sigma correlation rules](../detections/README.md) (enrichment velocity, fan-out, guard-block burst, and the guard marker co-occurring with a destructive command), and escalate any matched source to isolation and session invalidation per the "automatic blocking first" principle above.
+
+**(b) Host forensics — did ARTEX run on a given host**
+
+On a suspected host, check the following. The basis for each indicator is in Section 2 (b) and in the machine-readable [indicator list](../detections/indicators/artex_indicators.csv). The first four of the five read-only checks below (listening ports, egress logs, audit logs, state and recording stores) are run in one pass by the [host-triage script](../detections/triage/) (`detections/triage/artex_host_triage.py`). The fifth, the command audit, the script does not automate: destructive commands are a hunting lead that legitimate administrators also run, not an ARTEX fingerprint, so they are deliberately kept out of the automated indicators — check that one by hand against the host's command history. Run the script first when you have shell access but no SIEM, and treat each hit as a lead, as described below.
+
+1. **Listening ports.** Check on the host itself whether the default server port `:8787` and the loopback traffic-recording proxy `127.0.0.1:8788` are open.
+   ```sh
+   ss -ltnp | grep -E ':8787|:8788'   # use netstat -ltnp if ss is unavailable
+   ```
+   These two ports can be changed with the `--addr` and `--proxy` flags, so even if this query is empty, also review all open ports and whether an internal admin UI is up.
+2. **Egress logs.** Check whether requests went out to the code-repository host (GitHub releases) with the self-update User-Agent `artex-selfupdate` in your egress logs (`selfupdate/`). This suggests an ARTEX binary ran on the host.
+3. **Audit logs.** If the guard control marker `【ARTEX 平台管控·非目标防御】` appears in audit records, it supports an ARTEX-execution finding (`guard/guard.go`). It is written with this framing on every blocked tool call.
+4. **State and recording stores.** ARTEX keeps its exploration graph in PostgreSQL (the `exploration_nodes`, `assets`, `companies`, `activity` tables and the `agent_prompts` seed) and leaves its state and recordings in the data directory next to the executable (the `--data` default in `cmd/artex/main.go`). Directly under that directory are the per-task `tasks/` and conversation `transcripts/` subdirectories, while the recording proxy's artifacts sit one level deeper in a `traffic/` subdirectory (`server/manager.go` opens `traffic/` under the data directory as the recorder's store). So the trust CA certificate is at `traffic/_ca/mitmproxy-ca-cert.pem`, the traffic index at `traffic/_index/index.sqlite`, and the recorded request/response bodies at `traffic/_blobs/`. The case strengthens when these appear together with `tasks/` and `transcripts/`.
+5. **Command auditing.** Compare the destructive-command hunting indicators (the end of Section 2 (b): `rm -rf`, `DROP DATABASE`, `FLUSHALL`, exfiltration pipes, and the like) against the host's command history. A legitimate administrator uses the same commands, so treat them only as leads.
+
+Static indicators (ports, User-Agents, markers) can be changed or deleted by an operator. So **absence does not mean safety**, and the key to triaging an autonomous AI attack is to gather the behavioral signals from (a) and the host traces from (b) and judge them together.
+
+---
+
+## 7. Korean official channels: indicators, advisories, and reporting duties
+
+Defending teams in Korea should take their indicators of compromise and security advisories from official channels, and, when an incident occurs, meet the reporting duties the law sets. Make the official sources below your first reference instead of circulating unofficial lists.
+
+### 7.1 Where to get indicators and advisories
+
+- **KISA (Korea Internet & Security Agency), via [Boho Nara / KrCERT/CC](https://www.boho.or.kr)**, publishes security advisories, vulnerability notices, and incident-response information, and shares threat intelligence across organizations through C-TAS (the Cyber Threat Analysis and Sharing system; unlike the open portal, C-TAS is shared among enrolled organizations and takes a separate application).
+- **[FSI (Financial Security Institute)](https://www.fsec.or.kr)** shares intrusion and threat information across the financial sector (the finance-sector ISAC). If you are in finance, watch this channel as well.
+- **[PIPC (Personal Information Protection Commission)](https://www.pipc.go.kr)** publishes the criteria for breach notification and the guidance on protective measures.
+
+These channels are exactly what the section 5 hardening checklist means by "take official indicators of compromise from a trusted source." Even an official IoC is applied only after you review its validity window and false-blocking risk, the same principle explained in section 2, "Why IP-address blocking is a weak first line of defense."
+
+### 7.2 Reporting duties under Korean law
+
+Because autonomous attacks spread fast, build the statutory reporting steps into your section 6 incident-response procedure in advance. The following is a summary; confirm the exact scope, deadlines, and conditions against each authority's current rules.
+
+- **Personal-data breach:** under Article 34 of the Personal Information Protection Act, within 72 hours of becoming aware of the breach, report to the PIPC or KISA and notify the affected data subjects (the reporting conditions include a breach affecting 1,000 or more data subjects, a breach of sensitive or unique-identifier data, and a breach caused by unlawful external access).
+- **Security incident:** under the Network Act, an information and communications service provider reports the incident to the Ministry of Science and ICT and KISA (KrCERT/CC) within 24 hours of becoming aware of it.
+- **Financial companies:** under financial-sector supervisory rules you may additionally have to report to bodies such as the Financial Supervisory Service and FSI, so check those rules as well.
+
+To actually file: report a security incident through [Boho Nara](https://www.boho.or.kr) or by calling 118 with no area code (the KISA cyber help center), and a personal-data breach through the PIPC [personal-information portal](https://www.privacy.go.kr). The deadlines are short, so record the responsible owner and the contact path in your section 6 incident-response procedure in advance.
+
+---
+
+## References
+
+- Upstream project: [Autumn-27/ARTEX](https://github.com/Autumn-27/ARTEX) (AGPL-3.0). This document is the defensive material of its Korean-edition repository.
+- The top-level [README security and misuse warning, scope of use, and legal notice](../README.en.md).
+- This edition is localized for Korea; where personal data is involved, Korean law (the Network Act and the Personal Information Protection Act) applies. Unauthorized testing is a crime in most jurisdictions regardless — always secure written authorization and an agreed scope first.
+- Standard references for general web-security hardening: [OWASP Top 10](https://owasp.org/www-project-top-ten/), [OWASP ASVS (Application Security Verification Standard)](https://owasp.org/www-project-application-security-verification-standard/), [OWASP API Security Top 10](https://api-security.owasp.org/).
+
+> This guide is continually expanded to support defense and detection capability. Suggestions for additional detection rules or hardening items are welcome as repository issues.

docs/defense-ko.md

@@ -0,0 +1,388 @@
+# 자율 AI 공격 방어·탐지 가이드
+
+> 이 문서는 ARTEX 와 같은 **자율 AI 침투 에이전트**가 어떻게 동작하는지 방어하는 쪽에서 이해하고, 그 공격을 **탐지하고 차단하는 역량**을 기르기 위한 자료입니다. 공격 방법을 안내하는 문서가 아닙니다. 모든 내용은 자신이 소유하거나 서면으로 명시적 허가를 받은 시스템을 지키는 목적에만 사용하십시오. 권한 없이 타인의 정보통신망을 점검·공격하는 행위는 그 자체로 범죄입니다([상위 README 의 보안·오남용 경고](../README.md) 참조).
+>
+> English: **[Defense and Detection Guide (defense-en.md)](defense-en.md)**.
+
+자율 AI 공격 도구는 사람 한 명이 붙어 수동으로 돌리던 침투 테스트를, LLM 에이전트가 **스스로 목표를 쪼개고 실제 도구를 실행하며 발견을 축적하는** 24시간 자동 과정으로 바꿉니다. 방어자가 맞서는 상대가 "숙련된 공격자 한 명"에서 "지치지 않고 쉬지 않는 에이전트 군집"으로 바뀌는 셈입니다. 이 가이드는 그 변화가 탐지·대응에 무엇을 요구하는지를 정리합니다.
+
+---
+
+## 1. 자율 AI 공격은 기존 스캐너와 무엇이 다른가
+
+전통적인 취약점 스캐너(예: 고정 시그니처 기반 도구)는 미리 정해진 점검 항목을 순서대로 던지고 끝납니다. ARTEX 류의 자율 에이전트는 구조가 다릅니다. [시스템 아키텍처](../README.md#시스템-아키텍처)에서 설명하듯, 다음 요소가 결합해 **사람 개입 없이 여러 단계의 공격 체인을 완주**합니다.
+
+- **역할이 나뉜 멀티 에이전트.** 목표를 분해하는 `goals`, 다음 방향을 판정해 의도(intent)를 내보내는 `planner`, 의도 하나를 실제 도구로 실행하는 `worker` 여러 개, 사람이 끼어드는 `mainagent` 로 나뉩니다. planner 가 유일한 의도 생성자이고, worker 들이 그 의도를 병렬로 수행합니다.
+- **이중 그래프에 상태를 축적.** "무엇이 있는가"(자산 그래프)와 "어디까지 테스트했는가"(탐색 그래프)를 따로 쌓고 앵커로 연결합니다. 그래서 공격이 **점진적으로 깊어지고**, 같은 자산을 다른 각도에서 재방문하며, 앞선 관찰 위에 다음 단계를 세웁니다.
+- **이벤트 구동 폐곡선.** 그래프가 바뀔 때마다 planner 가 깨어나 다음 의도를 배정하고, worker 의 쓰기가 다시 다음 라운드를 촉발합니다. 목표가 증명될 때까지 이 순환이 멈추지 않습니다.
+- **직렬 공격 체인의 안정적 진행.** planner 는 "주입점 발견 → 인증 정보 획득 → 측면 이동 → 권한 상승" 같은 의존 순서를 공유 todolist 에 한 번만 기록하고, 선행 단계가 충족된 다음 단계에만 의도를 배정합니다. 그래서 무상태 세션 환경에서도 공격 체인이 어긋나지 않고 완주됩니다.
+- **LLM 이 맥락마다 페이로드를 변형.** 실행 도구와 페이로드가 코드에 고정된 상수가 아니라 LLM 이 상황을 읽고 생성하는 값이므로, 요청 하나하나의 형태가 조금씩 달라집니다.
+
+### 왜 탐지가 더 어려운가
+
+- **고정 시그니처가 잘 맞지 않습니다.** 페이로드가 맥락마다 바뀌므로, 알려진 악성 문자열을 정확히 일치시키는 방식의 룰(WAF 시그니처)이 비껴가기 쉽습니다.
+- **느리게, 그리고 사람처럼 끊어서 진행할 수 있습니다.** 에이전트는 라운드 사이에 쉬고, 발견에 따라 방향을 바꾸므로, 단순히 "짧은 시간에 많은 요청"만 보는 레이트 기반 탐지로는 놓칠 수 있습니다.
+- **정찰과 침투가 한 흐름으로 이어집니다.** 사람이 정찰 결과를 보고 며칠 뒤 수동으로 공격하던 간극이 사라져, 최초 접촉부터 자료 반출까지의 시간이 크게 짧아집니다.
+
+### 그래도 탐지할 수 있는 이유: 행동은 숨기기 어렵다
+
+정적 지문(User-Agent, 특정 페이로드 문자열)은 운영자가 마음먹으면 바꿀 수 있습니다. 그러나 **자율 에이전트의 행동 양상**은 공격의 본질이라 바꾸기 어렵습니다. 아래 2~4절은 이 행동 기반 관점에 무게를 둡니다.
+
+- 한 출처가 **여러 단계의 서로 다른 성격의 요청**(정찰 → 열거 → 인증 시도 → 익스플로잇)을 **일관된 세션으로 이어 가는** 패턴.
+- 사람이라면 피곤해서 멈출 시간대에도 **끊김 없이 이어지는** 탐색.
+- 실패한 응답에서 힌트를 얻어 **다음 요청을 체계적으로 변형**하는, 무작위가 아닌 적응적 진행.
+
+---
+
+## 2. 방어자가 관측할 수 있는 지문 (IoC·시그니처)
+
+지문을 두 관점으로 나눠 봅니다. **(가) 대상(피공격자) 관점**은 내 시스템을 향한 ARTEX 트래픽에서 볼 수 있는 것이고, **(나) 운영자·포렌식 관점**은 ARTEX 가 실제로 돌아간(또는 침해된 중계) 호스트에서 볼 수 있는 것입니다. 둘을 섞지 않는 것이 중요합니다. 대상 쪽에서 보이는 정적 지문은 제한적이고, 행동 지문이 핵심입니다.
+
+### (가) 대상 관점: 내 시스템을 향한 트래픽
+
+- **보강(enrich) 조회의 User-Agent `artex-enrich/1.0`.** ARTEX 는 자산을 자동으로 보강(DNS·HTTP 확인)할 때 이 User-Agent 로 대상에 직접 `GET` 을 보냅니다(`enrich/enrich.go`). 이 경로는 LLM 과 무관하게 ARTEX 가 스스로 생성하며, **리다이렉트를 따라가지 않고, keep-alive 를 끄며, 응답 앞부분만 읽어 `<title>` 을 뽑는** 특징이 있습니다. 기본 동시성은 4 입니다. 따라서 `artex-enrich/1.0` UA 로 **짧은 연결·단발 GET·제목만 읽고 끊는** 조회가 여러 자산에 동시에 들어오면 ARTEX 계열 보강 트래픽을 강하게 시사합니다. 다만 운영자가 UA 를 바꿀 수 있으므로 **부재가 안전을 뜻하지는 않습니다.**
+- **본 공격 트래픽은 도구 기본 지문을 따릅니다.** worker 는 실제 도구(Bash 로 실행하는 외부 도구·HTTP)로 요청을 보냅니다. ARTEX 는 이 트래픽을 자체 기록 프록시로 경유시키려고 서브프로세스 환경변수에 `HTTP_PROXY`·프록시 CA 경로를 주입할 뿐, **공격 트래픽에 ARTEX 고유 User-Agent 를 강제하지 않습니다.** 그래서 대상이 보는 User-Agent·헤더는 **그때 실행된 도구의 기본값**(각종 커맨드라인 도구의 기본 UA)입니다. 운영자가 커스텀하지 않았다면 흔한 자동화 도구 지문이 남고, 커스텀했다면 정상 브라우저처럼 위장될 수도 있습니다. 따라서 **단일 UA 매칭에 의존하지 말고 행동 기반 탐지와 결합**해야 합니다.
+- **worker 내장 WebFetch 도구는 `norma/0.4` User-Agent 를 남깁니다.** 위의 Bash 실행 외부 도구와 달리, ARTEX 가 norma SDK(`github.com/Autumn-27/norma`)로 직접 수행하는 HTTP 조회(WebFetch 도구)는 그 SDK 의 기본 User-Agent `norma/0.4` 를 공격 단계에 싣습니다. 평문 HTTP 로 오갈 때(또는 TLS 종단 지점에서) 네트워크 선에서 관측되며, [Suricata 규칙 sid 1000003](../detections/suricata/README.ko.md)이 이 접두사(`norma/`)를 잡습니다. 다만 이 UA 는 ARTEX 고유가 아니라 norma SDK 를 쓰는 다른 도구도 함께 쓰므로, `artex-enrich/1.0` 과 마찬가지로 단독 증거가 아니라 보조 단서이고, Bash 로 실행된 도구는 각자의 UA 를 쓰므로 **부재가 안전을 뜻하지 않습니다.**
+- **내장 레이트리밋이 없습니다.** ARTEX 자체에는 대상 트래픽 전용 속도 제한이 없고, 요청 속도는 LLM 이 돌리는 외부 도구가 결정합니다. 대신 태스크당 worker 는 기본 3개가 병렬로 돌아, 한 대상에 **여러 의도가 동시에** 진행될 수 있습니다. 즉 "느린 단일 세션"으로도, "여러 각도의 동시 진행"으로도 나타날 수 있어, 고정 임계값 하나로는 잡기 어렵습니다.
+- **행동 시그니처(가장 중요).** 아래 패턴의 **동시 출현**이 자율 에이전트를 가리킵니다.
+  - 한 출처(또는 소수의 회전 출처)에서 **정찰 → 디렉터리·엔드포인트 열거 → 파라미터 탐침 → 인증·주입 시도**가 **짧은 간격으로 연쇄**.
+  - 같은 엔드포인트로 보내되 **응답 코드·길이에 반응해 체계적으로 변형하는** 연속 요청(무작위 퍼징이 아니라 적응적).
+  - 사람 운영 시간대를 벗어나 **장시간 끊김 없이** 이어지는 세션.
+  - 실패(401/403/429) 이후에도 멈추지 않고 **우회 변형**을 시도하는 끈질김.
+
+### (나) 운영자·포렌식 관점: ARTEX 가 돌아간 호스트
+
+침해 조사에서 중계·경유 호스트에 ARTEX 가 설치·실행된 흔적을 찾을 때 참고합니다.
+
+- **기본 리스닝 포트 `:8787`.** ARTEX 서버의 기본 HTTP 수신 주소입니다(`cmd/artex/main.go`, `--addr` 로 변경 가능). 내부망 호스트가 이 포트에 관리 UI(대시보드·작업·자산 그래프)를 열고 있으면 ARTEX 인스턴스를 의심할 근거입니다.
+- **기록형 MITM 프록시 `127.0.0.1:8788`.** worker 의 Bash·HTTP 실행을 가로채 전 과정을 기록하는 로컬 프록시의 기본 주소입니다(`cmd/artex/main.go` 의 `--proxy` 기본값, 루프백 전용). 자체 CA 를 생성해 TLS 를 복호화·기록하므로(`mitmproxy-ca-cert.pem`), 호스트에 **ARTEX 가 설치한 신뢰 CA 인증서**가 있는지, 그리고 서브프로세스에 `HTTP_PROXY`·프록시 CA 경로 환경변수를 주입하는 흔적이 있는지가 단서가 됩니다. 이 주입은 ARTEX 가 생성하는 모든 worker 도구에 들어가고 변수 이름이 소스에 하드코딩이라(`agent/worker.go`), **실행 중인 프로세스가 프록시 변수와 mitmproxy CA 신뢰 변수를 함께 지니는지**는 포트 하나보다 특이적인 지문입니다. [호스트 분류 도구](../detections/triage/README.ko.md)가 `/proc`(또는 포렌식 이미지에서는 캡처한 환경변수 덤프)에서 이 조합을 확인합니다.
+- **self-update 콜백 `artex-selfupdate`.** 자가 업데이트가 GitHub 릴리스를 조회할 때 쓰는 User-Agent 입니다(`selfupdate/`). 송신(egress) 로그에서 이 UA 로 코드 저장소 호스트에 나가는 요청이 보이면 ARTEX 바이너리의 존재를 시사합니다.
+- **PostgreSQL 상의 이중 그래프.** `exploration_nodes`·`assets`·`companies`·`activity` 같은 테이블과 `agent_prompts` 시드가 있는 DB 는 ARTEX 데이터 저장소의 특징입니다.
+- **DB 기반 정규식 승인 규칙과 감사 로그.** 도구 호출을 평가하는 intercept 규칙이 DB 에 저장되고 우선순위대로 정규식으로 평가됩니다(`intercept/`). 차단된 호출은 감사 로그(`GET /api/audit`)에 `【ARTEX 平台管控·非目标防御】` 로 시작하는 통제 프레이밍과 함께 남으므로, 침해 호스트의 감사 기록에서 이 문자열이 보이면 ARTEX 실행을 뒷받침합니다.
+- **파괴적 명령 헌팅 지표.** ARTEX 자체 가드가 차단 대상으로 내장한 명령 패턴은 곧 자율 에이전트가 **시도할 수 있는** 명령군의 역상입니다. 호스트 명령 감사에서 아래를 헌팅 지표로 삼으십시오: `rm -rf`, `mkfs`, `dd of=/dev/`, `shred`/`wipe`, SQL `DROP DATABASE`/`DROP TABLE`/`TRUNCATE`, MongoDB `drop`/`dropDatabase`, Redis `FLUSHALL`/`FLUSHDB`, `curl`/`wget` 의 `-X DELETE`, 그리고 `curl … | nc …` 류의 데이터 반출 파이프. 다만 맨 끝의 데이터 반출 파이프는 데이터를 파괴하는 명령이 아니라 밖으로 빼내는 유출 신호라 성격이 다릅니다. 앞의 파괴 패턴과 달리 ARTEX 가드도 이 규칙만은 기본값으로 꺼 둔 채 내장하는데(정상적인 점검용 리버스셸이나 데이터 전송 파이프에 오탐이 잦기 때문입니다), 배포용 파괴 명령 헌팅 규칙([`destructive_command_hunting.yml`](../detections/sigma/destructive_command_hunting.yml))도 파괴 범위에만 한정돼 이 패턴을 포함하지 않으므로, 반출 파이프는 곧바로 차단하지 말고 별도 헌팅 지표로 두어 환경에 맞게 조정하십시오.
+
+> 정리: **대상 쪽 방어는 행동 지문에 걸고, 정적 UA(`artex-enrich/1.0`·`norma/0.4` 등)는 보조 단서로만** 씁니다. 운영자·포렌식 지문(`:8787`·`127.0.0.1:8788`·`artex-selfupdate`·DB 스키마·감사 로그 프레이밍)은 **침해된 경유 호스트를 조사할 때** 유효합니다.
+
+### IP 주소 차단은 왜 약한 1차 방어인가
+
+보안 사건이 알려지면 SNS·커뮤니티에 "공격 IP 목록을 공유하니 방화벽에서 차단하라"는 글이 흔히 돕니다. 공유하는 쪽의 선의와 달리, **출처가 불분명한 비공식 IP 목록을 그대로 차단 규칙에 넣는 것은 권하지 않습니다.** 자율 AI 공격에서는 특히 그렇습니다.
+
+- **출처를 검증하기 어렵습니다.** 개인이 올린 비공식 목록은 누가 어떤 근거로 수집했는지 확인할 방법이 없고, 사건과 무관한 IP 가 섞여 있어도 걸러 낼 수단이 없습니다.
+- **금방 낡습니다.** 자율 에이전트는 VPN·클라우드 인스턴스·탈취한 중계 서버를 거쳐 출발 IP 를 수시로 바꿉니다(위 (가) 절의 "소수의 회전 출처"). 어제 관측된 공격 IP 는 오늘 이미 버려졌을 가능성이 높아, 목록을 막아도 공격자는 다른 IP 로 되돌아옵니다.
+- **오차단 위험이 큽니다.** 목록에 공유 대역·CDN·정상 클라우드 IP 가 섞여 있으면, 그 IP 를 막는 순간 멀쩡한 고객 트래픽이나 내부 서비스까지 함께 끊깁니다. 자동 차단(아래 6절)과 결합하면 오차단 피해가 더 빠르게 번집니다.
+
+IP 차단 자체가 쓸모없다는 뜻은 아닙니다. **공식 침해지표(IoC)를 대응 기관이나 신뢰할 수 있는 위협 인텔리전스에서 받아, 유효 기간과 오차단 가능성을 검토한 뒤 적용할 때** 비로소 의미가 생깁니다. 그러나 IP 한 줄 차단은 회전하는 출발점을 뒤쫓는 임시 조치일 뿐이고, 오래가는 것은 바꾸기 어려운 **행동**(2~4절의 행동 기반 탐지)과 **공격 표면 축소**(3·5절의 하드닝: 노출 자산 정리·패치·MFA)입니다. "지문은 바꿀 수 있어도 행동은 숨기기 어렵다"는 이 가이드의 전제가 여기서도 그대로 적용됩니다.
+
+---
+
+## 3. 공격자가 노리는 진입점과 하드닝
+
+자율 에이전트는 사람 공격자와 **같은 약점**을 노리되 더 빠르고 집요하게 반복합니다. 아래는 방어 관점의 우선 하드닝 지점입니다.
+
+### 3.1 외부 노출 공격 표면과 알려진(n-day) 취약점
+
+자율 에이전트가 가장 먼저, 그리고 가장 안정적으로 노리는 진입점은 교묘한 0-day 가 아니라 **외부에 노출된 채 패치되지 않은, 이미 알려진 취약점**입니다. 경계 장비(VPN·방화벽), 외부에 열린 관리·운영 콘솔, 애플리케이션 서버·미들웨어·프레임워크(예: 널리 악용되는 WebLogic·Struts 계열), 그리고 **본 서비스가 아니라 제휴·모집·직원용으로 붙은 보조 시스템**이 대표적인 표적입니다. 자율 에이전트는 자산 그래프로 노출 표면을 자동으로 열거한 뒤, 공개 익스플로잇(PoC)이 도는 n-day 를 **패치가 적용되기 전에** 수백 개 자산을 대상으로 동시에 겨냥합니다. 노출된 약점을 찾아 대입하는 이 과정의 속도가 사람 공격자와 비대칭적으로 벌어지는 지점입니다.
+
+- **공격 표면을 줄입니다.** 인터넷에 노출된 자산·관리 콘솔·보조 시스템의 인벤토리를 지속적으로 유지하고, 꼭 외부에 둘 필요가 없는 것은 내부망·VPN·허용 목록 뒤로 옮깁니다.
+- **알려진 취약점을 신속히 패치합니다.** 경계 장비·웹서버·애플리케이션 서버·미들웨어의 공개된 취약점(n-day)은 자율 에이전트의 1순위 표적이므로, 공개 PoC 가 도는 구성요소부터 패치 적용 간격을 최대한 짧게 가져갑니다. 어느 것을 먼저 손볼지는 실제 악용이 관측된 취약점을 모아 두는 [CISA KEV(알려진 악용 취약점) 카탈로그](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)를 우선순위 입력으로 삼고, 7.1 의 국내 권고(KISA 보호나라)와 교차 확인하십시오. 특정 CVE 번호를 문서에 고정하기보다 이렇게 갱신되는 공식 목록을 기준으로 삼아야, 자율 에이전트가 새로 도는 n-day 로 표적을 옮겨도 뒤처지지 않습니다.
+- **노출이 불가피한 인터페이스를 조입니다.** 외부에 열어 둘 수밖에 없는 관리·운영 인터페이스에는 접근 출처 제한(IP 허용 목록)·MFA·VPN 을 더해, 인증 없는 열거 자체를 막습니다.
+- **보조 시스템을 본 서비스와 같은 기준으로 관리합니다.** 제휴·모집·직원용 보조 시스템도 본 서비스와 동일한 패치·모니터링 수준으로 관리합니다. 자율 에이전트가 파고드는 입구는 본 서비스가 아니라 이런 보조 경로인 경우가 많습니다. 인증 흐름 자체의 하드닝은 다음 3.2 로 이어집니다.
+
+탐지 관점에서는, 특정 취약점의 알려진 경로(URL·파라미터)를 겨냥한 요청이 외부에서 짧은 간격으로 연쇄하면 n-day 스캔의 신호입니다. 이 신호는 2절의 행동 지문, 4절의 동일 출처 다단계 상관 규칙과 결합할 때 가장 잘 드러납니다.
+
+### 3.2 보조 인증·본인확인 흐름
+
+부가 서비스·제휴·모집 채널처럼 **본 서비스와 다른 경로로 붙은 인증·본인확인 흐름**은 검증이 느슨한 경우가 많아 우회의 표적이 됩니다. 자율 에이전트는 이런 경로를 자동으로 열거하고, 응답 차이를 읽어 체계적으로 우회 조건을 찾습니다.
+
+- 본인확인·인증 단계를 **본 서비스와 동일한 강도**로 통일하고, 우회 가능한 보조 경로를 전수 점검합니다.
+- 인증 상태 전이(비로그인 → 로그인, 일반 → 권한)를 **서버에서 재검증**하고, 클라이언트가 보낸 신뢰 표식(쿠키·헤더·파라미터)을 그대로 믿지 않습니다.
+- 본인확인 토큰·일회성 코드의 **수명·재사용·추측 가능성**을 점검합니다.
+
+### 3.3 API 인증·인가 (IDOR·권한 상승)
+
+- 모든 객체 접근에 **서버측 소유권·권한 검사**를 강제합니다(식별자만 바꾸면 남의 자원이 열리는 IDOR 차단).
+- 수평·수직 권한 상승 경로를 열거해 봅니다. 자율 에이전트는 식별자를 기계적으로 증감시키며 대량으로 시도하므로, **단건 수동 테스트로는 놓친 구멍**을 금방 찾아냅니다.
+
+### 3.4 자격 증명 스터핑(credential stuffing)
+
+유출된 아이디·비밀번호 목록을 대입하는 공격은 자율 에이전트가 **속도와 분산**으로 증폭합니다.
+
+- 로그인·본인확인 엔드포인트에 **적응형 레이트리밋**(IP·계정·디바이스·행동 기반)을 겁니다.
+- **다단계 인증(MFA)** 을 민감 작업에 강제합니다. 스터핑으로 비밀번호가 맞아도 2차 인증이 막습니다.
+- **크리덴셜 침해 탐지**(알려진 유출 목록 대조, 비정상 로그인 위치·속도)로 선제 차단합니다.
+- 로그인 실패·성공의 **분포 변화**(갑작스러운 저속·광범위 시도)를 경보합니다.
+
+### 3.5 세션·토큰·비밀 관리
+
+- 세션 토큰의 **범위·수명·갱신**을 최소화하고, 민감 전이마다 재인증합니다.
+- API 키·내부 토큰을 응답·로그·오류 메시지에 **노출하지 않습니다**(자율 에이전트는 오류 응답에서 단서를 적극 수집).
+
+---
+
+## 4. 탐지 규칙·로그 패턴 (실무)
+
+특정 제품에 종속되지 않는 **의사 규칙** 형태로 적습니다. 자신의 WAF·IPS·SIEM 문법으로 옮겨 쓰십시오. 아래 규칙 가운데 정적 지문에 기반한 것은 바로 배포할 수 있는 [Sigma 규칙(`detections/sigma/`)](../detections/README.ko.md)으로 제공합니다. 핵심인 행동·상관 탐지(4.1·4.2)도 단일 규칙으로 환원되지는 않지만, 이 가운데 ARTEX 코드로 근거를 확인한 행동 지표는 배포 가능한 [Sigma 상관 규칙(`detections/sigma/correlation/`)](../detections/README.ko.md)으로 제공합니다(보강 조회 속도·보강 조회 대상 수·가드 차단 버스트·가드 마커와 파괴적 명령의 동일 호스트 동시 발생). 다만 그 순수 웹 다단계 상관(열거 → 탐침 → 인증)의 트래픽은 단일 ARTEX 고유 UA 로 환원되지 않으므로, 환경별 베이스 규칙이 필요합니다. 이 상관은 아래 4.2 에 바로 배포해 볼 수 있는 일반 행동 기반 Sigma 베이스 템플릿으로 실어 두었으니, 자신의 SIEM 과 기준선에 맞게 조정해 출발점으로 쓰십시오. 네트워크 계층에서 평문 HTTP 로 오갈 때(또는 TLS 종단 지점에서) 관측되는 ARTEX User-Agent 는 두 가지이고, 둘 다 [Suricata 규칙(`detections/suricata/`)](../detections/suricata/README.ko.md)으로 제공합니다. 하나는 enrich 프로브의 `artex-enrich/1.0`(존재 시그니처 sid 1000001·고속 열거 변형 sid 1000002)이고, 다른 하나는 norma SDK WebFetch 도구가 공격 단계에 보내는 `norma/0.4`(sid 1000003)입니다.
+
+### 4.1 WAF·IPS (행동 기반)
+
+- 단일 출처에서 **서로 다른 성격의 요청군**(정적 자원 요청 비중은 낮고, 열거·파라미터 탐침·인증 시도 비중이 높음)이 **한 세션으로** 이어지면 점수를 올립니다.
+- 응답 코드·본문 길이에 **반응해 변형되는 연속 요청**(엔트로피는 높되 무작위가 아닌 적응 패턴)을 가중합니다.
+- `artex-enrich/1.0` 같은 알려진 자동화 UA 는 **즉시 고위험**으로 태깅하되, UA 부재를 안전으로 해석하지 않습니다.
+
+### 4.2 SIEM 상관 규칙
+
+- **동일 출처 다단계 상관**: 같은 IP/ASN/세션에서 (a) 디렉터리·엔드포인트 열거, (b) 파라미터 탐침, (c) 인증/주입 시도가 **짧은 창 안에 모두** 관측되면 "자율 공격 의심" 경보.
+- **시간대 이상**: 서비스의 정상 트래픽 분포를 벗어나 **장시간 끊김 없이** 이어지는 단일 세션.
+- **실패 후 지속**: 403/429 를 받고도 멈추지 않고 **우회 변형**을 이어 가는 출처.
+
+위 **동일 출처 다단계 상관**을 바로 배포해 볼 수 있는 베이스 템플릿을 아래에 둡니다. 공격 트래픽에는 ARTEX 고유 User-Agent 가 없으므로, 이 템플릿은 `detections/sigma/` 의 ARTEX 소스 기반 규칙과 달리 **일반 행동 기반 규칙**입니다. 특정 공격 도구의 지문이 아니라 "한 출처가 짧은 창 안에서 열거·탐침·인증을 모두 수행한다"는 행동만 봅니다. 세 하위 규칙과, 한 클라이언트가 시간 창 안에서 셋을 모두 충족할 때만 발화하는 temporal 상관 규칙을 한 파일에 담았습니다.
+
+```yaml
+# ── 일반 행동 기반 템플릿 (ARTEX 고유 시그니처가 아님) ──
+# 방어 가이드 4.2절의 동일 출처 다단계 웹 패턴(열거 → 탐침 → 인증)입니다.
+# ARTEX 공격 트래픽에는 ARTEX 지문이 없으므로, detections/sigma/ 의 규칙과 달리
+# ARTEX 소스로 근거를 고정하지 않은 일반 행동 기반 출발점입니다. 필드 이름(SigmaHQ
+# 웹서버 분류)과 임계값·시간 창은 자신의 로그와 기준선에 맞게 반드시 조정하십시오.
+# 자족형: 세 하위 규칙 + 한 클라이언트가 창 안에서 셋을 모두 충족할 때만 발화하는
+# temporal 상관 규칙.
+title: Web Endpoint Enumeration Burst From One Source
+id: f03c360c-dc33-4a8a-afa8-821b1ff5c4e3
+status: experimental
+description: |
+    Stage 1 of the same-source multi-stage pattern in the ARTEX defense guide section 4.2: a
+    burst of endpoint or directory enumeration from a single client, seen as a high rate of 404
+    and 400 responses in a short window. This is generic behaviour, not an ARTEX-specific
+    signature; tune the count and window to your own baseline. On its own this leg is low signal
+    and earns weight only inside the correlation below.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.reconnaissance
+    - attack.t1595
+logsource:
+    category: webserver
+detection:
+    enum_misses:
+        sc-status:
+            - 404
+            - 400
+    condition: enum_misses
+falsepositives:
+    - Broken links, authorised vulnerability scanners, or misconfigured clients that generate
+      many 404 responses.
+level: low
+---
+title: Web Parameter Or Path Injection Probe From One Source
+id: f9296e55-6b7a-4030-b5f7-5f7b146233be
+status: experimental
+description: |
+    Stage 2 of the same-source multi-stage pattern: parameter or path probing, matched here as
+    query strings carrying common injection or traversal markers. This leg is unavoidably
+    signature-like and noisy on its own, so it is scored low and earns weight only inside the
+    correlation below. Extend the marker list to your own probe corpus and WAF categories; it is
+    a coarse proxy for the broader "adapts requests to responses" behaviour the guide describes.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.initial-access
+    - attack.t1190
+logsource:
+    category: webserver
+detection:
+    probe_markers:
+        cs-uri-query|contains:
+            - '../'
+            - "' or "
+            - ' union select '
+            - '<script'
+            - '; drop '
+    condition: probe_markers
+falsepositives:
+    - Legitimate request payloads that resemble probe markers; tune the marker list to your
+      application.
+level: low
+---
+title: Authentication Or Identity-Verification Attempt From One Source
+id: 2614cacb-7455-46ad-9af2-7b9633f12d7b
+status: experimental
+description: |
+    Stage 3 of the same-source multi-stage pattern: requests to login, authentication, or
+    identity-verification endpoints, or 401 and 403 responses. Map the paths and your own
+    authentication-event fields to your application; auxiliary, affiliate, and broker channels
+    often expose weaker identity-verification endpoints than the main service and belong here
+    too. This leg is broad by design and is only meaningful inside the correlation below.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.credential-access
+    - attack.t1110
+logsource:
+    category: webserver
+detection:
+    auth_path:
+        cs-uri-stem|contains:
+            - '/login'
+            - '/auth'
+            - '/verify'
+            - '/otp'
+    auth_deny:
+        sc-status:
+            - 401
+            - 403
+    condition: auth_path or auth_deny
+falsepositives:
+    - Ordinary users signing in; this leg is broad and only meaningful inside the correlation.
+level: low
+---
+title: Same-Source Multi-Stage Web Attack (Enumeration, Probe, Auth)
+id: 9b7c7b86-702f-42b8-be99-3e60a188ec5b
+status: experimental
+description: |
+    The behaviour-based core of ARTEX defense guide section 4.2 as a deployable template: one
+    client runs endpoint enumeration, parameter or path probing, and an authentication or
+    identity-verification attempt within the same short window. This is the pattern an autonomous
+    agent drives at machine speed and keeps driving past 403 and 429 responses. It is UA-free and
+    carries no ARTEX fingerprint, so it is a GENERIC behavioural rule, not one of the
+    ARTEX-source-grounded rules under detections/sigma/. Normalise the client field (c-ip, or a
+    session identifier if you have one) and tune the window to your baseline. If three legs are
+    too strict and miss cases, relax to any two of the three.
+references:
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-ko.md
+    - https://github.com/jiwoochris/artex-ko/blob/main/docs/defense-en.md
+author: artex-ko defense guide (generic template)
+date: 2026-10-07
+tags:
+    - attack.initial-access
+    - attack.t1190
+correlation:
+    type: temporal
+    rules:
+        - f03c360c-dc33-4a8a-afa8-821b1ff5c4e3
+        - f9296e55-6b7a-4030-b5f7-5f7b146233be
+        - 2614cacb-7455-46ad-9af2-7b9633f12d7b
+    group-by:
+        - c-ip
+    timespan: 10m
+falsepositives:
+    - An authorised vulnerability scan or QA run from a single source; allow-list its address.
+level: high
+```
+
+이 템플릿을 쓸 때 유의할 점입니다.
+
+- 이 블록은 탐지 팩이 쓰는 것과 같은 도구로 검증했습니다. `sigma check` 를 SigmaHQ 규약 전수로 돌려 오류·이슈 0 으로 통과하고, `sigma convert -t splunk` 로 질의가 생성됩니다(세 하위 규칙을 10분 창에서 `c-ip` 로 묶어 셋을 모두 충족하면 발화). 다만 ARTEX 소스로 근거를 고정할 수 없어 `detections/` 의 테스트되는 규칙 트리에는 넣지 않았습니다. 그 트리의 "추정이 아니라 소스에서 확인한 것만 싣는다"는 원칙을 지키기 위함입니다.
+- 이 템플릿은 상관(correlation) 규칙이라, `sigma convert` 가 템플릿 전체를 내보내는지 아니면 세 하위 규칙만 내보내는지는 백엔드가 Sigma 상관 변환을 지원하는지에 달려 있습니다. 같은 고정 버전(`sigma-cli` 3.1.0)으로 실측하면, 템플릿 전체는 Splunk(`-t splunk`)·Elasticsearch EQL(`-t eql`)·Grafana Loki(`-t loki`)에서 변환됩니다. 반면 Microsoft `kusto` 백엔드(Sentinel·Defender)와 Elasticsearch Lucene(`-t lucene`)에서는 상관 규칙이 변환되지 않으므로(`Backend does not support correlation rules`), 이때는 세 하위 규칙만 변환하고 "10분 창·동일 `c-ip`" 상관은 제품에서 직접 표현하십시오(예: Sentinel 예약 분석 규칙의 `summarize ... by bin(TimeGenerated, 10m), <클라이언트>`). 이는 탐지 팩이 문서화한 이식성과 같으며, 실측 지원 표는 [Sigma 백엔드 이식성](../detections/README.ko.md#sigma-백엔드-이식성)에 정리돼 있습니다.
+- 2단계(탐침)는 주입·순회 마커 목록에 기대는 거친 신호라 단독으로는 오탐이 많습니다. 그래서 세 하위 규칙의 `level` 은 낮게 두고, 셋이 한 출처에서 함께 나타나는 상관 규칙에서만 높은 경보가 되게 했습니다.
+- 클라이언트는 `c-ip` 로 묶었습니다. 프록시·CDN 뒤라면 `X-Forwarded-For` 로 복원한 실제 클라이언트 주소나 세션 식별자로 바꾸십시오. 세 단계를 모두 요구하는 것이 너무 엄격해 놓치는 사례가 있으면, 셋 중 둘만 충족해도 발화하도록 완화하십시오.
+
+### 4.3 인증 로그
+
+- 계정·IP 당 **로그인 실패율의 급변**, 광범위 계정에 걸친 **저속 분산 시도**(스터핑 특유), 실패에서 성공으로의 **비정상 전이 속도**.
+- 본인확인·일회성 코드 엔드포인트에 대한 **열거성 접근**.
+
+### 4.4 송신(egress)·포렌식
+
+- 내부 호스트에서 `artex-selfupdate` UA 로 코드 저장소 호스트에 나가는 요청.
+- 내부에서 `:8787`(관리 UI)·`127.0.0.1:8788`(기록 프록시)로 바인딩된 프로세스.
+- `artex-enrich/1.0` UA 로 짧은 시간에 대량의 외부 자산을 조회하는 DNS·HTTP 보강 패턴.
+
+---
+
+## 5. 하드닝 체크리스트
+
+방어 조직이 바로 점검할 수 있도록 요약합니다.
+
+- [ ] 로그인·본인확인·민감 API 에 **적응형 레이트리밋**을 적용했다(IP·계정·디바이스·행동).
+- [ ] 민감 작업에 **MFA** 를 강제한다.
+- [ ] 모든 객체 접근에 **서버측 소유권·권한 검사**가 있다(IDOR 차단).
+- [ ] 인증 상태 전이를 **서버에서 재검증**하고 클라이언트 신뢰 표식을 그대로 믿지 않는다.
+- [ ] **보조·제휴·모집 채널**의 본인확인 강도를 본 서비스와 통일했다.
+- [ ] 유출 자격 증명 **침해 탐지·대조**를 운영한다.
+- [ ] WAF 를 **행동 기반 모드**로 운용하고, 고정 시그니처에만 의존하지 않는다.
+- [ ] **떠도는 비공식 IP 차단 목록을 그대로 적용하지 않고**, 공식 침해지표(IoC)를 신뢰할 수 있는 출처에서 받아 유효 기간·오차단 위험을 검토한 뒤 반영한다.
+- [ ] SIEM 에 **동일 출처 다단계 상관 규칙**을 넣었다.
+- [ ] 인증·접근·송신 **로그를 충분한 기간 보존**한다(자율 공격은 빠르므로 사후 추적 자료가 중요).
+- [ ] 인터넷에 노출된 자산·관리 콘솔·보조 시스템의 **인벤토리를 유지해 공격 표면을 축소**하고, 경계 장비·애플리케이션 서버·미들웨어의 **알려진(n-day) 취약점을 신속히 패치**한다.
+- [ ] 네트워크 **세그멘테이션**으로 측면 이동·권한 상승의 폭발 반경을 줄였다.
+- [ ] 비밀(키·토큰)을 **응답·로그·오류 메시지에 노출하지 않는다**.
+- [ ] **자동 차단·격리** 대응을 준비했다(사람 승인만 기다리면 자율 공격 속도를 못 따라간다).
+
+---
+
+## 6. 사고 대응 요약
+
+자율 AI 공격의 특징은 **속도**입니다. 한 사람이 1년에 걸쳐 할 침투·반출을 에이전트는 훨씬 짧은 시간에 완주할 수 있습니다. 대응 설계도 이 속도를 전제로 합니다.
+
+- **자동 차단을 선제로.** 의심 출처 격리·세션 무효화·레이트 급감 같은 조치를 사람 승인 전에 **자동 발동**할 수 있게 둡니다. 전부 사람 승인 루프에 묶으면 공격 속도를 못 따라갑니다.
+- **보존할 로그를 미리 정합니다.** 인증 로그, 접근 로그(요청 본문 포함 가능 범위), 송신 로그, DNS 질의. 자율 공격은 흔적을 빠르게 쌓으므로, 사후에 공격 체인을 복원하려면 이 자료가 필요합니다.
+- **침해 범위를 자산 단위로 추적합니다.** 공격이 자산 그래프를 따라 번지므로, 최초 진입 자산에서 측면 이동·권한 상승으로 이어진 **경로 전체**를 복원해야 재침투를 막습니다.
+
+### 6.1 의심 호스트·트래픽 분류(triage) 절차
+
+ARTEX 연루가 의심될 때 가장 먼저 확인할 것을 순서로 정리합니다. 2절에서 지문을 두 관점으로 나눈 것과 같이, 분류도 **(가) 내 서비스가 표적이 됐는지**와 **(나) 특정 호스트에서 ARTEX 가 돌았는지**로 나눠 봅니다. 어느 단계든 적중 하나만으로 단정하지 말고, 여러 지표와 행동 신호가 함께 나타나는지로 판단합니다. 정적 지표가 전부 없더라도 행동 신호가 보이면 조사를 이어 갑니다.
+
+**(가) 대상 측: 내 서비스가 ARTEX 표적이 됐는지**
+
+1. 접근·인증 로그에서 보강 조회 User-Agent `artex-enrich/1.0` 을 조회합니다. 리다이렉트를 따라가지 않는 단발 `GET` 조회가 짧은 간격으로 여러 자산에 동시에 들어왔는지 확인합니다(2절 (가)). 운영자가 User-Agent 를 바꿀 수 있으므로, 걸리지 않아도 다음 단계로 넘어갑니다.
+2. 동일 출처(또는 소수의 회전 출처)에서 나오는 **다단계 연쇄**를 찾습니다. 정찰에서 엔드포인트 열거, 파라미터 탐침, 인증·주입 시도로 짧은 간격에 이어지고, 응답 코드·길이에 적응하며, 401·403·429 이후에도 우회 변형을 멈추지 않는 양상입니다. 이 행동 신호가 정적 User-Agent 보다 오래 남습니다(2절 (가) 행동 시그니처).
+3. SIEM 을 운용한다면 이 행동을 [Sigma 상관 규칙](../detections/README.ko.md)(보강 조회 속도·대상 수·가드 차단 버스트·가드 마커와 파괴 명령의 동시 발생)으로 걸어 두고, 걸린 출처를 위 "자동 차단을 선제로" 원칙에 따라 격리·세션 무효화 대상으로 올립니다.
+
+**(나) 호스트 포렌식: 특정 호스트에서 ARTEX 가 돌았는지**
+
+의심 호스트에서 다음을 확인합니다. 지표의 근거는 2절 (나)와 기계가 읽는 [침해지표 목록](../detections/indicators/artex_indicators.csv)에 있습니다. 아래 다섯 가지 읽기 전용 점검 가운데 앞의 네 가지(리스닝 포트·송신 로그·감사 로그·상태·기록 저장소)는 [호스트 분류 스크립트](../detections/triage/)(`detections/triage/artex_host_triage.py`)가 한 번에 대신 돌려 줍니다. 다섯 번째 명령 감사는 파괴적 명령이 ARTEX 고유 지문이 아니라 정당한 관리자도 쓰는 헌팅 단서여서 자동 지표로 싣지 않으므로, 스크립트가 대신 돌리지 않고 호스트 명령 이력에서 직접 대조합니다. SIEM 없이 셸 접근만 있을 때 먼저 돌려 보고, 각 적중은 아래 설명대로 단서로만 다룹니다.
+
+1. **리스닝 포트.** 기본 서버 포트 `:8787` 과 루프백 기록 프록시 `127.0.0.1:8788` 이 열려 있는지 호스트에서 직접 확인합니다.
+   ```sh
+   ss -ltnp | grep -E ':8787|:8788'   # ss 가 없으면 netstat -ltnp 를 씁니다
+   ```
+   두 포트는 `--addr`·`--proxy` 플래그로 바뀔 수 있으므로, 이 조회가 비어도 열린 포트 전체와 내부 관리 UI 가 떠 있는지를 함께 봅니다.
+2. **송신 로그.** 자가 업데이트 User-Agent `artex-selfupdate` 로 코드 저장소 호스트(GitHub 릴리스)에 나간 요청이 송신 로그에 있는지 확인합니다(`selfupdate/`). 이 호스트에서 ARTEX 바이너리가 돌았음을 시사합니다.
+3. **감사 로그.** 가드 통제 마커 `【ARTEX 平台管控·非目标防御】` 가 감사 기록에 있으면 ARTEX 실행을 뒷받침합니다(`guard/guard.go`). 차단된 도구 호출마다 이 프레이밍으로 남습니다.
+4. **상태·기록 저장소.** ARTEX 는 PostgreSQL 에 탐색 그래프를 두고(`exploration_nodes`·`assets`·`companies`·`activity` 테이블과 `agent_prompts` 시드), 실행 파일 옆 데이터 디렉터리(`cmd/artex/main.go` 의 `--data` 기본값)에 상태와 기록을 남깁니다. 이 디렉터리 바로 아래에는 작업별 산출물을 담는 `tasks/` 와 대화 기록을 담는 `transcripts/` 하위 디렉터리가 있고, 기록 프록시의 산출물은 그 안의 `traffic/` 하위 디렉터리에 따로 모입니다(`server/manager.go` 가 데이터 디렉터리 아래 `traffic/` 를 기록 프록시 저장소로 엽니다). 그래서 신뢰 CA 인증서는 `traffic/_ca/mitmproxy-ca-cert.pem`, 트래픽 색인은 `traffic/_index/index.sqlite`, 기록한 요청·응답 본문은 `traffic/_blobs/` 에 있습니다. 이 셋이 `tasks/`·`transcripts/` 와 함께 보이면 기록 프록시가 실제로 돌았다는 정황이 강해집니다.
+5. **명령 감사.** 파괴적 명령 헌팅 지표(2절 (나) 끝의 `rm -rf`·`DROP DATABASE`·`FLUSHALL`·반출 파이프 등)를 호스트 명령 이력과 대조합니다. 정당한 관리자도 같은 명령을 쓰므로 단서로만 다룹니다.
+
+정적 지표(포트·User-Agent·마커)는 운영자가 바꾸거나 지울 수 있습니다. 따라서 **부재가 안전을 뜻하지 않으며**, (가)의 행동 신호와 (나)의 호스트 흔적을 함께 모아 판단하는 것이 자율 AI 공격 분류의 핵심입니다.
+
+---
+
+## 7. 국내 공식 채널: 침해지표·보안 권고와 신고 의무
+
+국내 방어 조직은 침해지표와 보안 권고를 공식 채널에서 받고, 사고가 나면 법에서 정한 신고 의무를 지켜야 합니다. 떠도는 비공식 목록 대신 아래 공식 출처를 1차 기준으로 삼으십시오.
+
+### 7.1 침해지표·보안 권고를 받는 곳
+
+- **KISA(한국인터넷진흥원)의 [보호나라·KrCERT/CC](https://www.boho.or.kr)** 는 보안 권고와 취약점 공지, 침해사고 대응 정보를 제공합니다. 사이버위협정보 분석·공유체계(C-TAS)로 기관 사이에 위협정보를 공유합니다(C-TAS 는 가입 기관 간 공유 체계라 공개 포털과 달리 별도 신청 절차를 거칩니다).
+- **[금융보안원(FSI)](https://www.fsec.or.kr)** 은 금융 분야의 침해·위협 정보를 업권을 가로질러 공유합니다(금융 분야 ISAC). 금융권이라면 이 채널을 함께 봅니다.
+- **[개인정보보호위원회](https://www.pipc.go.kr)** 는 개인정보 유출 신고 기준과 보호 조치에 관한 고시·가이드를 공개합니다.
+
+5절 하드닝 체크리스트의 "공식 침해지표를 신뢰할 수 있는 출처에서 받는다"가 가리키는 출처가 바로 이 채널들입니다. 공식 침해지표라도 유효 기간과 오차단 위험을 먼저 검토한 뒤 반영하는 원칙은 2절의 "IP 주소 차단은 왜 약한 1차 방어인가"에서 설명한 것과 같습니다.
+
+### 7.2 국내법상 신고 의무
+
+자율 공격은 빠르게 번지므로, 6절 사고 대응 절차 안에 법정 신고 단계를 미리 넣어 두십시오. 아래는 요지이며, 정확한 적용 대상과 기한, 요건은 각 기관의 최신 고시로 확인해야 합니다.
+
+- **개인정보 유출**: 「개인정보 보호법」 제34조에 따라, 유출을 인지한 때부터 72시간 이내에 개인정보보호위원회 또는 KISA 에 신고하고 정보주체에게 통지합니다(정보주체 1천 명 이상, 민감정보나 고유식별정보의 유출, 외부의 불법적 접근에 의한 유출 등이 신고 요건에 해당합니다).
+- **침해사고**: 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」에 따라, 정보통신서비스 제공자는 침해사고를 인지한 뒤 24시간 이내에 과학기술정보통신부와 KISA(KrCERT/CC)에 신고합니다.
+- **금융회사**: 금융 분야 감독 규정에 따라 금융감독원이나 금융보안원 같은 소관 기관에 별도로 보고해야 할 수 있으므로, 해당 규정을 함께 확인하십시오.
+
+실제 신고는 침해사고의 경우 [보호나라](https://www.boho.or.kr)나 국번 없이 118(KISA 사이버민원센터)로, 개인정보 유출의 경우 개인정보보호위원회 [개인정보 포털](https://www.privacy.go.kr)로 접수합니다. 신고 기한이 짧으므로 담당자와 연락 경로를 6절 사고 대응 절차에 미리 적어 두십시오.
+
+---
+
+## 참고
+
+- 원본 프로젝트: [Autumn-27/ARTEX](https://github.com/Autumn-27/ARTEX) (AGPL-3.0). 이 문서는 그 한국어판 저장소의 방어 자료입니다.
+- 상위 [README 의 보안·오남용 경고와 사용 범위·국내법 고지](../README.md).
+- 이 판본은 한국 사용자를 위한 현지화본이며, 개인정보가 결부된 경우에는 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」과 「개인정보 보호법」이 함께 적용됩니다. 그와 무관하게 권한 없는 점검은 대부분의 관할에서 범죄가 되므로, 반드시 서면 허가와 합의된 범위를 먼저 확보한 뒤에 진행하십시오.
+- 일반 웹 보안 하드닝의 표준 참고: [OWASP Top 10](https://owasp.org/www-project-top-ten/), [OWASP ASVS(애플리케이션 보안 검증 표준)](https://owasp.org/www-project-application-security-verification-standard/), [OWASP API Security Top 10](https://api-security.owasp.org/).
+
+> 이 가이드는 방어·탐지 역량을 돕기 위해 계속 보강됩니다. 보완할 탐지 규칙·하드닝 항목 제안은 저장소 이슈로 환영합니다.

docs/finding-traffic-evidence-en.md

@@ -0,0 +1,106 @@
+# Vulnerability multi-traffic evidence
+
+> This document is an English translation of the upstream (original) ARTEX design doc. It records,
+> for contributors and maintainers, the design of the feature that links vulnerabilities to traffic
+> evidence. The original (Chinese) is preserved in
+> [`finding-traffic-evidence-zh.md`](finding-traffic-evidence-zh.md).
+>
+> 한국어판: **[취약점 다중 트래픽 증거 (finding-traffic-evidence-ko.md)](finding-traffic-evidence-ko.md)**.
+
+The **Linked traffic** panel on the vulnerability detail screen supports multi-select across pages, entering a role and a description, ordering, and unbinding. The traffic page likewise lets you select several records at once and link them to a single existing vulnerability. Vulnerability evidence that a task inherits is read-only; to change it you must enter the source task.
+
+**Agent automatic traffic binding** in system settings is off by default, and its read/write interface is `agent_traffic_binding` under `/api/settings`. Turning it on increases the Token consumption that comes from inspecting requests/responses, from tool calls, and from the prompt, and the new setting takes effect from the next round's Agent onward. While it is off, the automatic-binding parameters and the supplementary binding tool are hidden, the automatic-binding guidance is not injected, and automatic bindings newly submitted by an already-running session are rejected. Manual binding, traffic capture, and reading or exporting saved evidence are unaffected.
+
+Once the feature is on, the default flow is: save the finding → automatically trigger the report Agent → cross-check and bind traffic → write the report against the latest evidence version. In `evidence`, the reporter leaves the verification commands, the key output, and the real traffic IDs and their roles that are already in hand. The report Agent combines the vulnerability detail with the execution record, confirms with `traffic_search` / `traffic_get`, then calls `bind_finding_traffic`, reads the latest `version`, and saves the report. When the switch is off, the report Agent does not additionally receive the raw traffic search/read tools and does not bind automatically; it can still read manually bound snapshots and generate a report.
+
+It stays compatible with existing callers. You can still bind explicitly and immediately via `report_finding`'s `traffic_refs` / `evidence_hint_id`. Binding is optional. For a non-HTTP vulnerability such as TCP, when nothing has been collected yet, or when you cannot find the exact record, you may omit the references and still report and write the report normally. We recommend leaving other verifiable evidence — command output, logs, and so on — and explaining why you did not bind; no new required input field is added. Every ID you submit must be valid and its body intact. If even one fails, the entire binding operation for this call is rolled back. If an explicit bind-while-reporting fails, the whole report is rolled back. Appending the same snapshot again does not add a binding and does not overwrite the description.
+
+## Agent ID scheme and report version
+
+New optional parameters were added to `report_finding`, and the array order is the initial evidence order:
+
+```json
+{
+  "traffic_refs": [
+    {"traffic_id": "real traffic ID", "role": "baseline", "note": "normal account request"},
+    {"traffic_id": "another real traffic ID", "role": "proof", "note": "reproduction request"}
+  ]
+}
+```
+
+The roles are `baseline` (normal control), `proof` (vulnerability proof), `verification` (supplementary verification), and `supporting` (supporting evidence, the default). First cross-check against real records with `traffic_search` / `traffic_get`. Use the domain and the timestamp only to narrow down candidates, and do not assume task attribution.
+
+The prompt draws on [CyberStrikeAI's vulnerability-reporting tool guidance](https://github.com/RuoJi6/CyberStrikeAI/blob/54d56774b8bd285817d16d48b70a4a5e6e0963f7/internal/app/vulnerability_tools.go), combined with this project's optional-binding convention, but without adding a rule that makes a reason-for-not-binding mandatory. You must not guess IDs, and you should not probe repeatedly just to fill in evidence.
+
+The first line of the return value is still `finding recorded: <exploration node ID>`. The JSON that follows provides the standalone vulnerability record's `finding_id`, the exploration node's `finding_node_id`, and a binding summary.
+
+- `get_finding_traffic(finding_id)` uses the **standalone vulnerability record ID** and returns an ordered list together with `version`. Passing `binding_id`, `side=request|response`, `offset`, and `length` lets you read in segments, with each segment capped at 8192 bytes.
+- `update_finding_report`'s `finding_id` **continues to use the exploration node ID.** Fill the newly added `evidence_version` with the version you actually read. If the evidence changes while the report is being generated, a write from the old version is rejected, so you must read again and regenerate.
+- When an old report call does not pass a version, it is not treated as having overwritten existing traffic evidence. When a binding, description, role, or ordering changes, the existing report is flagged as needing an update.
+
+With automatic binding on, `add_hint` / `add_task_hint` can store `traffic_refs` on a single hint or on each element of a batch `hints`. When the planner reports on someone's behalf, it can pass `evidence_hint_id` to unambiguously select the references within the hint for this task, and it cannot reference inherited hints. The system does not guess a binding from the domain, the timestamp, or the browsing history. A failed submission does not create a partially formed vulnerability or trigger the report early.
+
+When an existing vulnerability is missing a binding, you can supplement it with `bind_finding_traffic(finding_id, traffic_refs)` without registering it again. `list_findings` / `list_task_findings` / `node_detail` / `get_task_node_detail` return explicit `finding_id` and `finding_node_id`, and the old `id` keeps its exploration-node meaning.
+
+At startup, only optional properties are added to the old tool schema; the original default traffic-tool binding is extended to the report Agent as well, and the supplementary binding tool is, by default, left to the report Agent. Custom binding lists, prompts, descriptions, and the enabled state are preserved as-is. Guidance is added all at once after the final tool assembly is done. The reporting role is responsible for handing over evidence already in hand, and the report Agent is responsible for cross-checking, binding, and writing the report. When a platform conversation has no task context, it must hand off to the task Agent as a structured hint and must not report directly. Before judging a task complete, it must first hand over the evidence already in hand, and it is not forced to wait when there is no traffic to bind. A failed `report_finding` does not trigger the report Agent.
+
+## API
+
+The base path is `/api/exploration/findings/{finding_id}/traffic`, and it uses the standalone vulnerability ID. Authentication follows the existing scheme, and `context_task` verifies task visibility and whether inherited reads are read-only.
+
+The request and return for each method and relative path are as follows:
+
+- `GET`: returns the ordered summary, the evidence version, and the version the report adopted.
+- `POST`: adds `{"traffic_refs":[...]}` in a single batch.
+- `PATCH /{binding_id}`: edits with `{"version":1,"role":"proof","note":"description"}`.
+- `DELETE /{binding_id}`: deletes with `{"version":1}`.
+- `PUT /order`: reorders with `{"version":1,"binding_ids":["2","1"]}`, and the list must be complete.
+- `GET /{binding_id}`: returns the snapshot metadata and a length-limited body preview.
+- `GET /{binding_id}/body`: takes `side`, `offset`, and `length`, and with `download=1` it downloads the complete raw bytes.
+
+A version/ordering set conflict or a write while archiving is in progress returns `409`, a write against an inherited item returns `403`, and a binding that does not exist or does not belong to the vulnerability returns `404`. When reading and verifying traffic or attachments fails, a clear error is returned.
+
+## Storage and migration
+
+At startup an idempotent migration is run against PostgreSQL. It newly adds the `traffic_evidence_snapshots` and `finding_traffic_bindings` tables and the `findings.evidence_version` / `report_evidence_version` columns (default `0`). It does not guess supplementary bindings from past text.
+
+A snapshot stores the original traffic ID, the capture time, the URL, the method, the status, the request/response headers, the body length, and the SHA-256. The body is stored by hash at `<data>/evidence/blobs/<first two characters>/<hash>.bin`, kept separate from the cleanup-subject `data/traffic`, so that several vulnerabilities can share a snapshot/body. A snapshot offers no interface for updating its content, and if verification does not match, reading and exporting fail.
+
+Under the original traffic write lock, the full body is read, including large body blobs and old directory records. The file is persisted and verified first, then a single PostgreSQL transaction records the exploration node, the intent relationship, the vulnerability, the snapshot, and the binding, and only after the commit is the planner notified. On failure, unreferenced files may remain, but no partially recorded business record is created.
+
+The PostgreSQL advisory lock `7337741004` coordinates evidence files and SQL references. A task row lock forbids evidence modification after it has been queued for archiving. Restore holds the evidence lock across the whole process, from body installation to metadata commit. Deleting a vulnerability cascades to remove its bindings as well.
+
+The cleaner runs every hour and only reclaims the content of tasks that are unreferenced and not in progress, with a minimum delay of 24 hours. Ordinary traffic cleanup does not touch the evidence directory. When backing up hot data, back up PostgreSQL and `data/evidence` together.
+
+## Export and archiving
+
+Markdown includes the ordered evidence list and the version, JSON adds the metadata, and CSV adds the count and the binding IDs. `md-zip` keeps the vulnerability Markdown while also providing the following structure:
+
+```text
+evidence/<finding_id>/<binding_id>/
+  manifest.json
+  request.http
+  response.http
+  request.bin
+  response.bin
+```
+
+Markdown references the packets with relative links. Before sending the download, it finishes copying the attachments, verifying the hashes, compressing, syncing to disk, and verifying the CRC read of every ZIP entry. If an entry is missing or corrupted, the entire download fails. A complete attachment preserves the raw binary bytes exactly.
+
+Archive v3 collects snapshots and bodies according to the vulnerability-binding relationships, without depending on the original traffic or the domain. It cleans hot data only after the package verification is done, and it keeps shared evidence. Restore first verifies the installed body, then restores the metadata and bindings in a transaction, and supports retries on failure. v1/v2 can still be restored, and missing new fields are explicitly filled with `0`.
+
+## Verification and boundaries
+
+Each test package has its own freshly created PostgreSQL test database, specified via `ARTEX_PG_DSN`, so that leftover task/model fixtures do not trigger background execution. Run the full test suite of the relevant packages and confirm that no test was skipped because of missing configuration:
+
+```sh
+# Set ARTEX_PG_DSN to the relevant isolated test database before running each package. If the explicit setting fails, it must raise an error.
+go test ./<package> -count=1
+go test -race -p 1 ./evidence ./db ./agent ./server -run 'TestEvidence|TestFindingTraffic|TestFindingEvidence|TestReportFindingAtomicContract|TestTaskArchive'
+```
+
+Frontend verification includes `npx tsc --noEmit`, a Biome check of the affected files, a Webpack build, and a `NEXT_EXPORT=1` static export. Use a separate cache directory so that a running dev server is not overwritten.
+
+Local end-to-end acceptance verification uses a separate port, a controlled HTTP / domain-HTTPS target, and a temporary data directory, and it covers the two binding entry points, selection across pages, ordering/description, error guidance, inherited read-only, and download. It also covers export after the original traffic has been deleted, archiving, hot-body reclamation, and restore with hash verification.
+
+The first version uses a global evidence-coordination lock. While a bulk binding/export or a slow attachment download is in progress, other evidence operations may wait. Without a recording or a complete body, evidence cannot be fabricated. This feature does not change the capture switch, nor does it address the certificate problem when accessing an IP directly over HTTPS.

docs/finding-traffic-evidence-ko.md

@@ -0,0 +1,105 @@
+# 취약점 다중 트래픽 증거
+
+> 이 문서는 상류(원본) ARTEX 의 설계 문서를 한국어로 옮긴 것입니다. 취약점과 트래픽 증거를 연결하는
+> 기능의 설계를 기여자·메인테이너를 위해 정리합니다. 원문(중국어)은
+> [`finding-traffic-evidence-zh.md`](finding-traffic-evidence-zh.md) 에 보존돼 있습니다.
+>
+> English: **[Vulnerability multi-traffic evidence (finding-traffic-evidence-en.md)](finding-traffic-evidence-en.md)**.
+
+취약점 상세 화면의 「연결된 트래픽」은 여러 페이지에 걸친 다중 선택, 용도와 설명 입력, 정렬, 바인딩 해제를 지원합니다. 트래픽 페이지에서도 여러 레코드를 한 번에 선택해 이미 있는 취약점 하나에 연결할 수 있습니다. 작업이 상속한 취약점 증거는 읽기 전용이며, 수정하려면 원본 작업으로 들어가야 합니다.
+
+시스템 설정의 「Agent 자동 트래픽 바인딩」은 기본값이 꺼짐이며, 읽기·수정 인터페이스는 `/api/settings` 의 `agent_traffic_binding` 입니다. 이 기능을 켜면 요청/응답 조회, 도구 호출, 프롬프트에서 비롯되는 Token 소비가 늘어나고, 다음 회차의 Agent 부터 새 설정을 사용합니다. 꺼져 있을 때는 자동 바인딩 파라미터와 보완 바인딩 도구를 숨기고, 자동 바인딩 안내를 주입하지 않으며, 이미 실행 중인 세션이 새로 제출하는 자동 바인딩을 거부합니다. 수동 바인딩, 트래픽 캡처, 저장된 증거의 읽기와 내보내기는 영향을 받지 않습니다.
+
+기능을 켠 뒤의 기본 흐름은 「발견 사항 저장 → 보고서 Agent 자동 트리거 → 트래픽 대조·바인딩 → 최신 증거 버전으로 보고서 작성」 입니다. 보고자는 `evidence` 에 검증 명령, 핵심 출력, 이미 확보한 실제 트래픽 ID 와 용도를 남깁니다. 보고서 Agent 는 취약점 상세와 실행 기록을 종합해 `traffic_search` / `traffic_get` 으로 확인한 뒤 `bind_finding_traffic` 을 호출하고, 최신 `version` 을 읽어 보고서를 저장합니다. 스위치를 끄면 보고서 Agent 는 원본 트래픽 검색/읽기 도구를 추가로 받지 않고 자동 바인딩도 하지 않으며, 그래도 수동으로 바인딩한 스냅샷을 읽어 보고서를 생성할 수 있습니다.
+
+기존 호출자와도 호환됩니다. `report_finding` 의 `traffic_refs` / `evidence_hint_id` 로 여전히 명시적으로 즉시 바인딩할 수 있습니다. 바인딩은 선택 사항입니다. TCP 같은 비 HTTP 취약점이거나, 아직 수집하지 않았거나, 정확한 레코드를 찾지 못한 경우에는 참조를 생략해도 정상적으로 보고하고 보고서를 작성할 수 있습니다. 명령 출력, 로그 등 검증 가능한 다른 증거는 남기고, 바인딩하지 않은 이유를 함께 설명하기를 권장하며, 필수 입력 필드는 새로 추가하지 않습니다. 제출한 ID 는 모두 유효해야 하고 본문이 온전해야 합니다. 그중 하나라도 실패하면 이번 바인딩 작업 전체를 롤백합니다. 보고와 함께 명시적으로 바인딩하다가 실패하면 보고 전체를 롤백합니다. 같은 스냅샷을 중복해서 덧붙여도 바인딩이 늘어나지 않고 설명도 덮어쓰지 않습니다.
+
+## Agent ID 체계와 보고서 버전
+
+`report_finding` 에 선택 파라미터를 새로 추가했으며, 배열 순서가 곧 초기 증거 순서입니다:
+
+```json
+{
+  "traffic_refs": [
+    {"traffic_id": "실제 트래픽 ID", "role": "baseline", "note": "정상 계정 요청"},
+    {"traffic_id": "다른 실제 트래픽 ID", "role": "proof", "note": "재현 요청"}
+  ]
+}
+```
+
+용도는 `baseline`(정상 대조), `proof`(취약점 증명), `verification`(보완 검증), `supporting`(보조 증거, 기본값) 입니다. 먼저 `traffic_search` / `traffic_get` 으로 실제 레코드를 대조합니다. 도메인과 시각은 후보를 추리는 용도로만 쓰고, 작업 귀속을 단정하지 않습니다.
+
+프롬프트는 [CyberStrikeAI 의 취약점 보고 도구 안내](https://github.com/RuoJi6/CyberStrikeAI/blob/54d56774b8bd285817d16d48b70a4a5e6e0963f7/internal/app/vulnerability_tools.go) 를 참고했고, 이 프로젝트의 선택적 바인딩 규약과 결합하되 바인딩하지 않은 이유를 필수로 검증하는 규칙은 두지 않습니다. ID 를 추측해서는 안 되며, 단지 증거를 채우려고 반복해서 탐지해서도 안 됩니다.
+
+반환값의 첫 줄은 여전히 `finding recorded: <탐색 노드 ID>` 입니다. 이어지는 JSON 은 독립 취약점 레코드의 `finding_id`, 탐색 노드의 `finding_node_id`, 바인딩 요약을 제공합니다.
+
+- `get_finding_traffic(finding_id)` 는 **독립 취약점 레코드 ID** 를 사용하며, 순서가 있는 목록과 `version` 을 반환합니다. `binding_id`, `side=request|response`, `offset`, `length` 를 넘기면 구간별로 나눠 읽을 수 있고, 한 구간은 최대 8192 바이트입니다.
+- `update_finding_report` 의 `finding_id` 는 **계속 탐색 노드 ID 를 사용합니다.** 새로 추가한 `evidence_version` 에는 실제로 읽은 버전을 채웁니다. 보고서를 생성하는 동안 증거가 바뀌면 옛 버전의 쓰기를 거부하므로, 다시 읽어서 생성해야 합니다.
+- 옛 보고서 호출이 버전을 넘기지 않으면, 이미 있는 트래픽 증거를 덮어썼다고 표시하지 않습니다. 바인딩, 설명, 용도, 정렬이 바뀌면 기존 보고서에 업데이트가 필요하다는 표시가 붙습니다.
+
+자동 바인딩을 켜면 `add_hint` / `add_task_hint` 가 단일 힌트나 일괄 `hints` 의 각 요소에 `traffic_refs` 를 저장하도록 지원합니다. 플래너가 대신 보고할 때는 `evidence_hint_id` 를 넘겨, 이 작업에 해당하는 힌트 안의 참조를 명확히 선택할 수 있고, 상속받은 힌트는 참조할 수 없습니다. 시스템은 도메인, 시각, 조회 기록으로 바인딩을 추측하지 않습니다. 제출이 실패하면 일부만 생성된 취약점을 만들거나 보고서를 앞당겨 트리거하지 않습니다.
+
+이미 있는 취약점에 바인딩이 빠졌을 때는 `bind_finding_traffic(finding_id, traffic_refs)` 로 보완 바인딩할 수 있고, 다시 등록할 필요가 없습니다. `list_findings` / `list_task_findings` / `node_detail` / `get_task_node_detail` 는 명확한 `finding_id` 와 `finding_node_id` 를 반환하며, 옛 `id` 는 탐색 노드 의미를 유지합니다.
+
+기동 시에는 옛 도구 schema 에 선택 속성만 추가하고, 원래의 기본 트래픽 도구 바인딩을 보고서 Agent 까지 확장하며, 보완 바인딩 도구는 기본적으로 보고서 Agent 에 맡깁니다. 사용자 지정 바인딩 목록, 프롬프트, 설명, 활성화 상태는 그대로 유지합니다. 안내는 최종 도구 조립이 끝난 뒤 한꺼번에 추가합니다. 보고 역할은 이미 확보한 증거를 넘겨주는 일을 맡고, 보고서 Agent 는 대조·바인딩·보고서 작성을 맡습니다. 플랫폼 대화에 작업 맥락이 없을 때는 구조화된 힌트로 작업 Agent 에 넘겨야 하고, 직접 보고하지 않습니다. 작업 완료를 판정하기 전에 먼저 이미 있는 증거를 넘겨야 하며, 바인딩할 트래픽이 없으면 기다리도록 강제하지 않습니다. 실패한 `report_finding` 은 보고서 Agent 를 트리거하지 않습니다.
+
+## API
+
+기본 경로는 `/api/exploration/findings/{finding_id}/traffic` 이며, 독립 취약점 ID 를 사용합니다. 인증은 기존 방식을 그대로 따르고, `context_task` 가 작업 가시성과 상속 읽기 전용 여부를 검증합니다.
+
+메서드와 상대 경로별 요청·반환은 다음과 같습니다:
+
+- `GET`: 순서가 있는 요약, 증거 버전, 보고서가 채택한 버전을 반환합니다.
+- `POST`: `{"traffic_refs":[...]}` 를 한 번에 일괄 추가합니다.
+- `PATCH /{binding_id}`: `{"version":1,"role":"proof","note":"설명"}` 로 수정합니다.
+- `DELETE /{binding_id}`: `{"version":1}` 로 삭제합니다.
+- `PUT /order`: `{"version":1,"binding_ids":["2","1"]}` 로 정렬하며, 완전한 목록이어야 합니다.
+- `GET /{binding_id}`: 스냅샷 메타데이터와 길이가 제한된 본문 미리 보기를 반환합니다.
+- `GET /{binding_id}/body`: `side`, `offset`, `length` 를 받고, `download=1` 이면 완전한 원본 바이트를 내려받습니다.
+
+버전/정렬 집합 충돌이나 보관 진행 중 쓰기는 `409` 를 반환하고, 상속 항목에 대한 쓰기는 `403` 을, 존재하지 않거나 해당 취약점에 속하지 않는 바인딩은 `404` 를 반환합니다. 트래픽/첨부 읽기와 검증이 실패하면 명확하게 오류를 반환합니다.
+
+## 저장과 마이그레이션
+
+기동 시 PostgreSQL 에 멱등 마이그레이션을 수행합니다. `traffic_evidence_snapshots`, `finding_traffic_bindings` 테이블과 `findings.evidence_version` / `report_evidence_version`(기본값 0) 컬럼을 새로 추가합니다. 과거 텍스트를 근거로 보완 바인딩을 추측하지 않습니다.
+
+스냅샷은 원본 트래픽 ID, 수집 시각, URL, 메서드, 상태, 요청/응답 헤더, 본문 길이, SHA-256 을 저장합니다. 본문은 해시에 따라 `<data>/evidence/blobs/<앞 두 자리>/<hash>.bin` 에 보관하며, 정리 대상인 `data/traffic` 와 분리돼 있어 여러 취약점이 스냅샷/본문을 공유할 수 있습니다. 스냅샷은 내용 갱신 인터페이스를 제공하지 않으며, 검증이 일치하지 않으면 읽기와 내보내기가 실패합니다.
+
+원본 트래픽 쓰기 잠금 아래에서 큰 본문 blob 과 옛 디렉터리 레코드를 포함해 본문 전체를 읽습니다. 먼저 파일을 영속화하고 검증한 뒤, 하나의 PostgreSQL 트랜잭션으로 탐색 노드, 의도 관계, 취약점, 스냅샷, 바인딩을 기록하고, 커밋한 뒤에야 플래너에게 통지합니다. 실패하면 참조되지 않는 파일이 남을 수는 있으나, 일부만 기록된 업무 레코드는 만들지 않습니다.
+
+PostgreSQL advisory lock `7337741004` 이 증거 파일과 SQL 참조를 조율합니다. 작업 행 잠금은 보관 대기열에 올린 뒤의 증거 수정을 금지합니다. 복원은 본문 설치부터 메타데이터 커밋까지 전 과정에서 증거 잠금을 유지합니다. 취약점을 삭제하면 바인딩도 연쇄로 제거됩니다.
+
+정리기는 매시간 실행되며, 참조가 없고 진행 중이지 않은 작업의 내용만 회수하되 최소 24시간을 지연합니다. 일반 트래픽 정리는 증거 디렉터리를 건드리지 않습니다. 핫 데이터를 백업할 때는 PostgreSQL 과 `data/evidence` 를 함께 백업합니다.
+
+## 내보내기와 보관
+
+Markdown 에는 순서가 있는 증거 목록과 버전이 들어가고, JSON 에는 메타데이터가, CSV 에는 개수와 바인딩 ID 가 추가됩니다. `md-zip` 은 취약점 Markdown 을 유지하면서 다음 구조를 함께 제공합니다:
+
+```text
+evidence/<finding_id>/<binding_id>/
+  manifest.json
+  request.http
+  response.http
+  request.bin
+  response.bin
+```
+
+Markdown 은 상대 링크로 패킷을 참조합니다. 다운로드를 보내기 전에 첨부 복사, 해시 검증, 압축, 디스크 동기화, 그리고 모든 ZIP 항목의 CRC 읽기 검증을 마칩니다. 항목이 누락되거나 손상되면 다운로드 전체가 실패합니다. 완전한 첨부는 이진 원본 바이트를 그대로 보존합니다.
+
+보관 v3 는 취약점 바인딩 관계에 따라 스냅샷과 본문을 수집하며, 원본 트래픽이나 도메인에 의존하지 않습니다. 패키지 검증을 마친 뒤에야 핫 데이터를 정리하고, 공유 증거는 계속 보존합니다. 복원은 먼저 설치한 본문을 검증한 뒤 트랜잭션으로 메타데이터와 바인딩을 복원하며, 실패하면 재시도를 지원합니다. v1/v2 도 계속 복원할 수 있고, 빠진 새 필드는 명시적으로 0 으로 채웁니다.
+
+## 검증과 경계
+
+테스트 패키지마다 독립적으로 새로 만든 PostgreSQL 테스트 데이터베이스를 두고 `ARTEX_PG_DSN` 으로 지정해, 남아 있는 작업/모델 픽스처가 백그라운드 실행을 트리거하지 않게 합니다. 관련 패키지의 전체 테스트를 실행하고, 설정 누락 때문에 건너뛴 테스트가 없는지 확인합니다:
+
+```sh
+# 각 패키지를 실행하기 전에 ARTEX_PG_DSN 을 해당 독립 테스트 데이터베이스로 설정합니다. 명시적 설정이 실패하면 반드시 오류를 내야 합니다.
+go test ./<package> -count=1
+go test -race -p 1 ./evidence ./db ./agent ./server -run 'TestEvidence|TestFindingTraffic|TestFindingEvidence|TestReportFindingAtomicContract|TestTaskArchive'
+```
+
+프런트엔드 검증에는 `npx tsc --noEmit`, 영향받은 파일의 Biome 검사, Webpack 빌드, `NEXT_EXPORT=1` 정적 내보내기가 포함됩니다. 독립 캐시 디렉터리를 사용해 실행 중인 개발 서버를 덮어쓰지 않도록 합니다.
+
+로컬 엔드투엔드 인수 검증은 독립 포트, 통제된 HTTP / 도메인 HTTPS 대상, 임시 데이터 디렉터리를 사용하며, 두 가지 바인딩 진입점, 여러 페이지에 걸친 선택, 정렬/설명, 오류 안내, 상속 읽기 전용, 다운로드를 다룹니다. 또한 원본 트래픽을 삭제한 뒤의 내보내기, 보관, 핫 본문 회수, 복원과 해시 검증까지 포함합니다.
+
+첫 버전은 전역 증거 조율 잠금을 사용합니다. 대량 바인딩/내보내기나 느린 첨부 다운로드가 진행되는 동안 다른 증거 작업은 대기할 수 있습니다. 녹화 레코드나 완전한 본문이 없으면 증거를 지어낼 수 없습니다. 이 기능은 캡처 스위치를 바꾸지 않으며, HTTPS 로 IP 에 직접 접근할 때의 인증서 문제도 다루지 않습니다.

docs/finding-traffic-evidence-zh.md

@@ -0,0 +1,99 @@
+# 漏洞多流量证据
+
+漏洞详情的「关联流量」支持跨页多选、用途和说明、排序及解除绑定。流量页也可多选记录，一次关联到一个已有漏洞。任务继承的漏洞证据只读，修改需进入来源任务。
+
+系统设置中的「Agent 自动绑定流量」默认关闭，读取和修改接口为 `/api/settings` 的 `agent_traffic_binding`。开启会增加查阅请求/响应、工具调用及提示词带来的 Token 消耗；下一轮 Agent 使用新设置。关闭时隐藏自动绑定参数和补绑工具，不注入自动绑定指引，并拒绝已运行会话新提交的自动绑定。人工绑定、流量捕获、已保存证据读取和导出不受影响。
+
+开启后，默认流程是「发现入库 → 自动触发报告 Agent → 核对并绑定流量 → 按最新证据版本写报告」。上报者在 `evidence` 保留验证命令、关键输出、已有真实流量 ID 及用途；报告 Agent 结合漏洞详情和执行记录，用 `traffic_search` / `traffic_get` 核实后调用 `bind_finding_traffic`，再读取最新 `version` 保存报告。关闭开关时，报告 Agent 不额外获得原始流量检索/读取工具，也不自动绑定；仍能读取人工绑定的快照并生成报告。
+
+兼容已有调用者：`report_finding` 的 `traffic_refs` / `evidence_hint_id` 仍可显式即时绑定。绑定可选：TCP 等非 HTTP 漏洞、未采集或找不到确切记录时，省略引用仍可正常上报和撰写报告；保留命令输出、日志等其他可验证证据，建议说明未绑定原因，不新增必填字段。提交的 ID 必须全部有效且正文完整。任何一条失败都会回滚本次绑定操作；显式随上报绑定失败时整次上报回滚。重复追加同一快照不增加绑定，也不覆盖说明。
+
+## Agent 编号与报告版本
+
+`report_finding` 新增可选参数，数组顺序即初始证据顺序：
+
+```json
+{
+  "traffic_refs": [
+    {"traffic_id": "真实流量ID", "role": "baseline", "note": "正常账户请求"},
+    {"traffic_id": "另一个真实流量ID", "role": "proof", "note": "复现请求"}
+  ]
+}
+```
+
+用途为 `baseline`（正常对照）、`proof`（漏洞证明）、`verification`（补充验证）、`supporting`（辅助证据，默认）。先用 `traffic_search` / `traffic_get` 核对真实记录；域名和时间仅用于候选筛选，不推定任务归属。
+
+提示词参考 [CyberStrikeAI 的漏洞上报工具指引](https://github.com/RuoJi6/CyberStrikeAI/blob/54d56774b8bd285817d16d48b70a4a5e6e0963f7/internal/app/vulnerability_tools.go)，结合本项目的可选绑定约定，不引入无包原因必填校验。不得猜测 ID，也不应仅为补包重复探测。
+
+返回第一行仍为 `finding recorded: <探索节点 ID>`；随后 JSON 提供独立漏洞记录 `finding_id`、探索节点 `finding_node_id` 和绑定摘要。
+
+- `get_finding_traffic(finding_id)` 使用**独立漏洞记录 ID**，返回有序清单及 `version`；传 `binding_id`、`side=request|response`、`offset`、`length` 可分段读取，每段最多 8192 字节。
+- `update_finding_report` 的 `finding_id` **继续使用探索节点 ID**。新增 `evidence_version` 填实际读取的版本；生成期间证据变化会拒绝旧版本写入，必须重新读取并生成。
+- 旧报告调用未传版本时，不宣称覆盖已有流量证据。绑定、说明、用途或排序变化后，已有报告提示待更新。
+
+开启自动绑定后，`add_hint` / `add_task_hint` 支持在单条提示或批量 `hints` 的每个元素中保存 `traffic_refs`。Planner 代为上报可传 `evidence_hint_id`，明确选取本任务对应提示中的引用，不能引用继承提示。系统不会按域名、时间或浏览记录猜测绑定。提交失败不生成部分漏洞或提前触发报告。
+
+已有漏洞漏绑时可用 `bind_finding_traffic(finding_id, traffic_refs)` 补绑，无需重复登记。`list_findings` / `list_task_findings` / `node_detail` / `get_task_node_detail` 返回明确的 `finding_id` 和 `finding_node_id`；旧 `id` 保持探索节点语义。
+
+启动时仅为旧工具 schema 增加可选属性，原始默认流量工具绑定扩展至报告 Agent；补绑工具默认交给报告 Agent。自定义绑定列表、提示词、描述及启用状态保留。指引在最终工具装配后统一加入：上报角色负责交接已有证据，报告 Agent 负责核对、绑定和写报告。平台对话缺少任务上下文时应通过结构化提示交接给任务 Agent，不直接上报。判定任务完成前应先交接已有证据；无包不强制等待。失败的 `report_finding` 不触发报告 Agent。
+
+## API
+
+基础路径：`/api/exploration/findings/{finding_id}/traffic`，使用独立漏洞 ID。沿用认证；`context_task` 校验任务可见性及继承只读。
+
+| 方法 / 相对路径 | 请求 / 返回 |
+| --- | --- |
+| `GET` | 有序摘要、证据版本、报告采用版本 |
+| `POST` | `{"traffic_refs":[...]}` 整批追加 |
+| `PATCH /{binding_id}` | `{"version":1,"role":"proof","note":"说明"}` |
+| `DELETE /{binding_id}` | `{"version":1}` |
+| `PUT /order` | `{"version":1,"binding_ids":["2","1"]}`，必须是完整列表 |
+| `GET /{binding_id}` | 快照元数据和有界正文预览 |
+| `GET /{binding_id}/body` | `side`、`offset`、`length`；`download=1` 下载完整原字节 |
+
+版本/排序集合冲突、归档中写入返回 `409`；继承写入 `403`；不存在或不属于漏洞的绑定 `404`；流量/附件读取及校验失败明确返回错误。
+
+## 存储与迁移
+
+启动幂等迁移 PostgreSQL：新增 `traffic_evidence_snapshots`、`finding_traffic_bindings`，以及 `findings.evidence_version` / `report_evidence_version`（默认 0）。不根据历史文字猜测补绑。
+
+快照保存原流量 ID、采集时间、URL、方法、状态、请求/响应头、正文长度和 SHA-256。正文按哈希存放在 `<data>/evidence/blobs/<前两位>/<hash>.bin`，与可清理的 `data/traffic` 独立，多个漏洞可共享快照/正文。快照不提供内容更新接口，校验不一致时读取和导出失败。
+
+在原流量写锁下读取完整正文，包括大正文 blob 和旧目录记录。先持久化并校验文件，再用单个 PostgreSQL 事务写入探索节点、意图关系、漏洞、快照和绑定；提交后才通知规划者。失败可能遗留无引用文件，但不产生部分业务记录。
+
+PostgreSQL advisory lock `7337741004` 协调证据文件和 SQL 引用；任务行锁禁止归档排队后的证据修改。恢复从正文安装到元数据提交全程保持证据锁。删除漏洞级联移除绑定。
+
+清理器每小时运行，只回收无引用且非进行中操作的内容，至少延迟 24 小时。普通流量清理不触及证据目录。备份热数据时同时备份 PostgreSQL 和 `data/evidence`。
+
+## 导出与归档
+
+Markdown 包含有序证据清单及版本；JSON 包含元数据；CSV 增加数量和绑定 ID。`md-zip` 保留漏洞 Markdown，并提供：
+
+```text
+evidence/<finding_id>/<binding_id>/
+  manifest.json
+  request.http
+  response.http
+  request.bin
+  response.bin
+```
+
+Markdown 通过相对链接引用报文。发送下载前完成附件复制、哈希校验、压缩、磁盘同步及全部 ZIP 条目的 CRC 读取校验；缺失/损坏使整个下载失败。完整附件保留二进制原字节。
+
+归档 v3 按漏洞绑定关系收集快照和正文，不依赖原流量或域名。包校验完成后才清理热数据；共享证据继续保留。恢复先校验安装正文，再事务恢复元数据和绑定，支持失败重试。v1/v2 继续可恢复，缺失的新字段显式补为 0。
+
+## 验证与边界
+
+为每个测试包设置独立、新建的 PostgreSQL 测试库，通过 `ARTEX_PG_DSN` 指定，避免残留任务/模型夹具触发后台运行。运行相关包完整测试，并确认没有配置缺失导致的跳过：
+
+```sh
+# 每个包运行前将 ARTEX_PG_DSN 设为对应的独立测试库；显式配置失败必须报错。
+go test ./<package> -count=1
+go test -race -p 1 ./evidence ./db ./agent ./server -run 'TestEvidence|TestFindingTraffic|TestFindingEvidence|TestReportFindingAtomicContract|TestTaskArchive'
+```
+
+前端验证包含 `npx tsc --noEmit`、受影响文件的 Biome 检查、Webpack 构建和 `NEXT_EXPORT=1` 静态导出。使用独立缓存目录，避免覆盖运行中的开发服务。
+
+本机端到端验收使用独立端口、受控 HTTP / 域名 HTTPS 目标和临时数据目录，覆盖两个绑定入口、跨页选择、排序/说明、错误提示、继承只读、下载，以及删除原流量后导出、归档、回收热正文、恢复并校验哈希。
+
+首版采用全局证据协调锁；大批量绑定/导出或慢速附件下载期间，其他证据操作可能等待。缺少录制记录或完整正文时不能补造证据。本功能不改变捕获开关，也不处理 HTTPS 直接访问 IP 的证书问题。