First Commit

detections/sigma/README.ko.md

@@ -0,0 +1,124 @@
+# ARTEX 탐지 규칙 (Sigma / 호스트·로그·SIEM)
+
+한국어 · [English](README.md)
+
+이 디렉터리는 ARTEX 탐지 묶음에서 호스트·로그·SIEM 계층을 맡습니다. 여기 실린
+[Sigma](https://sigmahq.io) 규칙은 방어 가이드([한국어](../../docs/defense-ko.md) ·
+[English](../../docs/defense-en.md)) 4절의 의사 규칙을 벤더 중립 형식으로 정식화한 것이고, 각자의
+SIEM·EDR 질의 언어로 변환해 씁니다. 모든 지표는 추정이 아니라 이 저장소 소스에서 실제로 확인한
+문자열이나 행동에 근거합니다. 네트워크 계층은 [`../suricata/`](../suricata/)에 있고, ATT&CK 레이어와
+지표 CSV·MISP 내보내기, 호스트 분류 스크립트를 포함한 전체 탐지 묶음은
+[`../README.ko.md`](../README.ko.md)가 색인합니다. 모든 규칙은 자신이 소유하거나 서면 허가를 받은
+시스템을 지키는 **방어·탐지 목적에만** 사용하십시오.
+
+## 원자(atomic) 규칙
+
+규칙 하나가 관측 가능한 사실 하나에 대응합니다. 개별로 변환해도 되고, 트리 전체의 일부로 변환해도
+됩니다.
+
+- **[`artex_enrich_user_agent.yml`](artex_enrich_user_agent.yml)**: *ARTEX Asset Enrichment Probe
+  User-Agent*. 자산 보강(`enrich/enrich.go`)이 보내는 인바운드 `artex-enrich/1.0` User-Agent 입니다.
+  대상 측에서 관측하는 보조 지표입니다. `level: high`.
+- **[`artex_selfupdate_egress.yml`](artex_selfupdate_egress.yml)**: *ARTEX Self-Update Egress
+  User-Agent*. 자가 업데이트 루틴(`selfupdate/github.go`)이 내보내는 아웃바운드 `artex-selfupdate`
+  User-Agent 입니다. 호스트·포렌식 egress 지표입니다. `level: medium`.
+- **[`artex_guard_audit_framing.yml`](artex_guard_audit_framing.yml)**: *ARTEX Platform Guard
+  Audit-Log Framing*. 도구 호출이 차단될 때 감사 로그에 기록되는 플랫폼 가드 통제 마커입니다
+  (`guard/guard.go`). 호스트·포렌식 지표입니다. `level: high`.
+- **[`artex_recording_proxy_ca.yml`](artex_recording_proxy_ca.yml)**: *ARTEX Recording-Proxy MITM CA
+  Certificate Artifact*. 기록 프록시가 `_ca/mitmproxy-ca-cert.pem` 배치로 생성하는 MITM CA 파일입니다
+  (`traffic/traffic.go`). 호스트·포렌식 산출물이며, 파일명 자체는 단독 실행 mitmproxy 와도 공유되므로
+  사냥 단서(hunting lead)로 취급합니다. `level: medium`.
+- **[`destructive_command_hunting.yml`](destructive_command_hunting.yml)**: *Destructive Command
+  Execution (ARTEX Guard-List Hunting)*. ARTEX 가드의 내장 거부 목록(`db/db.go` 시드)을 반영한 파괴적
+  셸·DB 명령입니다. ARTEX 고유 시그니처가 **아니라** 일반 사냥 단서입니다. `level: medium`.
+
+## 상관(correlation) 규칙 (행동 기반) · [`correlation/`](correlation/)
+
+정적 문자열은 바꿀 수 있지만 행동은 숨기기가 더 어렵습니다. 이 Sigma **상관** 규칙들은 방어 가이드
+4.1~4.2절과 4.4절의 행동 기반 계층을 정식화합니다. 각 규칙은 위의 원자 규칙 하나를 `id` 로 참조하므로,
+상관 파일 하나가 아니라 **`sigma/` 트리 전체를 변환해야** 참조가 풀립니다([Sigma 테스트](../tests/sigma/)가
+바로 이 의존 관계를 단언합니다).
+
+- **[`correlation/artex_enrich_scan_velocity.yml`](correlation/artex_enrich_scan_velocity.yml)**:
+  *Enrichment Scan Velocity*. 한 출처가 짧은 창 안에 `artex-enrich/1.0` 프로브를 몰아치는 경우입니다
+  (보강은 동시성 4로, 속도 제한 없이 돕니다). 단건 규칙이 놓치는 속도를 잡습니다. `event_count`,
+  `level: high`.
+- **[`correlation/artex_enrich_fanout.yml`](correlation/artex_enrich_fanout.yml)**: *Enrichment
+  Fan-Out*. 한 출처가 보강 User-Agent 를 서로 다른 여러 호스트로 퍼뜨리는 경우입니다. 요청량이 아니라
+  접촉한 서로 다른 호스트 수가 신호이며, 자산 목록을 기계 속도로 훑는 폭을 잡습니다. `value_count`,
+  `level: high`.
+- **[`correlation/artex_guard_block_burst.yml`](correlation/artex_guard_block_burst.yml)**:
+  *Guard-Block Burst*. 한 호스트에서 플랫폼 가드 통제 마커가 반복되는 경우입니다. 마커를 인용만 한
+  문서가 아니라, 실제로 가동 중인 ARTEX 실행이 자기 가드를 건드리는 상황을 가리킵니다. `event_count`,
+  `level: high`.
+- **[`correlation/artex_guard_marker_then_destructive.yml`](correlation/artex_guard_marker_then_destructive.yml)**:
+  *Guard Marker With Destructive Command*. 가드 마커와 파괴적 명령이 한 호스트에서 한 창 안에 함께
+  나타나는 경우입니다(방어 가이드 4.2절, 다단계). ARTEX 고유 마커를 원래 일반적인 파괴적 명령 신호와
+  결합하므로 특이도가 올라갑니다. `temporal`, `level: high`.
+
+임계값과 창은 보수적인 기본값이므로, 자신의 기준선에 맞게 조정하십시오. 순수 웹 다단계 경우(열거 →
+프로빙 → 인증)는 여전히 환경별 기본 규칙이 필요합니다. 그 패턴은 ARTEX 고유 User-Agent 하나로
+환원되지 않기 때문입니다. 시작점으로 쓸 일반 행동 기반 기본 템플릿은 [방어 가이드 4.2절](../../docs/defense-ko.md)에
+있으며, ARTEX 소스에 근거를 둘 수 없어 이 검증된 트리에서는 의도적으로 뺐습니다.
+
+## 범위와 정직함: 배포 전에 읽으십시오
+
+- **정적 지표는 바꿀 수 있습니다.** 운영자가 User-Agent 를 바꾸거나 CA 파일을 지울 수 있으므로, 원자
+  지표가 없다고 해서 안전하다는 뜻은 **아닙니다**. 오래가는 신호는 `correlation/` 규칙이 기준으로 삼는
+  행동입니다. 한 출처가 정찰에서 열거, 프로빙, 인증·주입 시도로 이어 가며, 응답에 적응하고, 쉬지 않고
+  도는 흐름이 그것입니다.
+- **파괴적 명령 규칙은 일반 사냥입니다.** ARTEX 가드 거부 목록을 반영하지만, 같은 명령을 정당한
+  관리자도 실행합니다. 적중은 단서로 다루고, 자신의 환경을 허용 목록으로 걸러 내며, 그것만으로 ARTEX
+  라고 단정하지 마십시오.
+- **포트와 스키마는 네트워크가 아니라 호스트 포렌식입니다.** 서버 기본 포트 `:8787` 과 기록 프록시
+  `127.0.0.1:8788`(`cmd/artex/main.go`), 그리고 PostgreSQL 탐색 그래프 스키마는 의심 호스트에서 직접
+  확인하는 편이 낫습니다. 그래서 시끄러운 규칙 대신 [지표 CSV](../indicators/)와
+  [호스트 분류 스크립트](../triage/)로 제공합니다.
+- **`logsource` 와 필드명은 일반값입니다.** 규칙은 일반 `category`·`product` 로그 소스와 필드명
+  (`cs-user-agent`, `CommandLine`, `TargetFilename`)을 씁니다. 변환 시 파이프라인(`-p`)으로 자신의
+  제품 스키마에 매핑하십시오. 아래 백엔드 설명을 참조하십시오.
+
+## 검증과 변환
+
+[sigma-cli](https://github.com/SigmaHQ/sigma-cli)(pySigma)로 검증했습니다. 저장소 루트에서 실행합니다.
+
+```sh
+python3 -m venv .venv && . .venv/bin/activate
+pip install sigma-cli
+
+# 구조 + 모범 사례 검증 (기대: 0 errors, 0 issues)
+sigma check detections/sigma/
+
+# 이 규칙 세트의 문서화된 기준선으로 SigmaHQ 관례 전체를 검사 (기대: 0 issues)
+pip install pySigma-validators-sigmahq
+sigma check --validation-config detections/tests/sigma_lint/validators.yml detections/sigma/
+
+# 상관 규칙이 참조하는 원자 규칙을 풀 수 있도록 트리 전체를 변환
+sigma plugin install splunk
+sigma convert -t splunk --without-pipeline detections/sigma/
+```
+
+백엔드마다 상관 규칙 지원이 다르므로 `-t` 선택이 중요합니다. Splunk, Elasticsearch EQL, Grafana Loki 는
+트리 전체를 변환하고, Elasticsearch Lucene, OpenSearch, 마이크로소프트 `kusto` 백엔드는 원자 규칙
+다섯 개만 변환합니다(창은 제품에서 네이티브로 표현합니다). 백엔드별 실측 표와 `--without-pipeline` ·
+`-p` 필드 매핑 설명은 [`../README.ko.md`](../README.ko.md)에 있고,
+[`../tests/sigma_backends/`](../tests/sigma_backends/)가 재현합니다.
+
+## 테스트
+
+[`../tests/`](../tests/) 아래 재현 가능한 네 스위트가 이 규칙들을 다루며, 각각 Docker 만 있으면 됩니다.
+[`sigma/`](../tests/sigma/)는 검증과 트리 전체 컴파일, 그리고 상관 규칙이 단독으로는 변환에 실패함을
+단언하고, [`sigma_match/`](../tests/sigma_match/)는 규칙이 악성 샘플에 실제로 발화하고 양성 샘플에는
+침묵하는지 확인하며, [`sigma_backends/`](../tests/sigma_backends/)는 백엔드 다섯 종의 이식성을,
+[`sigma_lint/`](../tests/sigma_lint/)는 SigmaHQ 검증기 기준선 전체(0 issues)를 확인합니다.
+[`../tests/README.ko.md`](../tests/README.ko.md)를 참조하십시오.
+
+## 기여
+
+탐지 기여를 환영합니다. 새 규칙은 모든 지표를 관측 가능한 사실에 근거해 두고, 한계를 `description` 에
+밝히며, SigmaHQ 검증기 기준선을 깨끗이 통과하고
+(`sigma check --validation-config ../tests/sigma_lint/validators.yml .`), 공격 안내로 읽히는 내용을
+담지 않아야 합니다. [`../../CONTRIBUTING.md`](../../CONTRIBUTING.md)와
+[`../suricata/`](../suricata/)의 네트워크 계층, 그리고 [`../README.ko.md`](../README.ko.md)를
+참조하십시오.

detections/sigma/README.md

@@ -0,0 +1,127 @@
+# ARTEX detection rules (Sigma / host · log · SIEM)
+
+English · [한국어](README.ko.md)
+
+> 한국어: 이 디렉터리는 [방어·탐지 가이드(docs/defense-ko.md)](../../docs/defense-ko.md) 4절
+> "탐지 규칙"의 의사 규칙을 실제로 배포 가능한 [Sigma](https://sigmahq.io) 규칙으로 옮긴 것입니다.
+> 네트워크 계층은 [`../suricata/`](../suricata/)가 담당합니다. 모든 규칙은 자신이 소유하거나 서면
+> 허가를 받은 시스템을 지키는 **방어·탐지 목적에만** 사용하십시오. 한국어 전체 문서는
+> **[README.ko.md](README.ko.md)** 를, 전체 탐지 묶음 개요는 **[../README.ko.md](../README.ko.md)** 를 보십시오.
+
+The host, log, and SIEM layer of the ARTEX detection set. These [Sigma](https://sigmahq.io) rules
+formalize the pseudo-rules in the defense guide ([Korean](../../docs/defense-ko.md) ·
+[English](../../docs/defense-en.md), section 4) into a vendor-neutral format you convert to your own
+SIEM or EDR query language. Every indicator is grounded in a string or behaviour verified in this
+repository's source, not inferred. The network layer lives under [`../suricata/`](../suricata/); the
+full detection set — the ATT&CK coverage layer, the indicator CSV / MISP export, and the host-triage
+script — is indexed in [`../README.md`](../README.md).
+
+## Atomic rules
+
+One rule, one observable fact. Convert them individually or as part of the whole tree.
+
+- **[`artex_enrich_user_agent.yml`](artex_enrich_user_agent.yml)** — *ARTEX Asset Enrichment Probe
+  User-Agent*. Inbound `artex-enrich/1.0` User-Agent from asset enrichment (`enrich/enrich.go`).
+  Target-side, supporting indicator. `level: high`.
+- **[`artex_selfupdate_egress.yml`](artex_selfupdate_egress.yml)** — *ARTEX Self-Update Egress
+  User-Agent*. Outbound `artex-selfupdate` User-Agent from the self-update routine
+  (`selfupdate/github.go`). Host/forensic egress indicator. `level: medium`.
+- **[`artex_guard_audit_framing.yml`](artex_guard_audit_framing.yml)** — *ARTEX Platform Guard
+  Audit-Log Framing*. The platform-guard control marker written to the audit log on a blocked tool
+  call (`guard/guard.go`). Host/forensic indicator. `level: high`.
+- **[`artex_recording_proxy_ca.yml`](artex_recording_proxy_ca.yml)** — *ARTEX Recording-Proxy MITM CA
+  Certificate Artifact*. Creation of the recording proxy's MITM CA file under the
+  `_ca/mitmproxy-ca-cert.pem` layout (`traffic/traffic.go`). Host/forensic artifact; the bare filename
+  is shared with standalone mitmproxy, so it is a hunting lead. `level: medium`.
+- **[`destructive_command_hunting.yml`](destructive_command_hunting.yml)** — *Destructive Command
+  Execution (ARTEX Guard-List Hunting)*. Destructive shell/DB commands mirroring the ARTEX guard's
+  built-in deny list (`db/db.go` seed). Generic hunting lead, **not** an ARTEX signature. `level: medium`.
+
+## Correlation rules (behaviour) — [`correlation/`](correlation/)
+
+Static strings can be changed; behaviour is harder to hide. These Sigma **correlation** rules encode the
+behaviour-based layer of the defense guide (sections 4.1–4.2 and 4.4). Each references an atomic rule
+above by its `id`, so **convert the whole `sigma/` tree, not a single correlation file**, or the
+reference will not resolve (the [Sigma test](../tests/sigma/) asserts exactly this dependency).
+
+- **[`correlation/artex_enrich_scan_velocity.yml`](correlation/artex_enrich_scan_velocity.yml)** —
+  *Enrichment Scan Velocity*. A burst of `artex-enrich/1.0` probes from one source in a short window
+  (enrichment runs at concurrency 4 with no rate limit) — the velocity the single-request rule misses.
+  `event_count`, `level: high`.
+- **[`correlation/artex_enrich_fanout.yml`](correlation/artex_enrich_fanout.yml)** — *Enrichment
+  Fan-Out*. One source carrying the enrichment User-Agent to many *distinct* hosts: machine-speed breadth
+  across an asset list, where the distinct-host count, not request volume, is the tell. `value_count`,
+  `level: high`.
+- **[`correlation/artex_guard_block_burst.yml`](correlation/artex_guard_block_burst.yml)** —
+  *Guard-Block Burst*. Repeated platform-guard control markers on one host — an actively engaged ARTEX
+  run tripping its own guard, not a document that merely quotes the marker. `event_count`, `level: high`.
+- **[`correlation/artex_guard_marker_then_destructive.yml`](correlation/artex_guard_marker_then_destructive.yml)**
+  — *Guard Marker With Destructive Command*. The guard marker and a destructive command co-occurring on
+  one host within a window (defense guide §4.2, multi-stage): combining an ARTEX-specific marker with the
+  otherwise-generic destructive-command signal raises specificity. `temporal`, `level: high`.
+
+Thresholds and windows are conservative defaults — tune them to your baseline. The pure web multi-stage
+case (enumerate → probe → authenticate) still needs base rules specific to your environment, because that
+pattern does not reduce to a single ARTEX-unique User-Agent; a generic behavioural base template to start
+from is in the [defense guide §4.2](../../docs/defense-en.md), kept out of this tested tree because it
+cannot be grounded in ARTEX source.
+
+## Scope and honesty — read before deploying
+
+- **Static indicators can be changed.** An operator can set a different User-Agent or clean up the CA
+  file, so the absence of an atomic indicator does **not** mean safety. The durable signal is the
+  behaviour the `correlation/` rules key on — one source chaining recon → enumeration → probing →
+  auth/injection attempts, adapting to responses, running without pause.
+- **The destructive-command rule is generic hunting.** It mirrors ARTEX's guard deny list, but the same
+  commands are run by legitimate administrators. Treat a hit as a lead, allow-list your environment, and
+  do not attribute it to ARTEX on its own.
+- **Ports and schema are host-forensic, not Sigma.** The server default `:8787` and recording proxy
+  `127.0.0.1:8788` (`cmd/artex/main.go`), and the PostgreSQL exploration-graph schema, are best checked on
+  a suspected host, so they ship in the [indicator CSV](../indicators/) and the
+  [host-triage script](../triage/) rather than as noisy rules.
+- **`logsource` and field names are generic.** The rules use generic `category`/`product` log sources and
+  field names (`cs-user-agent`, `CommandLine`, `TargetFilename`). Map them to your product's schema with a
+  pipeline (`-p`) at convert time; see the backend notes below.
+
+## Validate and convert
+
+Validated with [sigma-cli](https://github.com/SigmaHQ/sigma-cli) (pySigma). From the repository root:
+
+```sh
+python3 -m venv .venv && . .venv/bin/activate
+pip install sigma-cli
+
+# structural + best-practice validation (expect: 0 errors, 0 issues)
+sigma check detections/sigma/
+
+# full SigmaHQ convention set with this rule set's documented baseline (expect: 0 issues)
+pip install pySigma-validators-sigmahq
+sigma check --validation-config detections/tests/sigma_lint/validators.yml detections/sigma/
+
+# compile the WHOLE tree so the correlation rules resolve the atomic rules they reference by id
+sigma plugin install splunk
+sigma convert -t splunk --without-pipeline detections/sigma/
+```
+
+Backends vary in correlation support, so the `-t` choice matters: Splunk, Elasticsearch EQL, and Grafana
+Loki convert the whole tree, while Elasticsearch Lucene, OpenSearch, and the Microsoft `kusto` backend
+convert the five atomic rules only (express the window natively in the product). The measured per-backend
+matrix and the `--without-pipeline` / `-p` field-mapping notes are in [`../README.md`](../README.md), and
+they are reproduced by [`../tests/sigma_backends/`](../tests/sigma_backends/).
+
+## Tests
+
+Four reproducible suites under [`../tests/`](../tests/) cover these rules, each needing only Docker:
+[`sigma/`](../tests/sigma/) (validation, whole-tree compilation, and that a correlation rule fails to
+convert alone), [`sigma_match/`](../tests/sigma_match/) (the rules actually fire on malicious samples and
+stay quiet on benign ones), [`sigma_backends/`](../tests/sigma_backends/) (portability across five
+backends), and [`sigma_lint/`](../tests/sigma_lint/) (the full SigmaHQ validator baseline, 0 issues). See
+[`../tests/README.md`](../tests/README.md).
+
+## Contributing
+
+Detection contributions are welcome. New rules should keep every indicator grounded in an observable fact,
+state limitations in the `description`, pass the SigmaHQ validator baseline cleanly
+(`sigma check --validation-config ../tests/sigma_lint/validators.yml .`), and avoid any content that reads
+as attack guidance. See [`../../CONTRIBUTING.en.md`](../../CONTRIBUTING.en.md) and the network layer in
+[`../suricata/`](../suricata/) / [`../README.md`](../README.md).

detections/sigma/artex_enrich_user_agent.yml

@@ -0,0 +1,31 @@
+title: ARTEX Asset Enrichment Probe User-Agent
+id: 34adfa15-1696-4322-afc0-f69988e9cc1e
+status: experimental
+description: |
+    Detects inbound HTTP requests whose User-Agent is "artex-enrich/1.0", set by the ARTEX
+    autonomous penetration-testing framework when it auto-enriches assets (DNS/HTTP checks)
+    and reads a target's <title>. This probe is generated by ARTEX itself, independent of the
+    LLM: it does not follow redirects, disables keep-alive, and reads only the beginning of the
+    response. Default concurrency is 4, so several assets may be probed at once. An operator can
+    change this User-Agent, so its ABSENCE does not imply safety. Treat it as a supporting
+    indicator and combine it with the behaviour-based detection in the defense guide, section 4.
+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
+logsource:
+    category: webserver
+detection:
+    selection:
+        cs-user-agent: 'artex-enrich/1.0'
+    condition: selection
+falsepositives:
+    - Unlikely; this User-Agent string is specific to the ARTEX enrichment client, but an
+      operator who changed it will not be caught here.
+level: high

detections/sigma/artex_guard_audit_framing.yml

@@ -0,0 +1,27 @@
+title: ARTEX Platform Guard Audit-Log Framing
+id: 3add497e-36cb-47c4-8993-df8f98585ef7
+status: experimental
+description: |
+    Detects the control-framing string the ARTEX platform guard writes to its audit log when it
+    blocks a tool call. Blocked calls are recorded with a message beginning with the literal
+    marker shown below (ARTEX platform control, non-target defence). Finding this marker in a
+    host's application or audit logs strongly supports that ARTEX ran on that host. This is a
+    host and forensic indicator, not a target-side signal.
+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
+logsource:
+    category: application
+detection:
+    keywords:
+        - '【ARTEX 平台管控·非目标防御】'
+    condition: keywords
+falsepositives:
+    - Logs that quote this defense guide or the ARTEX source code for documentation purposes.
+level: high

detections/sigma/artex_recording_proxy_ca.yml

@@ -0,0 +1,37 @@
+title: ARTEX Recording-Proxy MITM CA Certificate Artifact
+id: 3bac40a5-a780-4d1f-a7e8-5d0daa29ef47
+status: experimental
+description: |
+    Detects creation of the man-in-the-middle certificate-authority file the ARTEX recording proxy writes
+    when it starts. ARTEX embeds a go-mitmproxy traffic recorder that decrypts and logs every HTTP(S)
+    exchange its worker tools make; on first start the recorder generates a CA under its data directory
+    (traffic/traffic.go writes "<dir>/_ca/mitmproxy-ca-cert.pem") and injects it into spawned tools through
+    SSL_CERT_FILE / CURL_CA_BUNDLE / REQUESTS_CA_BUNDLE / NODE_EXTRA_CA_CERTS together with an
+    HTTP(S)_PROXY pointing at the loopback recorder (agent/worker.go). The file appearing on a host is a
+    forensic artifact of that recording proxy having run: an adversary-in-the-middle traffic recorder
+    (ATT&CK T1557) whose trust anchor is an installed root certificate. The "_ca/mitmproxy-ca-cert.pem"
+    layout narrows it to ARTEX's data directory; a bare mitmproxy-ca-cert.pem is shared with standalone
+    go-mitmproxy / mitmproxy, so treat a hit as a host-triage lead to correlate with the loopback proxy
+    endpoint and server port (see the indicators list), not a standalone alert.
+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-07
+tags:
+    - attack.credential-access
+    - attack.collection
+    - attack.t1557
+logsource:
+    category: file_event
+detection:
+    selection:
+        TargetFilename|contains|all:
+            - '_ca'
+            - 'mitmproxy-ca-cert.pem'
+    condition: selection
+falsepositives:
+    - Standalone go-mitmproxy or mitmproxy deployments that write the same CA filename.
+    - Developers intentionally running a recording or debugging proxy on the host.
+level: medium

detections/sigma/artex_selfupdate_egress.yml

@@ -0,0 +1,27 @@
+title: ARTEX Self-Update Egress User-Agent
+id: e96380a3-2a34-4237-be2b-088ad9cc947d
+status: experimental
+description: |
+    Detects outbound (egress) HTTP requests whose User-Agent is "artex-selfupdate", used by the
+    ARTEX self-update routine when it queries code-repository hosts (for example GitHub releases)
+    for a newer binary. Seeing this User-Agent leave an internal host toward a code-hosting
+    service suggests an ARTEX binary is installed on that host. This is primarily an operator and
+    forensic indicator on a (possibly compromised relay) host, not a target-side signal.
+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.command-and-control
+    - attack.t1105
+logsource:
+    category: proxy
+detection:
+    selection:
+        c-useragent: 'artex-selfupdate'
+    condition: selection
+falsepositives:
+    - Unlikely; this User-Agent string is specific to the ARTEX self-update client.
+level: medium

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

detections/sigma/destructive_command_hunting.yml

@@ -0,0 +1,64 @@
+title: Destructive Command Execution (ARTEX Guard-List Hunting)
+id: f510564f-2958-4dc8-a188-3300a2f6f5a7
+status: experimental
+description: |
+    Hunts for destructive shell and database commands on a host. The pattern set mirrors the
+    built-in deny rules the ARTEX guard ships with (db/db.go seed): because the guard blocks
+    these, they are the inverse image of the destructive actions an autonomous agent could
+    attempt if the guard were disabled or bypassed. This is GENERIC destructive-command hunting
+    informed by that list, not an ARTEX-specific signature, and matches are expected from
+    legitimate administration. Tune and allow-list for your environment and treat a hit as a
+    hunting lead, not a standalone alert. High-noise availability commands the guard also blocks
+    (bare shutdown/reboot) are intentionally omitted here; hunt those separately. The database
+    patterns likewise track data-destroying objects (DROP DATABASE/TABLE/SCHEMA) rather than the
+    guard's wider DROP set (INDEX/VIEW/USER/ROLE/TABLESPACE), which alter structure or access
+    rather than destroy data and are noisy in routine migrations.
+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.impact
+    - attack.t1485
+    - attack.t1561.002
+    - attack.t1489
+logsource:
+    category: process_creation
+detection:
+    selection_filesystem:
+        CommandLine|contains:
+            - 'rm -rf'
+            - 'rm -fr'
+            - 'rm --recursive'
+            - '--no-preserve-root'
+            - 'mkfs'
+            - 'dd of=/dev/'
+            - 'shred '
+            - 'wipe /dev/'
+    selection_database:
+        CommandLine|contains:
+            - 'DROP DATABASE'
+            - 'DROP TABLE'
+            - 'DROP SCHEMA'
+            - 'TRUNCATE '
+            - '.dropDatabase('
+            - '.dropCollection('
+            - 'FLUSHALL'
+            - 'FLUSHDB'
+    selection_availability:
+        CommandLine|contains:
+            - 'curl -X DELETE'
+            - 'curl --request DELETE'
+            - 'wget --method=DELETE'
+            - 'iptables -F'
+            - 'nft flush ruleset'
+            - 'kill -9 -1'
+            - 'killall -9'
+    condition: 1 of selection_*
+falsepositives:
+    - Routine system administration, maintenance scripts, and container teardown.
+    - CI/CD pipelines that drop and recreate test databases or caches.
+    - The GNU coreutils `truncate` command (e.g. log rotation `truncate -s 0 file`) shares the TRUNCATE token; allow-list it, since it is followed by a flag rather than a table name.
+level: medium