First Commit

detections/sigma/correlation/artex_enrich_fanout.yml

@@ -0,0 +1,37 @@
+# references base rule: ../artex_enrich_user_agent.yml (ARTEX Asset Enrichment Probe User-Agent)
+title: ARTEX Enrichment Fan-Out (One Source, Many Distinct Hosts)
+id: 6fba3b7c-1dd9-4e18-bf55-d93fc1d2e2e0
+status: experimental
+description: |
+    Correlates a single client carrying the ARTEX enrichment User-Agent to many DISTINCT
+    destination hosts within a short window (distinct count of cs-host). Autonomous enrichment
+    fans out across an asset list at machine speed, so breadth — the number of different hosts
+    touched, not just request volume — is what separates it from a person browsing a few pages.
+    Evaluate this where your telemetry spans multiple hosts (CDN, WAF, reverse proxy, or shared
+    hosting) or at an egress point that sees outbound enrichment. As with the base rule, the
+    User-Agent can be changed; the durable signal is the fan-out behaviour, so pair this with the
+    defense guide section 4 and tune the distinct-host threshold and window to your environment.
+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
+    - https://github.com/jiwoochris/artex-ko
+author: artex-ko defense guide
+date: 2026-10-05
+tags:
+    - attack.reconnaissance
+    - attack.t1595
+    - attack.t1592
+correlation:
+    type: value_count
+    rules:
+        - 34adfa15-1696-4322-afc0-f69988e9cc1e
+    group-by:
+        - c-ip
+    timespan: 10m
+    condition:
+        gte: 20
+        field: cs-host
+falsepositives:
+    - Shared egress (NAT/proxy) where many users appear as one source; a legitimate scanner or
+      uptime monitor that fronts many hosts. Allow-list known sources and raise the threshold.
+level: high

detections/sigma/correlation/artex_enrich_scan_velocity.yml

@@ -0,0 +1,35 @@
+# references base rule: ../artex_enrich_user_agent.yml (ARTEX Asset Enrichment Probe User-Agent)
+title: ARTEX Enrichment Scan Velocity (Burst From One Source)
+id: 1d07c5f1-e0ff-4a6a-8017-6008fa790889
+status: experimental
+description: |
+    Correlates a burst of ARTEX asset-enrichment probes from a single client within a short
+    window. The base rule matches the "artex-enrich/1.0" User-Agent; this correlation adds the
+    behaviour the single-request rule misses — velocity. ARTEX enriches assets with a default
+    concurrency of 4 and ships no built-in rate limit (enrich/enrich.go), so an active run emits
+    many enrichment requests in quick succession rather than one. An operator can change the
+    User-Agent, so a quiet result is inconclusive, not proof of safety; see the behaviour-based
+    detection in the defense guide, section 4. Tune the count and window to your own baseline.
+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
+    - https://github.com/jiwoochris/artex-ko
+author: artex-ko defense guide
+date: 2026-10-05
+tags:
+    - attack.reconnaissance
+    - attack.t1595
+    - attack.t1592
+correlation:
+    type: event_count
+    rules:
+        - 34adfa15-1696-4322-afc0-f69988e9cc1e
+    group-by:
+        - c-ip
+    timespan: 5m
+    condition:
+        gte: 30
+falsepositives:
+    - Legitimate asset-management or monitoring tools that set this User-Agent and poll many
+      assets; allow-list their source addresses.
+level: high

detections/sigma/correlation/artex_guard_block_burst.yml

@@ -0,0 +1,34 @@
+# references base rule: ../artex_guard_audit_framing.yml (ARTEX Platform Guard Audit-Log Framing)
+title: ARTEX Guard-Block Burst (Active Engaged Session)
+id: 065c11b5-4dcf-48ae-84fe-e8301346d5b4
+status: experimental
+description: |
+    Correlates repeated ARTEX platform-guard control markers in one host's application or audit
+    log within a short window. The base rule matches a single marker, which can also appear in a
+    document or source file that merely quotes it. A burst of the same marker on one host instead
+    indicates an ARTEX run that is actively and repeatedly tripping its guard — which both
+    confirms execution on that host and removes the quote-a-marker false positive of the single
+    event. This remains a host and forensic indicator, not a target-side signal. Tune the count
+    and window to your environment.
+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
+    - https://github.com/jiwoochris/artex-ko
+author: artex-ko defense guide
+date: 2026-10-05
+tags:
+    - attack.execution
+    - attack.t1059
+correlation:
+    type: event_count
+    rules:
+        - 3add497e-36cb-47c4-8993-df8f98585ef7
+    group-by:
+        - host
+    timespan: 10m
+    condition:
+        gte: 5
+falsepositives:
+    - A log pipeline that repeatedly ingests or re-processes a document quoting this marker;
+      scope the rule to runtime application/audit logs, not documentation stores.
+level: high

detections/sigma/correlation/artex_guard_marker_then_destructive.yml

@@ -0,0 +1,40 @@
+# references base rules:
+#   ../artex_guard_audit_framing.yml   (ARTEX Platform Guard Audit-Log Framing)
+#   ../destructive_command_hunting.yml (Destructive Command Execution — ARTEX Guard-List Hunting)
+title: ARTEX Guard Marker With Destructive Command on One Host
+id: 1a03bfb8-7893-4730-9422-dd50c2dd91e8
+status: experimental
+description: |
+    Temporal correlation for the multi-stage behaviour in the defense guide, section 4.2: on a
+    single host, the ARTEX platform-guard control marker (confirming ARTEX executed there) AND a
+    destructive command from the guard deny-list hunting rule occur within the same window.
+    Pairing an ARTEX-specific marker with the otherwise-generic destructive-command signal raises
+    specificity. A destructive command on its own is routine administration and a known source of
+    false positives; one that co-occurs with an active ARTEX run on the same host is worth
+    investigating. This assumes a normalized host field is present across both the application or
+    audit logs and the process-creation logs; map it in your pipeline. It does not by itself prove
+    ARTEX issued the command — the guard blocks these patterns, so a hit means the destructive
+    command ran outside or despite the guard near an ARTEX run. Treat it as a high-priority lead.
+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
+    - https://github.com/jiwoochris/artex-ko
+author: artex-ko defense guide
+date: 2026-10-05
+tags:
+    - attack.execution
+    - attack.t1059
+    - attack.impact
+    - attack.t1485
+correlation:
+    type: temporal
+    rules:
+        - 3add497e-36cb-47c4-8993-df8f98585ef7
+        - f510564f-2958-4dc8-a188-3300a2f6f5a7
+    group-by:
+        - host
+    timespan: 30m
+falsepositives:
+    - Maintenance windows where an operator legitimately runs ARTEX and, separately, performs
+      destructive administration on the same host within the window. Confirm with change tickets.
+level: high