🎯 contentctlとは?
contentctl は、SplunkのEnterprise Security(ES)向けに、検知ルールなどのセキュリティコンテンツをコードベースで作成・管理できるCLIツールです。
ざっくりいうと、「検知ルールをYAMLで管理してCI/CD的に運用できるようにするやつ」です。
GitHubで公開されていて、以下のリポジトリでドキュメントも整っています:
👉 https://github.com/splunk/contentctl
🚀 使ってみた
公式のUser Guideをベースに試してみました!
(お試しなので、入力情報は雑にテキトーなものを入れています🙏)
GithubにあるQuick Start Guideを元に進める〜
進めた結果、作成されたMyNewContentPackの中身はこんな感じ
Detectionの作り方
contentctl new --type detectionを実施してdetectionを作成していく
コマンドを打つとディレクションが出てきてdetection nameなどの入力を求められる。
次に作成者
detection typeの選択
データソース(どのログ(イベントID)を使って不正アクセスを検知するか)の選択
複数選択も実施できる
ちなみにWindows Security4625とか書かれている内容はググると詳細が出てきます。
例)https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625
次はこの検知ルールがどの攻撃手法(MITRE ATT&CK の Technique)に関連するか を指定
security domain for detection(検知ルールがどのセキュリティ分野(ドメイン)に属するか)を指定
上記の内容で完了
作成したフォルダの下記のディレクトリにyamlが作成されている。(今回detectionで作成したので)
detections>endpoint>
📦 サンプルで入っていた検知ルール
初期状態で入っていた以下の検知ルールを使って検証してみました。
📄 anomalous_usage_of_7zip.yml
中身はこんな感じ。。
name: Anomalous usage of 7zip
id: 9364ee8e-a39a-11eb-8f1d-acde48001122
version: 1
date: '2021-04-22'
author: Michael Haag, Teoderick Contreras, Splunk
status: production
type: Anomaly
description: The following detection identifies a 7z.exe spawned from `Rundll32.exe`
or `Dllhost.exe`. It is assumed that the adversary has brought in `7z.exe` and `7z.dll`.
It has been observed where an adversary will rename `7z.exe`. Additional coverage
may be required to identify the behavior of renamed instances of `7z.exe`. During
triage, identify the source of injection into `Rundll32.exe` or `Dllhost.exe`. Capture
any files written to disk and analyze as needed. Review parallel processes for additional
behaviors. Typically, archiving files will result in exfiltration.
data_source:
- Sysmon EventID 1
search: '| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes where Processes.parent_process_name
IN ("rundll32.exe", "dllhost.exe") Processes.process_name=*7z* by Processes.dest
Processes.user Processes.parent_process Processes.process_name Processes.process
Processes.process_id Processes.parent_process_id Processes.parent_process_name | `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`| `anomalous_usage_of_7zip_filter`'
how_to_implement: To successfully implement this search you need to be ingesting information
on process that include the name of the process responsible for the changes from
your endpoints into the `Endpoint` datamodel in the `Processes` node.
known_false_positives: False positives should be limited as this behavior is not normal
for `rundll32.exe` or `dllhost.exe` to spawn and run 7zip.
references:
- https://attack.mitre.org/techniques/T1560/001/
- https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/
- https://thedfirreport.com/2021/01/31/bazar-no-ryuk/
drilldown_searches:
- name: View the detection results for $user$ and $dest$
search: '%original_detection_search% | search user = $user$ dest = $dest$'
earliest_offset: $info_min_time$
latest_offset: $info_max_time$
- name: View risk events for the last 7 days for $user$ and $dest$
search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ($user$, $dest$) starthoursago=168 endhoursago=1 | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
earliest_offset: $info_min_time$
latest_offset: $info_max_time$
rba:
message: An instance of $parent_process_name$ spawning $process_name$ was identified
on endpoint $dest$ by user $user$. This behavior is indicative of suspicious loading
of 7zip.
risk_objects:
- field: user
type: user
score: 56
- field: dest
type: system
score: 60
threat_objects:
- field: parent_process_name
type: parent_process_name
- field: process_name
type: process_name
tags:
analytic_story:
- Cobalt Strike
asset_type: Endpoint
mitre_attack_id:
- T1560.001
product:
- Splunk Enterprise
- Splunk Enterprise Security
- Splunk Cloud
security_domain: endpoint
tests:
- name: True Positive Test
attack_data:
- data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1560.001/archive_utility/windows-sysmon.log
source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
sourcetype: xmlwineventlog
「7z.exe」が不審なオプションで使われているパターンを検知するルールです。
MITREのT1560(Archive Collected Data)などに関連する検知ですね。
🛠 buildしてみる
contentctl build
上記コマンドを叩くと、dist/ ディレクトリにビルド済みのファイルが生成される
Splunkに入れてみると
Content Packという名前のAppが入る。
開けてみたら下記の画面。
まとめ(with GPT)
contentctl は、コマンドラインベースでSplunk Enterprise Security (ES) の検知ルールの作成、管理、テスト、デプロイを一元化するためのツール。活用することで、検知ルールの精度向上、誤検知の削減、CI/CD ワークフローによる自動化も可能。
🎯 contentctl を活用するメリット
✅ 検知ルールの作成からデプロイまでのプロセスを一元管理し、運用を効率化
✅ YAMLベースのスキーマを利用し、製品依存のない検知ルールの開発を実現
✅ CI/CD ワークフローと統合し、継続的なテスト・デプロイを自動化
✅ 検知ルールのバージョン管理を強化し、誤検知を最小限に抑える
✅ MITRE ATT&CK や RBA(リスクベースアラート)を活用し、脅威の可視化を向上
✅ Attack Range や Mordor Labs を活用して、シミュレーションベースの検証が可能
🔗 参考リンク
contentctl GitHub:https://github.com/splunk/contentctl
User Guide:https://github.com/splunk/contentctl/blob/main/docs/UserGuide.md