[BUG] AWS CreateAccessKey: unquoted field names make the cross-user filter a no-op (fires on self-key creation)
メンテナーはふだん 1 日以内に返信
@themaryjo がすでに取り組んでいます。
2026年9月29日 から。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 72/100
調査の方向性
detections/cloud/aws_createaccesskey.yml から始め、クロスユーザーフィルターと aws_createaccesskey_filter を調査します。自己完結型の SPL 再現を実行して現在の結果を確認し、その後、ルールが自身のキーの作成を除外しつつ、別のユーザーによるキーの作成は維持することを検証します。これには requestParameters.userName を含まないリクエストも含まれます。Issue に記載されているコンソール除外の動作を確認し、最終的なスコープがルールに反映されていることを確認します。
索引モデルが issue の本文から書いたものです。
説明
Describe the bug
AWS CreateAccessKey (detections/cloud/aws_createaccesskey.yml, id 2a9b80d3-6340-4345-11ad-212bf3d0d111) is meant to surface a user creating an access key for a different user:
| eval match=if(match(userIdentity.userName,requestParameters.userName),1,0)
| search match=0
Inside eval, the dotted field names are not single-quoted, so SPL parses userIdentity.userName as the . concatenation of the (non-existent) fields userIdentity and userName. Both arguments to match() evaluate to null, match is always 0, and search match=0 keeps every event. As shipped, the filter does nothing: the rule fires on every successful non-console CreateAccessKey, including the routine case of a user rotating their own key.
Repro
Self-contained, with no data needed:
| makeresults count=2
| streamstats count as n
| eval _raw=if(n==1, "{\"userIdentity\":{\"userName\":\"alice\"},\"requestParameters\":{\"userName\":\"alice\"}}", "{\"userIdentity\":{\"userName\":\"alice\"},\"requestParameters\":{\"userName\":\"bob\"}}")
| spath
| eval case=if(n==1,"self: alice creates a key for alice","cross-user: alice creates a key for bob")
| eval match=if(match(userIdentity.userName,requestParameters.userName),1,0)
| eval match_quoted=if('userIdentity.userName'=='requestParameters.userName',1,0)
| table case userIdentity.userName requestParameters.userName match match_quoted
Output:
| case | userIdentity.userName | requestParameters.userName | match (shipped) | match_quoted |
|---|---|---|---|---|
| self: alice creates a key for alice | alice | alice | 0 | 1 |
| cross-user: alice creates a key for bob | alice | bob | 0 | 0 |
The self-key row should be excluded (match=1), but the shipped expression returns 0.
Expected behavior
Only cross-user key creation should produce a result. A minimal fix quotes the fields and compares them directly. match() also treats its second argument as a regex, so a username like svc. would match svcX:
| eval match=if('userIdentity.userName'=='requestParameters.userName',1,0)
| search match=0
One related case to consider: when requestParameters.userName is absent (the key is for the caller), the request is a self-key and should also be excluded, e.g. if(isnull('requestParameters.userName') OR 'userIdentity.userName'=='requestParameters.userName',1,0).
Additional context: the console exclusion no longer matches console calls
The base search excludes console activity with userAgent!=console.amazonaws.com. A real console-issued CreateAccessKey captured from an AWS account in 2026 records a browser user agent (Mozilla/5.0 ... Chrome/...) together with "sessionCredentialFromConsole": "true", not console.amazonaws.com. Keys created in the console today therefore aren't excluded. A scripted caller can also evade the rule by sending the literal console.amazonaws.com user agent.
sessionCredentialFromConsole is not a clean replacement key. It marks console-session credentials, not the client, and AWS's own log examples show CloudShell CLI calls (exec-env/CloudShell) carrying it, including IAM calls. Excluding on it would hide cross-user key creation scripted from CloudShell. Once the cross-user filter works, dropping the console exclusion altogether and suppressing known provisioning principals in aws_createaccesskey_filter may be the better trade-off.
App Version:
- ESCU: reproduced on 5.26.0; SPL unchanged on
develop(64acde7bf6, rule version 11) - Splunk Enterprise 9.3.10, Splunk_TA_aws 7.11.0
- 主要言語
- Python
- スター
- 1.7k
- フォーク
- 494
- 平均マージ
- 2日 6時間
- マージ済み PR（30日）
- 32
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
splunk/security_content のほかの issue
-
Duplicate *http* Pattern in Windows Ngrok Reverse Proxy Usage Detection対応中かも @nasbench が 4 日前に担当しました。 オープンbug
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
splunk/security_content#4275 · コメント 1 件 · 担当者 2 名 ·
メンテナーはふだん 1 日以内に返信
-
Splunk Add-on for Sysmon for Linux is archived on Splunkbase対応中かも @nasbench が今日担当しました。 オープン
splunk/security_content#4306 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
DEPRECATED Add-on for Cisco Network Data is archived on Splunkbase対応中かも @nasbench が今日担当しました。 オープン
splunk/security_content#4305 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
App for CircleCI is archived on Splunkbase対応中かも @nasbench が今日担当しました。 オープン
splunk/security_content#4304 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] Detect New Open S3 Buckets over AWS CLI: operator precedence makes it fire on any aws-cli PutBucketAcl (incl. private ACLs); canned public-read missed when alone in the window対応中かも @P4T12ICK が 3 日前に担当しました。 オープンbug
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
splunk/security_content#4293 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
splunk/security_content の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
BasedHardware/omi#20271 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 92/100
openai/openai-cookbook#3153 ·
メンテナーはふだん 1 日以内に返信
-
cvss-severity:high devguard l3montree-cybersecurity/devguard/devguard pkg:golang/github.com/l3montree-dev/devguard risk:low state:open
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
l3montree-dev/devguard#3146 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
bug confirmed issue
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
open-webui/open-webui#31849 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信