diff --git a/detection_rules/etc/beats_schemas/main.json.gz b/detection_rules/etc/beats_schemas/main.json.gz index b0033e71d5b..5f4c5c7fed9 100644 Binary files a/detection_rules/etc/beats_schemas/main.json.gz and b/detection_rules/etc/beats_schemas/main.json.gz differ diff --git a/detection_rules/etc/beats_schemas/v9.4.3.json.gz b/detection_rules/etc/beats_schemas/v9.4.3.json.gz new file mode 100644 index 00000000000..7d958a11165 Binary files /dev/null and b/detection_rules/etc/beats_schemas/v9.4.3.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.10.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.10.0/ecs_flat.json.gz index 8fce2d01c34..86681e20789 100644 Binary files a/detection_rules/etc/ecs_schemas/8.10.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.10.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.10.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.10.0/ecs_nested.json.gz index 406174a9338..0b574d5e4e7 100644 Binary files a/detection_rules/etc/ecs_schemas/8.10.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.10.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.11.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.11.0/ecs_flat.json.gz index 2d932f3055d..fe538d698c0 100644 Binary files a/detection_rules/etc/ecs_schemas/8.11.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.11.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.11.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.11.0/ecs_nested.json.gz index 1d4523eab8e..8e25c24a015 100644 Binary files a/detection_rules/etc/ecs_schemas/8.11.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.11.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.16.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.16.0/ecs_flat.json.gz index ad4d3811b12..b1a82adde0c 100644 Binary files a/detection_rules/etc/ecs_schemas/8.16.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.16.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.16.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.16.0/ecs_nested.json.gz index 7bf30837400..9d33621dcc1 100644 Binary files a/detection_rules/etc/ecs_schemas/8.16.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.16.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.17.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.17.0/ecs_flat.json.gz index a37735d6ca6..cda620f544a 100644 Binary files a/detection_rules/etc/ecs_schemas/8.17.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.17.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.17.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.17.0/ecs_nested.json.gz index 03c9681112d..72893ecce4d 100644 Binary files a/detection_rules/etc/ecs_schemas/8.17.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.17.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.2.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.2.0/ecs_flat.json.gz index 565cbbca69a..c300d56dae8 100644 Binary files a/detection_rules/etc/ecs_schemas/8.2.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.2.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.2.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.2.0/ecs_nested.json.gz index df0c5f6d24b..812b3d1f049 100644 Binary files a/detection_rules/etc/ecs_schemas/8.2.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.2.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.2.1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.2.1/ecs_flat.json.gz index e06a18ffb53..a3efc945904 100644 Binary files a/detection_rules/etc/ecs_schemas/8.2.1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.2.1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.2.1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.2.1/ecs_nested.json.gz index 1e896caf600..9053aea2da8 100644 Binary files a/detection_rules/etc/ecs_schemas/8.2.1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.2.1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.3.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.3.0/ecs_flat.json.gz index 852bf7251f6..305787d328a 100644 Binary files a/detection_rules/etc/ecs_schemas/8.3.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.3.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.3.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.3.0/ecs_nested.json.gz index c7628178dcc..7e3419c25e3 100644 Binary files a/detection_rules/etc/ecs_schemas/8.3.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.3.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.3.1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.3.1/ecs_flat.json.gz index 2082a3b7255..629876149bc 100644 Binary files a/detection_rules/etc/ecs_schemas/8.3.1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.3.1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.3.1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.3.1/ecs_nested.json.gz index 0a3481b4aa1..ea70d48c8cd 100644 Binary files a/detection_rules/etc/ecs_schemas/8.3.1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.3.1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_flat.json.gz index 9655be99a2c..680f62ba379 100644 Binary files a/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_nested.json.gz index 18fa2fed12a..b4dbbeb7f56 100644 Binary files a/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.4.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.4.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.4.0/ecs_flat.json.gz index b52392f7603..44c3352f6a6 100644 Binary files a/detection_rules/etc/ecs_schemas/8.4.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.4.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.4.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.4.0/ecs_nested.json.gz index 7cf8ca8a384..b99f5f5779b 100644 Binary files a/detection_rules/etc/ecs_schemas/8.4.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.4.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_flat.json.gz index cf970e0d7c2..1412566d7b1 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_nested.json.gz index 3ff12955d9d..95d9e9b6f60 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.5.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.5.0/ecs_flat.json.gz index 54a0640b925..c327d090b9d 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.5.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.5.0/ecs_nested.json.gz index 61d7ac40ba3..ca4d0a5984d 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.5.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.5.1/ecs_flat.json.gz index a95145cd427..978d5620519 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.5.1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.5.1/ecs_nested.json.gz index 6a3f00337e6..e99b6ad3e3c 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.5.1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.2/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.5.2/ecs_flat.json.gz index c7fbfe0c5be..7999ac3a11d 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.2/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.5.2/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.5.2/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.5.2/ecs_nested.json.gz index 7c27cbf1b66..b53787f1845 100644 Binary files a/detection_rules/etc/ecs_schemas/8.5.2/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.5.2/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_flat.json.gz index c4630b6ee82..1851759b94d 100644 Binary files a/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_nested.json.gz index cbc94cf3b4c..04866fe5699 100644 Binary files a/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.6.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.6.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.6.0/ecs_flat.json.gz index cf60e6bb61f..5a6318c5c74 100644 Binary files a/detection_rules/etc/ecs_schemas/8.6.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.6.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.6.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.6.0/ecs_nested.json.gz index 8f80d36421f..9895c6d5faa 100644 Binary files a/detection_rules/etc/ecs_schemas/8.6.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.6.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.6.1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.6.1/ecs_flat.json.gz index cae6499465b..f520b489f51 100644 Binary files a/detection_rules/etc/ecs_schemas/8.6.1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.6.1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.6.1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.6.1/ecs_nested.json.gz index f8097bf50e4..9c98e6c6e38 100644 Binary files a/detection_rules/etc/ecs_schemas/8.6.1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.6.1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_flat.json.gz index 51f807f66af..f273e3ddb3c 100644 Binary files a/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_nested.json.gz index 824692c420a..6208576d881 100644 Binary files a/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.7.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.7.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.7.0/ecs_flat.json.gz index 4922380bcfe..c930d9fb49d 100644 Binary files a/detection_rules/etc/ecs_schemas/8.7.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.7.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.7.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.7.0/ecs_nested.json.gz index 6aadfb9db60..78b752d6b37 100644 Binary files a/detection_rules/etc/ecs_schemas/8.7.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.7.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.8.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.8.0/ecs_flat.json.gz index 435bf845b9a..e6f4d2e88e5 100644 Binary files a/detection_rules/etc/ecs_schemas/8.8.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.8.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.8.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.8.0/ecs_nested.json.gz index 64b8f2b95ae..b10690460f1 100644 Binary files a/detection_rules/etc/ecs_schemas/8.8.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.8.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.9.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.9.0/ecs_flat.json.gz index 6b47044d922..23cf5374434 100644 Binary files a/detection_rules/etc/ecs_schemas/8.9.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.9.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.9.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.9.0/ecs_nested.json.gz index d117d42872e..be9399f1d42 100644 Binary files a/detection_rules/etc/ecs_schemas/8.9.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.9.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_flat.json.gz index 58367cc4f40..ab31523284c 100644 Binary files a/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_nested.json.gz index 0d04c2dbdaa..39b66252774 100644 Binary files a/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.0.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.0.0/ecs_flat.json.gz index ee97c4dbe2b..c4849073c0c 100644 Binary files a/detection_rules/etc/ecs_schemas/9.0.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.0.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.0.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.0.0/ecs_nested.json.gz index 8671d3802e4..c7ed7c13502 100644 Binary files a/detection_rules/etc/ecs_schemas/9.0.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.0.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.1.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.1.0/ecs_flat.json.gz index 1c78100be2b..e246c42436f 100644 Binary files a/detection_rules/etc/ecs_schemas/9.1.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.1.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.1.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.1.0/ecs_nested.json.gz index 38fa16cc2c0..5866c7782cf 100644 Binary files a/detection_rules/etc/ecs_schemas/9.1.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.1.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_flat.json.gz index fa32e881f44..30a8e07fa63 100644 Binary files a/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_nested.json.gz index 485948d097b..21ca82161de 100644 Binary files a/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.2.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.2.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.2.0/ecs_flat.json.gz index d85f749e0d7..f32ad99712b 100644 Binary files a/detection_rules/etc/ecs_schemas/9.2.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.2.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.2.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.2.0/ecs_nested.json.gz index 2c92c614291..579b6bd9789 100644 Binary files a/detection_rules/etc/ecs_schemas/9.2.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.2.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_flat.json.gz index 613d79d960c..c720cf85831 100644 Binary files a/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_nested.json.gz index a1761f2c4c3..fd0564f9545 100644 Binary files a/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.3.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.3.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.3.0/ecs_flat.json.gz index a837c4fa9ab..0737dda3239 100644 Binary files a/detection_rules/etc/ecs_schemas/9.3.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.3.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.3.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.3.0/ecs_nested.json.gz index 0b7837c9e29..0425cf577cf 100644 Binary files a/detection_rules/etc/ecs_schemas/9.3.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.3.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_flat.json.gz index 5a936162134..378caa5f5ca 100644 Binary files a/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_nested.json.gz index b84b3889e81..b9a5d8a2f3b 100644 Binary files a/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/9.4.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.4.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/9.4.0/ecs_flat.json.gz new file mode 100644 index 00000000000..e9eae6e520f Binary files /dev/null and b/detection_rules/etc/ecs_schemas/9.4.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/9.4.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/9.4.0/ecs_nested.json.gz new file mode 100644 index 00000000000..28b8552f539 Binary files /dev/null and b/detection_rules/etc/ecs_schemas/9.4.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/integration-manifests.json.gz b/detection_rules/etc/integration-manifests.json.gz index a684e82ee49..b0274e61eeb 100644 Binary files a/detection_rules/etc/integration-manifests.json.gz and b/detection_rules/etc/integration-manifests.json.gz differ diff --git a/detection_rules/etc/integration-schemas.json.gz b/detection_rules/etc/integration-schemas.json.gz index f6df1333fd4..786c85f1a08 100644 Binary files a/detection_rules/etc/integration-schemas.json.gz and b/detection_rules/etc/integration-schemas.json.gz differ diff --git a/detection_rules/etc/stack-schema-map.yaml b/detection_rules/etc/stack-schema-map.yaml index 7b8c539f0f0..cbf41dcd994 100644 --- a/detection_rules/etc/stack-schema-map.yaml +++ b/detection_rules/etc/stack-schema-map.yaml @@ -150,11 +150,11 @@ endgame: "8.4.0" "9.4.0": - beats: "9.3.4" - ecs: "9.4.0-rc1" + beats: "9.4.3" + ecs: "9.4.0" endgame: "8.4.0" "9.5.0": - beats: "9.3.4" - ecs: "9.4.0-rc1" + beats: "9.4.3" + ecs: "9.4.0" endgame: "8.4.0" \ No newline at end of file diff --git a/pyproject.toml b/pyproject.toml index 33c11123c5b..3a0f25d7fe7 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "detection_rules" -version = "1.7.7" +version = "1.7.8" description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine." readme = "README.md" requires-python = ">=3.12" diff --git a/rules/linux/command_and_control_netcon_file_creation.toml b/rules/linux/command_and_control_netcon_file_creation.toml index bb46349791c..6f43cba2108 100644 --- a/rules/linux/command_and_control_netcon_file_creation.toml +++ b/rules/linux/command_and_control_netcon_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2026/07/02" integration = ["endpoint"] maturity = "production" -updated_date = "2026/07/02" +updated_date = "2026/07/06" [rule] author = ["Elastic"] @@ -16,6 +16,37 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.file*"] language = "eql" license = "Elastic License v2" name = "Network Connection Followed by File Creation" +note = """ ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Network Connection Followed by File Creation + +This rule spots a Linux process running from an unusual writable directory that makes an outbound connection and then creates a file within seconds, a pattern that often marks an active implant receiving tasks and staging follow-on activity. Attackers launch a loader from /dev/shm or /tmp, poll a remote web-based command server, and immediately drop a script or renamed payload for execution or persistence. + +### Possible investigation steps + +- Review the process ancestry and launch context for the binary in the writable directory to determine whether it originated from a user session, script, scheduled task, package operation, or remote execution mechanism. +- Inspect the external destination's reputation, ownership, protocol details, and whether other hosts contacted it at similar times to distinguish approved software behavior from likely command-and-control traffic. +- Examine the created file's location, type, hash, contents, permissions, and any immediate chmod, rename, or execution activity to assess whether it is a staged payload, script, or persistence artifact. +- Build a concise timeline around the alert to identify preceding download, decode, or unpack actions and any follow-on child processes, credential access attempts, or lateral movement from the same host. +- Search the environment for the same executable hash, destination, or dropped artifact on other systems and contain the host if you observe repeated beaconing, additional suspicious file creation, or evidence of execution. + +### False positive analysis + +- A legitimate software installer, updater, or bootstrap script launched from /tmp or /var/tmp can contact an external repository and immediately create unpacked files; verify the parent process, initiating user, shell history, and whether the destination IP and dropped files align with an approved installation or update at that time. +- An administrator or automation job may execute a temporary script from /dev/shm or /run/user to fetch remote content and write logs, configuration, or cache files; confirm the activity matches a scheduled task or provisioning change and inspect the created file paths and script contents for expected benign output. + +### Response and remediation + +- Isolate the affected Linux host from the network except for approved management access, kill the suspicious process running from the writable directory, quarantine the binary and any files it created, and block the contacted external IP or domain at the firewall, proxy, and DNS layers. +- Remove attacker footholds by deleting malicious systemd services, cron jobs, shell profile modifications, SSH authorized_keys entries, and any copied or renamed payloads the implant placed under writable paths or startup locations, after preserving forensic copies. +- Reset potentially exposed access by rotating passwords, SSH keys, API tokens, and service credentials used on the host, especially if the process ran as root, touched authentication files, or dropped scripts and configuration files that may contain secrets. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline when the binary or dropped files executed, then validate package integrity, startup items, and critical application data before reconnecting it to production. +- Escalate immediately to incident response if the same executable hash, outbound destination, or dropped artifact appears on additional hosts, or if you identify privilege escalation, credential theft, persistence in multiple locations, or attempted lateral movement. +- Harden the environment by blocking execution from /tmp, /dev/shm, and other writable directories where feasible, tightening egress rules to approved destinations, enforcing application allowlisting, and improving monitoring for new outbound beacons followed by file creation. +""" risk_score = 21 rule_id = "01c1e353-9d86-4344-abdf-523ab80c6f08" setup = """## Setup @@ -51,6 +82,7 @@ tags = [ "Tactic: Command and Control", "Tactic: Execution", "Data Source: Elastic Defend", + "Resources: Investigation Guide", ] type = "eql" query = ''' diff --git a/rules/linux/defense_evasion_lolbin_so_load.toml b/rules/linux/defense_evasion_lolbin_so_load.toml index 52d801df9ed..8f12e06ec81 100644 --- a/rules/linux/defense_evasion_lolbin_so_load.toml +++ b/rules/linux/defense_evasion_lolbin_so_load.toml @@ -2,7 +2,7 @@ creation_date = "2026/07/02" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/07/02" +updated_date = "2026/07/06" [rule] author = ["Elastic"] @@ -22,6 +22,37 @@ index = [ language = "eql" license = "Elastic License v2" name = "Shared Object Load via LoLBin" +note = """ ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Shared Object Load via LoLBin + +This alert flags a Linux program that normally is not used as a loader but is started with options that pull a shared object into memory, a common way to hide malicious code behind trusted tools. An attacker can launch `openssl -engine /tmp/libcrypto.so` or a short `python -c` snippet that calls `cdll.LoadLibrary("/tmp/libx.so")` to execute a rogue library while blending in with legitimate system activity. + +### Possible investigation steps + +- Review the full command line, ancestor process chain, session context, and executing user to determine whether the shared object load aligns with a legitimate admin task, build workflow, or expected plugin behavior. +- Identify the referenced `.so` file on disk and validate its package ownership, hash reputation, permissions, timestamps, and location, giving extra scrutiny to libraries in temporary, user-writable, hidden, or recently created paths. +- Pivot on the same library path or hash across hosts and users to determine whether it is isolated to one system, newly introduced, or part of a broader sequence involving script execution, file drops, or repeated LoLBin abuse. +- Examine activity immediately before and after the load for suspicious follow-on behavior such as outbound network connections, credential access attempts, unexpected child processes, privilege escalation, or persistence-related file changes. +- If the library is not attributable to approved software, collect the binary and related artifacts for static or sandbox analysis and consider host containment or blocking the file hash and path if corroborating malicious evidence is present. + +### False positive analysis + +- Developers or build jobs may use `python -c`, `ruby -e`, or `openssl -engine` to validate a locally built `.so` during compilation or testing; confirm the parent process and working directory map to an expected build path or `make`-driven workflow and that the library resides in a project or package-managed location. +- Administrators may intentionally load a legitimate shell builtin or application plugin through `bash -c`, `gdb`, or `vim` while troubleshooting or enabling features; verify the session is interactive and attributable to the user, then check that the referenced `.so` is package-owned or stored in a standard system library or plugin directory rather than a writable temporary path. + +### Response and remediation + +- Isolate the affected Linux host from the network, terminate the abusing LoLBin and any spawned processes, and quarantine the referenced `.so` and any copies found in writable locations such as `/tmp`, `/dev/shm`, user home directories, or hidden folders. +- Remove attacker persistence by deleting unauthorized entries from `/etc/ld.so.preload`, shell startup files, cron jobs, systemd services or timers, and any wrapper scripts that relaunch `openssl -engine`, `python -c`, `ruby -e`, or shell commands to load the malicious library. +- Reset credentials and revoke secrets used on the host, including SSH keys, API tokens, and service-account passwords, if the library executed under a privileged account or accessed authentication material, browser data, or configuration files with embedded secrets. +- Restore the host to a known-good state by rebuilding from a trusted image or reinstalling verified packages, then validate that no unapproved libraries, altered loader settings, or attacker-added binaries remain on disk before returning the system to production. +- Escalate to incident response immediately if the same library hash or path is present on multiple hosts, the load occurred as `root`, or the host showed follow-on behavior such as new persistence, remote command execution, or suspicious outbound network connections. +- Harden the environment by restricting plugin and engine loads to approved library directories, enforcing package integrity checks, monitoring for changes to preload files and service definitions, and applying SELinux or AppArmor policies that prevent scripts and LoLBins from loading shared objects from user-writable paths. +""" references = ["https://gtfobins.github.io/#+library%20load"] risk_score = 47 rule_id = "ebf493d1-20be-41a0-a010-c1b6a6f90e28" @@ -66,6 +97,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: SentinelOne", "Data Source: Crowdstrike", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/defense_evasion_proxy_execution_via_systemd_run.toml b/rules/linux/defense_evasion_proxy_execution_via_systemd_run.toml index 3b734333b49..cca649e9314 100644 --- a/rules/linux/defense_evasion_proxy_execution_via_systemd_run.toml +++ b/rules/linux/defense_evasion_proxy_execution_via_systemd_run.toml @@ -2,7 +2,7 @@ creation_date = "2026/07/02" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2026/07/02" +updated_date = "2026/07/06" [rule] author = ["Elastic"] @@ -23,6 +23,37 @@ index = [ language = "eql" license = "Elastic License v2" name = "Potential Proxy Execution via Systemd-run" +note = """ ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Potential Proxy Execution via Systemd-run + +This alert fires when a Linux process launches another command through systemd-run instead of executing it directly, which can hide execution behind a trusted system utility and detach it into a transient service or scope. An attacker might use systemd-run --user or a transient unit to start a shell, downloader, or credential-harvesting script in the background from an interactive session, reducing visibility into the real payload and parent-child chain. + +### Possible investigation steps + +- Reconstruct the full process tree around the event to determine which user, shell, script, service, or remote access session invoked systemd-run and whether the ancestry aligns with normal administrative or automation activity on that host. +- Review the exact command passed through systemd-run, including flags such as --user, --scope, scheduling options, or custom unit names, and classify the spawned payload as expected software management, benign interactive use, or suspicious shell, downloader, or persistence behavior. +- Query systemd and journal artifacts for the transient unit that was created, including unit properties, start time, execution account, service output, and whether the unit remained active, failed, or was configured to run again. +- Correlate the execution with nearby events from the same user or host such as logins, sudo activity, file creation in writable locations, outbound network connections, or follow-on launches of interpreters and admin tools to identify a broader intrusion sequence. +- If the activity is unauthorized or unclear, inspect the referenced binary or script for path reputation, package ownership, hash prevalence, and recent modification history, then stop the transient unit and contain any files or persistence it introduced. + +### False positive analysis + +- A legitimate administrator or maintenance script may use `systemd-run` to launch a transient unit for package updates, cache rebuilds, or controlled service restarts, so verify the initiating user, the parent script or shell history, and nearby package-management or scheduled change activity. +- A normal desktop or user session can invoke `systemd-run --user` or `--scope` to start an application, terminal, or session task in a transient scope, so confirm the parent process belongs to the logged-in user’s graphical session and that the spawned command matches expected interactive activity in systemd or journal logs. + +### Response and remediation + +- Isolate the affected Linux host from the network except for approved management channels, terminate the malicious `systemd-run` transient unit or scope, and kill any child shell, downloader, or script it launched. +- Remove attacker persistence by deleting unauthorized unit files and drop-ins from `/etc/systemd/system/`, `/run/systemd/transient/`, `/var/lib/systemd/`, and affected users’ `~/.config/systemd/user/` directories, then run `systemctl daemon-reload` and disable any malicious timers or services. +- Preserve and quarantine the executed payload, related scripts, and any files created from writable locations such as `/tmp`, `/var/tmp`, `/dev/shm`, or a user home directory, and revoke exposed access by resetting compromised passwords, SSH keys, tokens, and sudo access tied to the initiating account. +- Restore the system to a known-good state by reimaging or rebuilding the host from a trusted baseline if the command ran as `root`, modified security tooling, or executed an unknown binary, and validate that only approved packages, services, and startup entries remain before returning it to production. +- Escalate to incident response immediately if the `systemd-run` activity spawned a reverse shell, downloader, credential access tool, or lateral movement utility, if similar transient units appear on multiple hosts, or if the affected account has privileged or production access. +- Harden the environment by restricting who can invoke `systemd-run` through sudoers and privileged group membership, enforcing MFA and least privilege for administrative access, monitoring for new transient units and unexpected `--user` executions, and blocking execution from world-writable paths where the payload was staged. +""" risk_score = 21 rule_id = "a2e5e290-f534-4b71-bc3f-2dd1932b4cd6" setup = """## Setup @@ -66,6 +97,7 @@ tags = [ "Data Source: Auditd Manager", "Data Source: SentinelOne", "Data Source: Crowdstrike", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/discovery_curl_external_ip_discovery.toml b/rules/linux/discovery_curl_external_ip_discovery.toml index c4851e56702..a7cf208e71c 100644 --- a/rules/linux/discovery_curl_external_ip_discovery.toml +++ b/rules/linux/discovery_curl_external_ip_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2026/07/02" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/07/02" +updated_date = "2026/07/06" [rule] author = ["Elastic"] @@ -18,6 +18,37 @@ index = [ language = "eql" license = "Elastic License v2" name = "Linux External IP Address Discovery via Curl" +note = """ ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Linux External IP Address Discovery via Curl + +This rule flags a Linux process that uses curl to contact public IP lookup sites, a common way malware learns the host’s internet-facing address before choosing follow-on actions. An attacker who gains shell access on a server or container may run curl against services like ifconfig.me or ipify, then use the returned address to verify outbound reachability, tailor command-and-control, or decide whether the system sits behind cloud or NAT infrastructure. + +### Possible investigation steps + +- Trace the full process ancestry and nearby commands to determine whether the curl execution came from an interactive shell, scheduled task, deployment script, container entrypoint, or an unexpected program launched from a writable path. +- Review the invoked URL, arguments, working directory, and any captured output to determine whether the request was a one-off connectivity check or part of a broader script performing follow-on discovery, download, or beaconing. +- Correlate the activity with the initiating account, TTY/session details, recent SSH and sudo events, and change records to quickly separate approved administrator troubleshooting from suspicious post-compromise behavior. +- Pivot to surrounding network activity from the same host to identify repeated lookups, subsequent outbound connections to unfamiliar infrastructure, or signs of staging and command-and-control immediately after the public IP query. +- Inspect the parent script or binary on disk for recent creation or modification, unusual persistence mechanisms, and prevalence on peer systems to assess whether the behavior is tied to malware, a rogue change, or benign automation. + +### False positive analysis + +- Legitimate startup, login-banner, or scheduled maintenance scripts may use curl to learn the host’s public IP for configuration or status display, so verify the parent script or service path is expected, recently approved, and consistently seen at boot or on a routine schedule. +- An administrator or engineer may manually run curl to a public IP lookup site during troubleshooting or deployment validation, so confirm the initiating user, TTY or session context, and shell history align with authorized activity and that no suspicious follow-on commands occurred. + +### Response and remediation + +- Isolate the affected Linux host or container from the network immediately, allow only a secured management path, and preserve volatile evidence such as the running parent process, shell history, and the script or binary that launched curl. +- Terminate the malicious process chain and remove persistence by inspecting and cleaning cron jobs, systemd unit files, rc.local, user shell profiles, container entrypoints, SSH authorized_keys, and any attacker files staged in writable locations such as /tmp, /var/tmp, or /dev/shm. +- Rotate credentials and secrets exposed to the compromised system, including SSH keys, API tokens, cloud instance credentials, and application secrets found in scripts, environment files, or shell history. +- Restore the asset to a known-good state by rebuilding from a trusted image or clean backup and validating startup scripts, packages, and container images before returning the system to production. +- Escalate to incident response and broaden scoping across peer systems if the IP lookup was followed by downloads, reverse shells, new outbound connections to unfamiliar infrastructure, or if the same parent script, binary, or persistence artifact appears on multiple hosts. +- Harden the environment by restricting outbound curl access to approved destinations, blocking public IP lookup services where not needed, limiting execution from writable directories, and adding detections for unexpected systemd, cron, and shell-profile modifications. +""" risk_score = 21 rule_id = "996e2e09-087e-4e99-a3cc-a9225d24ba3d" setup = """## Setup @@ -54,6 +85,7 @@ tags = [ "Tactic: Discovery", "Data Source: Elastic Defend", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/execution_busybox_unusual_execution.toml b/rules/linux/execution_busybox_unusual_execution.toml index 7a0cacdff85..16432051960 100644 --- a/rules/linux/execution_busybox_unusual_execution.toml +++ b/rules/linux/execution_busybox_unusual_execution.toml @@ -2,7 +2,7 @@ creation_date = "2026/07/02" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2026/07/02" +updated_date = "2026/07/06" [rule] author = ["Elastic"] @@ -18,6 +18,37 @@ index = [ language = "eql" license = "Elastic License v2" name = "Suspicious Command Execution via Busybox Proxy" +note = """ ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Suspicious Command Execution via Busybox Proxy + +This rule flags Busybox being used as a proxy to launch shells or make outbound connections on Linux, a common way to hide command execution behind a trusted multi-call binary and slip past simple detections. An intruder can drop a script or binary in /tmp or /dev/shm, then run Busybox sh with /dev/tcp, nc, or openssl to establish a reverse shell and execute follow-on commands. + +### Possible investigation steps + +- Reconstruct the full execution chain around the Busybox invocation to identify the initiating script or binary, the user or service account involved, and whether the parent came from a writable or ephemeral location such as /tmp, /dev/shm, or a hidden working directory. +- Retrieve and analyze any files or command artifacts referenced in the invocation, including shell scripts, dropped binaries, or inline payloads, and compare their hashes and prevalence against internal baselines and external reputation sources. +- Review adjacent host activity for follow-on behavior consistent with staging or hands-on-keyboard access, such as additional shell launches, curl or wget downloads, permission changes, archive extraction, credential access attempts, or persistence creation via cron, systemd, or startup scripts. +- Pivot to network telemetry from the same host and time window to determine whether Busybox or its descendants established outbound sessions, then validate the destination IPs, domains, ports, and protocols against expected business use and known benign infrastructure. +- Confirm whether the behavior is expected for the asset type, container image, or embedded tooling in use, and if the activity is not readily explained, isolate the host and collect volatile evidence such as active connections, running processes, loaded modules, and recent shell history. + +### False positive analysis + +- Container or host startup scripts may invoke `busybox sh` with `nc`, `openssl`, or `/dev/tcp` from a temporary path to wait for a local dependency or perform a health check; verify the parent script is part of the expected image or boot workflow and that the destination is a known internal service. +- An administrator or automation task may stage a temporary script under `/tmp`, `/var/tmp`, or a user home directory that uses `busybox sh` to test port reachability or TLS negotiation during troubleshooting; confirm the initiating account and script contents against approved maintenance activity and check that no suspicious follow-on processes or outbound connections occurred. + +### Response and remediation + +- Isolate the affected Linux host from the network, terminate the malicious `busybox` process and any spawned shells, and block the destination IPs, domains, and ports used by the outbound session or reverse shell. +- Preserve copies of the parent script or binary from locations such as `/tmp`, `/var/tmp`, or `/dev/shm`, then remove attacker persistence including cron jobs, `systemd` service files, `rc.local` changes, startup scripts, and unauthorized `authorized_keys` entries tied to the same activity. +- Reset passwords, revoke tokens, and rotate SSH keys or application secrets for any user or service account that launched Busybox or was exposed on the host, especially when shell history, environment files, or config files contained credentials. +- Reimage the host or restore it from a known-good baseline, verify trusted package integrity for replaced binaries and scripts, and return the system to service only after confirming no unexpected executables remain in writable or temporary directories. +- Escalate to incident response immediately if the Busybox session ran as `root`, reached an external address, created persistence beyond a single host, or if other systems show the same dropped script, destination, or follow-on shell activity. +- Harden the environment by restricting Busybox execution to approved administrative use, mounting temporary directories with `noexec` where feasible, limiting unnecessary outbound egress, and adding detections for shell-capable Busybox usage launched from temporary, hidden, or user-writable paths. +""" risk_score = 21 rule_id = "7ed84571-58ac-46da-a0ab-9c213ef2927b" setup = """## Setup @@ -56,6 +87,7 @@ tags = [ "Tactic: Defense Evasion", "Data Source: Elastic Defend", "Data Source: SentinelOne", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" diff --git a/rules/linux/privilege_escalation_container_escape_via_kernel_core_pattern.toml b/rules/linux/privilege_escalation_container_escape_via_kernel_core_pattern.toml index b54bdbaed4b..fc86ef1bb64 100644 --- a/rules/linux/privilege_escalation_container_escape_via_kernel_core_pattern.toml +++ b/rules/linux/privilege_escalation_container_escape_via_kernel_core_pattern.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0" min_stack_version = "9.3.0" -updated_date = "2026/07/02" +updated_date = "2026/07/06" [rule] author = ["Elastic"] @@ -28,6 +28,37 @@ index = [ language = "eql" license = "Elastic License v2" name = "Potential Container Escape via Kernel core_pattern Modification" +note = """ ## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Potential Container Escape via Kernel core_pattern Modification + +This rule detects attempts on Linux to change the kernel’s core dump handler, a setting that can make the host run a program as root when a process crashes. In a container, an attacker can write a pipe-based core_pattern such as a shell script path, then deliberately crash a process so the host executes the handler outside the container, turning container access into full host compromise. + +### Possible investigation steps + +- Verify the current and recent value of `kernel.core_pattern` on the affected node, prioritizing pipe-based handlers and whether the referenced program lives in a writable, temporary, container-mounted, or otherwise untrusted path. +- Reconstruct the full ancestry and session context of the modifying process to determine whether it came from a legitimate admin workflow or from a containerized shell, and identify the associated user, container, image, pod, and privilege level. +- Review the container or pod security context for escape-enabling conditions such as privileged mode, shared host namespaces, hostPath mounts to `/proc` or the host filesystem, and elevated capabilities that would have allowed changing a host kernel parameter. +- Hunt for follow-on exploitation by looking for deliberate crashes, core-dump activity, and new root-owned host processes launched shortly after the change, especially executions from `/tmp`, container overlay paths, or bind-mounted locations. +- If the activity is not authorized, collect the referenced handler file and related artifacts, assess the host for persistence or lateral movement, and contain the node and implicated workload before restoring `kernel.core_pattern` to a known-good value. + +### False positive analysis + +- An administrator or approved automation may temporarily change `kernel.core_pattern` from a host shell or privileged container during crash-dump troubleshooting; verify the initiating user and parent process, look for a corresponding maintenance window or change record, and confirm the setting was restored to an approved value afterward. +- A legitimate test or debugging workflow may use `sysctl`, shell redirection, or file-copy utilities to point `core_pattern` to a known crash handler before generating controlled faults; confirm the activity is tied to an expected container or host session, the handler path is trusted, and no unexpected root-owned host processes were launched after the change. + +### Response and remediation + +- Isolate the affected host from the network, cordon and drain the Kubernetes node if applicable, and stop or quarantine the implicated container or pod so the attacker cannot trigger additional core dumps or spawn new host processes. +- Preserve the malicious artifacts for incident handling and then remove the attacker-controlled core dump handler, including any scripts or binaries referenced by `/proc/sys/kernel/core_pattern` and copies placed in `/tmp`, `/var/tmp`, container overlay paths, bind mounts, or other writable locations. +- Restore the node to a known-good state by resetting `kernel.core_pattern` to the approved value, removing unauthorized entries from `/etc/sysctl.conf`, `/etc/sysctl.d/`, and startup scripts that would reapply it, and rebuilding the host from a trusted image if host-level execution occurred. +- Hunt for and remove persistence added after the escape attempt, including rogue systemd units, cron jobs, `/etc/rc.local` changes, SSH `authorized_keys`, newly created sudoers entries, and unauthorized privileged DaemonSets or containers on the node. +- Escalate immediately to incident response if the handler executed on the host, if you find root-owned processes launched from a container-writable path such as `/tmp` or an overlay mount, or if the same `core_pattern` change appears on more than one node. +- Rotate any credentials or tokens exposed on the host or mounted into the compromised workload, then harden the environment by blocking privileged pods, removing dangerous capabilities such as `CAP_SYS_ADMIN`, prohibiting writable `hostPath` access to `/proc` or the host filesystem, and enforcing pod security or admission policies to prevent recurrence. +""" references = [ "https://www.sysdig.com/blog/runc-container-escape-vulnerabilities", "https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm", @@ -73,6 +104,7 @@ tags = [ "Data Source: Crowdstrike", "Data Source: SentinelOne", "Data Source: Elastic Defend for Containers", + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql"