diff --git a/.github/workflows/lock-versions.yml b/.github/workflows/lock-versions.yml index 2f472c5ce6a..c02f560fa9a 100644 --- a/.github/workflows/lock-versions.yml +++ b/.github/workflows/lock-versions.yml @@ -6,7 +6,7 @@ on: description: 'List of branches to lock versions (ordered, comma separated)' required: true # 7.17 was intentionally skipped because it was added late and was bug fix only - default: '8.12,8.13,8.14,8.15,8.16,8.17' + default: '8.13,8.14,8.15,8.16,8.17,8.18' jobs: pr: diff --git a/detection_rules/etc/api_schemas/8.18/8.18.base.json b/detection_rules/etc/api_schemas/8.18/8.18.base.json new file mode 100644 index 00000000000..23138b13640 --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.base.json @@ -0,0 +1,412 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "query", + "saved_query", + "machine_learning", + "eql", + "esql", + "threshold", + "threat_match", + "new_terms" + ], + "enumNames": [], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "name", + "risk_score", + "rule_id", + "severity", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.eql.json b/detection_rules/etc/api_schemas/8.18/8.18.eql.json new file mode 100644 index 00000000000..30f489eed55 --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.eql.json @@ -0,0 +1,490 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + }, + "group_by": { + "description": "AlertSuppressionGroupBy", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + "missing_fields_strategy": { + "description": "AlertSuppressionMissing", + "enum": [ + "suppress", + "doNotSuppress" + ], + "enumNames": [], + "type": "string" + } + }, + "required": [ + "group_by", + "missing_fields_strategy" + ], + "type": "object" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "data_view_id": { + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "event_category_override": { + "min_compat": "8.0", + "type": "string" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "language": { + "enum": [ + "eql" + ], + "type": "string" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "query": { + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "throttle": { + "type": "string" + }, + "tiebreaker_field": { + "min_compat": "8.0", + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_field": { + "min_compat": "8.0", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "eql" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "language", + "name", + "query", + "risk_score", + "rule_id", + "severity", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.esql.json b/detection_rules/etc/api_schemas/8.18/8.18.esql.json new file mode 100644 index 00000000000..b3e42f35b45 --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.esql.json @@ -0,0 +1,478 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + }, + "group_by": { + "description": "AlertSuppressionGroupBy", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + "missing_fields_strategy": { + "description": "AlertSuppressionMissing", + "enum": [ + "suppress", + "doNotSuppress" + ], + "enumNames": [], + "type": "string" + } + }, + "required": [ + "group_by", + "missing_fields_strategy" + ], + "type": "object" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "data_view_id": { + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "language": { + "enum": [ + "esql" + ], + "type": "string" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "query": { + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "esql" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "language", + "name", + "query", + "risk_score", + "rule_id", + "severity", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.machine_learning.json b/detection_rules/etc/api_schemas/8.18/8.18.machine_learning.json new file mode 100644 index 00000000000..7b1b42c2223 --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.machine_learning.json @@ -0,0 +1,476 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + }, + "group_by": { + "description": "AlertSuppressionGroupBy", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + "missing_fields_strategy": { + "description": "AlertSuppressionMissing", + "enum": [ + "suppress", + "doNotSuppress" + ], + "enumNames": [], + "type": "string" + } + }, + "required": [ + "group_by", + "missing_fields_strategy" + ], + "type": "object" + }, + "anomaly_threshold": { + "type": "integer" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "license": { + "type": "string" + }, + "machine_learning_job_id": { + "anyOf": [ + { + "type": "string" + }, + { + "items": { + "type": "string" + }, + "type": "array" + } + ] + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "machine_learning" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "anomaly_threshold", + "author", + "description", + "machine_learning_job_id", + "name", + "risk_score", + "rule_id", + "severity", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.new_terms.json b/detection_rules/etc/api_schemas/8.18/8.18.new_terms.json new file mode 100644 index 00000000000..c0d7d437f87 --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.new_terms.json @@ -0,0 +1,533 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + }, + "group_by": { + "description": "AlertSuppressionGroupBy", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + "missing_fields_strategy": { + "description": "AlertSuppressionMissing", + "enum": [ + "suppress", + "doNotSuppress" + ], + "enumNames": [], + "type": "string" + } + }, + "required": [ + "group_by", + "missing_fields_strategy" + ], + "type": "object" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "data_view_id": { + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "language": { + "enum": [ + "eql", + "esql", + "kuery", + "lucene" + ], + "enumNames": [], + "type": "string" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "new_terms": { + "additionalProperties": false, + "properties": { + "field": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "history_window_start": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "value": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "field", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "value": { + "description": "NewTermsFields", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "field", + "history_window_start", + "value" + ], + "type": "object" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "query": { + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "new_terms" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "language", + "name", + "new_terms", + "query", + "risk_score", + "rule_id", + "severity", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.query.json b/detection_rules/etc/api_schemas/8.18/8.18.query.json new file mode 100644 index 00000000000..408c8bbb9dd --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.query.json @@ -0,0 +1,482 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + }, + "group_by": { + "description": "AlertSuppressionGroupBy", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + "missing_fields_strategy": { + "description": "AlertSuppressionMissing", + "enum": [ + "suppress", + "doNotSuppress" + ], + "enumNames": [], + "type": "string" + } + }, + "required": [ + "group_by", + "missing_fields_strategy" + ], + "type": "object" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "data_view_id": { + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "language": { + "enum": [ + "eql", + "esql", + "kuery", + "lucene" + ], + "enumNames": [], + "type": "string" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "query": { + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "query" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "language", + "name", + "query", + "risk_score", + "rule_id", + "severity", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.threat_match.json b/detection_rules/etc/api_schemas/8.18/8.18.threat_match.json new file mode 100644 index 00000000000..f10aa0d859e --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.threat_match.json @@ -0,0 +1,573 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + }, + "group_by": { + "description": "AlertSuppressionGroupBy", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "minItems": 1, + "type": "array" + }, + "missing_fields_strategy": { + "description": "AlertSuppressionMissing", + "enum": [ + "suppress", + "doNotSuppress" + ], + "enumNames": [], + "type": "string" + } + }, + "required": [ + "group_by", + "missing_fields_strategy" + ], + "type": "object" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "concurrent_searches": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + }, + "data_view_id": { + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "items_per_search": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + }, + "language": { + "enum": [ + "eql", + "esql", + "kuery", + "lucene" + ], + "enumNames": [], + "type": "string" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "query": { + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "threat_filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "threat_index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat_indicator_path": { + "type": "string" + }, + "threat_language": { + "enum": [ + "eql", + "esql", + "kuery", + "lucene" + ], + "enumNames": [], + "type": "string" + }, + "threat_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "entries": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "enum": [ + "mapping" + ], + "type": "string" + }, + "value": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "field", + "type", + "value" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "entries" + ], + "type": "object" + }, + "type": "array" + }, + "threat_query": { + "type": "string" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "threat_match" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "language", + "name", + "query", + "risk_score", + "rule_id", + "severity", + "threat_index", + "threat_mapping", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/api_schemas/8.18/8.18.threshold.json b/detection_rules/etc/api_schemas/8.18/8.18.threshold.json new file mode 100644 index 00000000000..58469621412 --- /dev/null +++ b/detection_rules/etc/api_schemas/8.18/8.18.threshold.json @@ -0,0 +1,508 @@ +{ + "$schema": "http://json-schema.org/draft-04/schema#", + "additionalProperties": false, + "properties": { + "actions": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "alert_suppression": { + "additionalProperties": false, + "properties": { + "duration": { + "additionalProperties": false, + "properties": { + "unit": { + "enum": [ + "s", + "m", + "h" + ], + "enumNames": [], + "type": "string" + }, + "value": { + "description": "AlertSupressionValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "unit", + "value" + ], + "type": "object" + } + }, + "required": [ + "duration" + ], + "type": "object" + }, + "author": { + "items": { + "type": "string" + }, + "type": "array" + }, + "building_block_type": { + "enum": [ + "default" + ], + "type": "string" + }, + "data_view_id": { + "type": "string" + }, + "description": { + "type": "string" + }, + "enabled": { + "type": "boolean" + }, + "exceptions_list": { + "items": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "array" + }, + "false_positives": { + "items": { + "type": "string" + }, + "type": "array" + }, + "filters": { + "items": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "type": "array" + }, + "from": { + "type": "string" + }, + "index": { + "items": { + "type": "string" + }, + "type": "array" + }, + "interval": { + "description": "Interval", + "pattern": "^\\d+[mshd]$", + "type": "string" + }, + "investigation_fields": { + "additionalProperties": false, + "properties": { + "field_names": { + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "field_names" + ], + "type": "object" + }, + "language": { + "enum": [ + "eql", + "esql", + "kuery", + "lucene" + ], + "enumNames": [], + "type": "string" + }, + "license": { + "type": "string" + }, + "max_signals": { + "description": "MaxSignals", + "minimum": 1, + "type": "integer" + }, + "meta": { + "additionalProperties": { + "type": [ + "string", + "number", + "object", + "array", + "boolean" + ] + }, + "type": "object" + }, + "name": { + "description": "RuleName", + "type": "string" + }, + "note": { + "description": "MarkdownField", + "type": "string" + }, + "query": { + "type": "string" + }, + "references": { + "items": { + "type": "string" + }, + "type": "array" + }, + "related_integrations": { + "items": { + "additionalProperties": false, + "properties": { + "integration": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "package": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "version": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "package", + "version" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "required_fields": { + "items": { + "additionalProperties": false, + "properties": { + "ecs": { + "type": "boolean" + }, + "name": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "type": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + } + }, + "required": [ + "ecs", + "name", + "type" + ], + "type": "object" + }, + "min_compat": "8.3", + "type": "array" + }, + "revision": { + "min_compat": "8.8", + "type": "integer" + }, + "risk_score": { + "description": "MaxSignals", + "maximum": 100, + "minimum": 1, + "type": "integer" + }, + "risk_score_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "rule_id": { + "description": "UUIDString", + "pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$", + "type": "string" + }, + "rule_name_override": { + "type": "string" + }, + "setup": { + "description": "MarkdownField", + "min_compat": "8.3", + "type": "string" + }, + "severity": { + "enum": [ + "low", + "medium", + "high", + "critical" + ], + "enumNames": [], + "type": "string" + }, + "severity_mapping": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "operator": { + "enum": [ + "equals" + ], + "type": "string" + }, + "severity": { + "type": "string" + }, + "value": { + "type": "string" + } + }, + "required": [ + "field" + ], + "type": "object" + }, + "type": "array" + }, + "tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "threat": { + "items": { + "additionalProperties": false, + "properties": { + "framework": { + "enum": [ + "MITRE ATT&CK" + ], + "type": "string" + }, + "tactic": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TacticURL", + "pattern": "^https://attack.mitre.org/tactics/TA[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "technique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "TechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/$", + "type": "string" + }, + "subtechnique": { + "items": { + "additionalProperties": false, + "properties": { + "id": { + "type": "string" + }, + "name": { + "type": "string" + }, + "reference": { + "description": "SubTechniqueURL", + "pattern": "^https://attack.mitre.org/techniques/T[0-9]+/[0-9]+/$", + "type": "string" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "id", + "name", + "reference" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "framework", + "tactic" + ], + "type": "object" + }, + "type": "array" + }, + "threshold": { + "additionalProperties": false, + "properties": { + "cardinality": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "value": { + "description": "ThresholdValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "field", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "field": { + "description": "CardinalityFields", + "items": { + "description": "NonEmptyStr", + "minLength": 1, + "type": "string" + }, + "maxItems": 3, + "type": "array" + }, + "value": { + "description": "ThresholdValue", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "field", + "value" + ], + "type": "object" + }, + "throttle": { + "type": "string" + }, + "timeline_id": { + "description": "TimelineTemplateId", + "type": "string" + }, + "timeline_title": { + "description": "TimelineTemplateTitle", + "type": "string" + }, + "timestamp_override": { + "type": "string" + }, + "to": { + "type": "string" + }, + "type": { + "enum": [ + "threshold" + ], + "type": "string" + }, + "version": { + "description": "PositiveInteger", + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "author", + "description", + "language", + "name", + "query", + "risk_score", + "rule_id", + "severity", + "threshold", + "type" + ], + "type": "object" +} \ No newline at end of file diff --git a/detection_rules/etc/beats_schemas/main.json.gz b/detection_rules/etc/beats_schemas/main.json.gz index 153ad622d90..8113ae49e7d 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.0.0-beta1.json.gz b/detection_rules/etc/beats_schemas/v9.0.0-beta1.json.gz new file mode 100644 index 00000000000..67d74043fab Binary files /dev/null and b/detection_rules/etc/beats_schemas/v9.0.0-beta1.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.10.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/1.10.0/ecs_flat.json.gz index 0fac25c807b..b1debf2986e 100644 Binary files a/detection_rules/etc/ecs_schemas/1.10.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/1.10.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.10.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/1.10.0/ecs_nested.json.gz index e4f729907d1..7cc61d2ff24 100644 Binary files a/detection_rules/etc/ecs_schemas/1.10.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/1.10.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.11.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/1.11.0/ecs_flat.json.gz index 291900511ac..112dc50a3b5 100644 Binary files a/detection_rules/etc/ecs_schemas/1.11.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/1.11.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.11.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/1.11.0/ecs_nested.json.gz index d5e001596ff..2a5f6db2b97 100644 Binary files a/detection_rules/etc/ecs_schemas/1.11.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/1.11.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.12.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/1.12.0/ecs_flat.json.gz index 2dcc966716d..c74a7ec3c50 100644 Binary files a/detection_rules/etc/ecs_schemas/1.12.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/1.12.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.12.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/1.12.0/ecs_nested.json.gz index a60a125e20d..df4159cdd2c 100644 Binary files a/detection_rules/etc/ecs_schemas/1.12.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/1.12.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.12.1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/1.12.1/ecs_flat.json.gz index 5408e1c30c8..9df569a99ba 100644 Binary files a/detection_rules/etc/ecs_schemas/1.12.1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/1.12.1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.12.1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/1.12.1/ecs_nested.json.gz index c6c03bd074c..cc9db3ad937 100644 Binary files a/detection_rules/etc/ecs_schemas/1.12.1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/1.12.1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.12.2/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/1.12.2/ecs_flat.json.gz index 9aafe1ab2ae..6985f13c846 100644 Binary files a/detection_rules/etc/ecs_schemas/1.12.2/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/1.12.2/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/1.12.2/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/1.12.2/ecs_nested.json.gz index af7f77ba444..f3640a9f156 100644 Binary files a/detection_rules/etc/ecs_schemas/1.12.2/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/1.12.2/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.0.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.0.0/ecs_flat.json.gz index a24bbf0c4b4..4ec16782936 100644 Binary files a/detection_rules/etc/ecs_schemas/8.0.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.0.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.0.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.0.0/ecs_nested.json.gz index 90f687aa8e2..fc47f2252ea 100644 Binary files a/detection_rules/etc/ecs_schemas/8.0.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.0.0/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.0.1/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.0.1/ecs_flat.json.gz index b26730fa239..33f47f3898c 100644 Binary files a/detection_rules/etc/ecs_schemas/8.0.1/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.0.1/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.0.1/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.0.1/ecs_nested.json.gz index be771063d6d..b12191c5a75 100644 Binary files a/detection_rules/etc/ecs_schemas/8.0.1/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.0.1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.1.0/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/8.1.0/ecs_flat.json.gz index f33919b87af..6cdb906fd0b 100644 Binary files a/detection_rules/etc/ecs_schemas/8.1.0/ecs_flat.json.gz and b/detection_rules/etc/ecs_schemas/8.1.0/ecs_flat.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/8.1.0/ecs_nested.json.gz b/detection_rules/etc/ecs_schemas/8.1.0/ecs_nested.json.gz index e1b54ce824d..feabc7383f5 100644 Binary files a/detection_rules/etc/ecs_schemas/8.1.0/ecs_nested.json.gz and b/detection_rules/etc/ecs_schemas/8.1.0/ecs_nested.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 175ece06abc..22063834bf8 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 674067433f9..e61edfa2c25 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 45daaf55a72..b626429f186 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 51febb7afee..cd9730ef105 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 303331297ae..3b87f5edf98 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 4ac255b4097..95adfb78d69 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 aa64cb43440..02d3c71bc3a 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 033fb104e74..9d104f3ae9e 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 4dd71dd3b4e..d4c89804cc0 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 c635df73f52..e393907d845 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 87de001179e..c9b9575d1e2 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 f1856dca63d..3aeb7b5793d 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 8a68f15eaac..1ed55b9d3ed 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 2d640b23a96..97c51daff8a 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 5c0b6c385be..72e5a9c2ff1 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 0d27552154d..4a562b1aead 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 c027f24930f..30457da4c4f 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 e01cf600b49..461024cc34c 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 d07512ea8af..31c2cb74364 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 3f44b5f1390..88a248a9895 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 b12705f32f3..5d37050c954 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 967994501d6..0eb0ae8319a 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 82c56b53964..5c594b449a1 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 c130dfe2cc6..76b23916bd4 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 bb2f0df7a16..9350a574307 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 a6ca7b4097d..0decb7b7bb8 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 9d047ac108f..235703e4d50 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 5534a7b6468..099c6bfdff5 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 c4c254875b6..3499755a9d7 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 8f51271b11a..6647e142815 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 b81159c1cb6..f429412d744 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 ff5415e8e18..5c307f7848b 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 d0b5374feb0..634c97709be 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 5ca1100cb4a..8927220fe1d 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 af36bcd63bb..b271414ff4e 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 ebb1adff0f4..6c010231f24 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 757bbb84a27..d2e8da922c5 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 e8dea1501ad..ac262534317 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 cedfec56a63..17a3c1ce8bb 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 8f6d0c5cd05..b71823784ed 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 91663576453..26f93a77493 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 d85d2193d76..869807302b7 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 new file mode 100644 index 00000000000..24195864081 Binary files /dev/null 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 new file mode 100644 index 00000000000..9e7da101a54 Binary files /dev/null and b/detection_rules/etc/ecs_schemas/9.0.0-rc1/ecs_nested.json.gz differ diff --git a/detection_rules/etc/ecs_schemas/master_9.0.0-dev/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/master_9.0.0-dev/ecs_flat.json.gz deleted file mode 100644 index 98b02206359..00000000000 Binary files a/detection_rules/etc/ecs_schemas/master_9.0.0-dev/ecs_flat.json.gz and /dev/null differ diff --git a/detection_rules/etc/ecs_schemas/master_9.1.0-dev/ecs_flat.json.gz b/detection_rules/etc/ecs_schemas/master_9.1.0-dev/ecs_flat.json.gz new file mode 100644 index 00000000000..d4a3739217b Binary files /dev/null and b/detection_rules/etc/ecs_schemas/master_9.1.0-dev/ecs_flat.json.gz differ diff --git a/detection_rules/etc/integration-manifests.json.gz b/detection_rules/etc/integration-manifests.json.gz index df76b3ea8a3..dd75165f85a 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 561bf356dde..1c6db5e9bd0 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/packages.yaml b/detection_rules/etc/packages.yaml index a72de41bf9a..80600b38c17 100644 --- a/detection_rules/etc/packages.yaml +++ b/detection_rules/etc/packages.yaml @@ -3,7 +3,7 @@ package: maturity: - production log_deprecated: true - name: '8.18' + name: '9.0' registry_data: categories: - security @@ -12,7 +12,7 @@ package: capabilities: - security subscription: basic - kibana.version: ^8.18.0 + kibana.version: ^9.0.0 description: Prebuilt detection rules for Elastic Security format_version: 3.0.0 icons: @@ -27,5 +27,5 @@ package: license: Elastic-2.0 title: Prebuilt Security Detection Rules type: integration - version: 8.18.0-beta.1 + version: 9.0.0-beta.1 release: true diff --git a/detection_rules/etc/stack-schema-map.yaml b/detection_rules/etc/stack-schema-map.yaml index 40d90e1c361..50b2d41c86b 100644 --- a/detection_rules/etc/stack-schema-map.yaml +++ b/detection_rules/etc/stack-schema-map.yaml @@ -87,12 +87,12 @@ # ecs: "8.11.0" # endgame: "8.4.0" -## Supported +# "8.12.0": +# beats: "8.12.2" +# ecs: "8.11.0" +# endgame: "8.4.0" -"8.12.0": - beats: "8.12.2" - ecs: "8.11.0" - endgame: "8.4.0" +## Supported "8.13.0": beats: "8.13.4" @@ -122,4 +122,9 @@ "8.18.0": beats: "8.17.1" ecs: "8.17.0" + endgame: "8.4.0" + +"9.0.0": + beats: "9.0.0-beta1" + ecs: "9.0.0-rc1" endgame: "8.4.0" \ No newline at end of file diff --git a/detection_rules/etc/version.lock.json b/detection_rules/etc/version.lock.json index aedc3c1153f..cc8eaa11c4a 100644 --- a/detection_rules/etc/version.lock.json +++ b/detection_rules/etc/version.lock.json @@ -2,7 +2,7 @@ "000047bb-b27a-47ec-8b62-ef1a5d2c9e19": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 309, "rule_name": "Attempt to Modify an Okta Policy Rule", "sha256": "61224002fe2acb034c68f8a1ce071b7b5373f3cce6e3134e155cd51017a68e99", @@ -25,19 +25,12 @@ "00140285-b827-4aee-aa09-8113f58a08f3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Potential Credential Access via Windows Utilities", "sha256": "8cd037720adc468e6c21ea2add4914a716d1fa7f3ffb7542a3196bf05c40a420", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "Potential Credential Access via Windows Utilities", - "sha256": "148b877fd8c02c9338683afb02175ecd6f5cae155844fb6eb12205e1a4bfaf4b", - "type": "eql", - "version": 216 } }, "rule_name": "Potential Credential Access via Windows Utilities", @@ -48,19 +41,12 @@ "0022d47d-39c7-4f69-a232-4fe9dc7a3acd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "System Shells via Services", "sha256": "94047c055fb327e889a977deaf20ab8494f8d7c817d09a9039eecead9f00ec21", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 413, - "rule_name": "System Shells via Services", - "sha256": "2b030c8d49b750ea50e794ec65195cccb5c668d04a6eb1c0e9f00bd274fe1289", - "type": "eql", - "version": 316 } }, "rule_name": "System Shells via Services", @@ -112,16 +98,6 @@ "version": 3 }, "01c49712-25bc-49d2-a27d-d7ce52f5dc49": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of GitHub User Interaction with Private Repo", - "sha256": "adb33991bc7e05efa461ee20ccaa7ac960c540154ae482921c711a1e850b06cf", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of GitHub User Interaction with Private Repo", "sha256": "095c16605c5fbf8541e9458048d6b266d1019f1daa27e2292b8c6882a0595e28", "type": "new_terms", @@ -130,7 +106,7 @@ "027ff9ea-85e7-42e3-99d2-bbb7069e02eb": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Potential Cookies Theft via Browser Debugging", "sha256": "810907d90a27aee361c0e4bdf4d0bfe79e58e47c2b9f7a8df4b14ad750f1aa8a", @@ -144,16 +120,6 @@ "version": 209 }, "0294f105-d7af-4a02-ae90-35f56763ffa2": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of GitHub Repo Interaction From a New IP", - "sha256": "5c428cb19c48c4a48a019d8275c5361269f5caba6736aec0a5304d2790f5789c", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of GitHub Repo Interaction From a New IP", "sha256": "3510266d54dc4cce4d79160e2fcdff9c2750cc8c0fe8b7f1e54b255096f8916e", "type": "new_terms", @@ -168,7 +134,7 @@ "02a4576a-7480-4284-9327-548a806b5e48": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Potential Credential Access via DuplicateHandle in LSASS", "sha256": "376189f0989a9c834ea9e807f1c31236301e528eec227aa389419a7e53aeabf0", @@ -202,7 +168,7 @@ "035889c4-2686-4583-a7df-67f89c292f2c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "High Number of Process and/or Service Terminations", "sha256": "4c5ca4a33be28031ab32a084760e988f017a7edd84cc8c08f314f52d3873cb50", @@ -222,16 +188,6 @@ "version": 3 }, "0369e8a6-0fa7-4e7a-961a-53180a4c966e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Suspicious Dynamic Linker Discovery via od", - "sha256": "63da0c176cc07352e9a1cb9d92ededc8900ca1b1c6f6dfa5b1d8af6e158f55fa", - "type": "eql", - "version": 3 - } - }, "rule_name": "Suspicious Dynamic Linker Discovery via od", "sha256": "bd5bbad719e965a90859b0a4bdedba465855590236e80fa2f05be1b1943c969e", "type": "eql", @@ -270,19 +226,12 @@ "043d80a3-c49e-43ef-9c72-1088f0c7b278": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Potential Escalation via Vulnerable MSI Repair", "sha256": "47373227a503f5fe1fde96d536e6a205fcac83b971b0dee087b3614cd96c814f", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Potential Escalation via Vulnerable MSI Repair", - "sha256": "8d179fe06605d1b9a62c3cda5f232e20d6e98172b8c62bc1ac5e3c362f0caf83", - "type": "eql", - "version": 103 } }, "rule_name": "Potential Escalation via Vulnerable MSI Repair", @@ -305,7 +254,7 @@ "053a0387-f3b5-4ba5-8245-8002cca2bd08": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Potential DLL Side-Loading via Microsoft Antimalware Service Executable", "sha256": "1ca8fdf09317fd36c70df03f3201b8274dda82e84f259811b7e392d1b5d8e6b4", @@ -327,7 +276,7 @@ "0564fb9d-90b9-4234-a411-82a546dc1343": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Microsoft IIS Service Account Password Dumped", "sha256": "05e330c5bc7ed2ce8eebca407e464236f706e834abd2347c5e29222915cb9919", @@ -343,19 +292,12 @@ "05b358de-aa6d-4f6c-89e6-78f74018b43b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Conhost Spawned By Suspicious Parent Process", "sha256": "0437ed81150e42654cb33e6ad318152edb266126d44225341bc12cc678bc578e", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Conhost Spawned By Suspicious Parent Process", - "sha256": "ccb2ff57c3244f25002537f1dc77486f9eafdcdbd670e3f6c41a50749f80121d", - "type": "eql", - "version": 210 } }, "rule_name": "Conhost Spawned By Suspicious Parent Process", @@ -378,7 +320,7 @@ "0635c542-1b96-4335-9b47-126582d2c19a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Remote System Discovery Commands", "sha256": "b86728d65216af8f9dfa8912908f8a4225fdff95bd52dd63c2483d7bdd8385b4", @@ -394,7 +336,7 @@ "06568a02-af29-4f20-929c-f3af281e41aa": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "System Time Discovery", "sha256": "33fe7970c008c5046403b819e98a65e6552a9579cc28562fe551e9ec75fcf0ef", @@ -416,19 +358,12 @@ "06a7a03c-c735-47a6-a313-51c354aef6c3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Enumerating Domain Trusts via DSQUERY.EXE", "sha256": "d70040688d2d40faca05dc65ea89f7b7cb6dc34b2c978f2fc33e67f843a5c79f", "type": "eql", "version": 10 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "Enumerating Domain Trusts via DSQUERY.EXE", - "sha256": "bff4aae78a241e310a292c793fba005814a975476eba89387b3301217986255b", - "type": "eql", - "version": 110 } }, "rule_name": "Enumerating Domain Trusts via DSQUERY.EXE", @@ -437,16 +372,6 @@ "version": 211 }, "06d555e4-c8ce-4d90-90e1-ec7f66df5a6a": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Dynamic Linker (ld.so) Creation", - "sha256": "798d7634945767913aeab178e7df25c3696ac6e993cbaaaefe8030ea91fe0f4c", - "type": "eql", - "version": 2 - } - }, "rule_name": "Dynamic Linker (ld.so) Creation", "sha256": "cf3d305ea89fd7b2c84f8ed412f55d0c5180e021f2d107a517d501e85c15e038", "type": "eql", @@ -455,7 +380,7 @@ "06dceabf-adca-48af-ac79-ffdf4c3b1e9a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Potential Evasion via Filter Manager", "sha256": "af64a92d30ef699c25bf08f37822770635ec2e44be940f17de9cf25ba519f602", @@ -478,19 +403,12 @@ "074464f9-f30d-4029-8c03-0ed237fffec7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Remote Desktop Enabled in Windows Firewall by Netsh", "sha256": "9f32696b9fa2e1510dd9d329776fa82b31d56c88665b21f900724188a3fb1f33", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Remote Desktop Enabled in Windows Firewall by Netsh", - "sha256": "b22d6b7ab9817cd0a492a0bb23fa58aefc0460b88dea57ffc84c6cda058950b9", - "type": "eql", - "version": 212 } }, "rule_name": "Remote Desktop Enabled in Windows Firewall by Netsh", @@ -499,16 +417,6 @@ "version": 313 }, "07639887-da3a-4fbf-9532-8ce748ff8c50": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 205, - "rule_name": "GitHub Protected Branch Settings Changed", - "sha256": "380c523049b8404ce0d831d93a39d8d6e334c2a51c94e3454920aa9b947d0d60", - "type": "eql", - "version": 107 - } - }, "rule_name": "GitHub Protected Branch Settings Changed", "sha256": "3d9549ea279015b77bc82b2e69b630d2013529cbc37e51d1316381f1c8f34d54", "type": "eql", @@ -523,19 +431,12 @@ "07b1ef73-1fde-4a49-a34a-5dd40011b076": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Local Account TokenFilter Policy Disabled", "sha256": "09c2f36752a76180ee5f6c3d999fca9b4a594baf1e68da518828098d4a918b29", "type": "eql", "version": 10 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Local Account TokenFilter Policy Disabled", - "sha256": "7a1e221305122e11869857dfef01583fa3242e9353bbc3c58bd029ddc08ce349", - "type": "eql", - "version": 213 } }, "rule_name": "Local Account TokenFilter Policy Disabled", @@ -570,19 +471,12 @@ "0859355c-0f08-4b43-8ff5-7d2a4789fc08": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "First Time Seen Removable Device", "sha256": "f1ac8cf1be60a96de758a01dfbfd0a5b594450e5a38ceae29fc315267402c892", "type": "new_terms", "version": 10 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "First Time Seen Removable Device", - "sha256": "c14fec5bc1b916855cac0929b535c0865ae08136bf417b3ef52374ed88a27cc5", - "type": "new_terms", - "version": 110 } }, "rule_name": "First Time Seen Removable Device", @@ -615,16 +509,6 @@ "version": 111 }, "095b6a58-8f88-4b59-827c-ab584ad4e759": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "Member Removed From GitHub Organization", - "sha256": "425013c02e030ebacc0fd4c5249f59222b5afe82c2e8f03b6a1cc1139bdf917a", - "type": "eql", - "version": 104 - } - }, "rule_name": "Member Removed From GitHub Organization", "sha256": "2c13e8235f2ccb01b6e8191742db632dd78914afd8d4305a6445d06b907d6bf7", "type": "eql", @@ -663,7 +547,7 @@ "0abf0c5b-62dd-48d2-ac4e-6b43fe3a6e83": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "PowerShell Script with Remote Execution Capabilities via WinRM", "sha256": "c9e9c7d9aeb625a2ff827174aa3e775a8396562727ff6250c64dbc0a9e2fe28e", @@ -685,7 +569,7 @@ "0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Anomalous Windows Process Creation", "sha256": "e58901307b82a6b703f7a5b2767769ca7cbec1c80db040954fe646835f35d714", @@ -701,7 +585,7 @@ "0b2f3da5-b5ec-47d1-908b-6ebb74814289": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "User account exposed to Kerberoasting", "sha256": "f4161c7c3cb1aa92b083eb597fae4114d218aee981cb01a13851e639a4dea970", @@ -727,16 +611,6 @@ "version": 2 }, "0b803267-74c5-444d-ae29-32b5db2d562a": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 105, - "rule_name": "Potential Shell via Wildcard Injection Detected", - "sha256": "91457268048c8d92e741bfd1d7bb5d54fe0d743c61407f7a0715f70c10dfa674", - "type": "eql", - "version": 7 - } - }, "rule_name": "Potential Shell via Wildcard Injection Detected", "sha256": "7fc4e84759a2af54a9511e0a595038dfb7f5e4cded7427859e3081ac8d7ff641", "type": "eql", @@ -765,16 +639,6 @@ "version": 2 }, "0c1e8fda-4f09-451e-bc77-a192b6cbfc32": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Potential Hex Payload Execution", - "sha256": "74f721a4c27361f235243b389dfdd0770212ed79d7fe1c2959e73c93b9edb754", - "type": "eql", - "version": 2 - } - }, "rule_name": "Potential Hex Payload Execution", "sha256": "60df1c7136646558bb4c4713cbfb9a5a4b107a9416be8a60fbf7700cbcb94ce3", "type": "eql", @@ -796,19 +660,12 @@ "0c7ca5c2-728d-4ad9-b1c5-bbba83ecb1f4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Peripheral Device Discovery", "sha256": "0ba61428f49133210022937f1edfd3ba9e42329cb91126ff0465644e23fc62ce", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Peripheral Device Discovery", - "sha256": "61ae1ba97794982369c44f00a1f32eec466cb30eb538a026250b2146313d688c", - "type": "eql", - "version": 211 } }, "rule_name": "Peripheral Device Discovery", @@ -823,7 +680,6 @@ "version": 204 }, "0cd2f3e6-41da-40e6-b28b-466f688f00a6": { - "min_stack_version": "8.13", "rule_name": "AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session", "sha256": "0d0084d44982bd3c5392b363044b94d1c083b4ff85c4da034a82be08872812d5", "type": "esql", @@ -842,16 +698,6 @@ "version": 4 }, "0d69150b-96f8-467c-a86d-a67a3378ce77": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 207, - "rule_name": "Nping Process Activity", - "sha256": "b83427252d66ff411238da7c5005c49740b023436dbc3bf58ba27c1ee3922248", - "type": "eql", - "version": 109 - } - }, "rule_name": "Nping Process Activity", "sha256": "1ecfdf114395bc4eb70a3fb066620a04c60f99884612e0f29066015950dbd8dc", "type": "eql", @@ -864,23 +710,12 @@ "version": 111 }, "0e1af929-42ed-4262-a846-55a7c54e7c84": { - "min_stack_version": "8.13", "rule_name": "Unusual High Denied Sensitive Information Policy Blocks Detected", "sha256": "06cd8ab4b8922f24d2b6151406f8680b95c67b7d415ccdab4ef61cfc5c80fda7", "type": "esql", "version": 2 }, "0e4367a0-a483-439d-ad2e-d90500b925fd": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of User Agent For a GitHub Personal Access Token (PAT)", - "sha256": "87d0a19367e8add592f2100c95bd1076e0a1aea6b46d62bc39297eb59dffb3b8", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of User Agent For a GitHub Personal Access Token (PAT)", "sha256": "87c53fc8cfc1a77be0a4e4e1323b5d6bb753604636a2e9bdeaa4910ebdf536ce", "type": "new_terms", @@ -893,7 +728,6 @@ "version": 207 }, "0e524fa6-eed3-11ef-82b4-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "M365 OneDrive Excessive File Downloads with OAuth Token", "sha256": "f6f434f76330ba923e4d55b62e92891d98a21706ca8bd0b47bd9811566a8c497", "type": "esql", @@ -908,7 +742,7 @@ "0e79980b-4250-4a50-a509-69294c14e84b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "MsBuild Making Network Connections", "sha256": "7c639b668c0b9207254749cb4e45c08ed861a61d1b5e8b27147b3b664d0ae255", @@ -935,32 +769,12 @@ "version": 116 }, "0f54e947-9ab3-4dff-9e8d-fb42493eaa2f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Polkit Policy Creation", - "sha256": "44b43d02b93465a284ad02a34ec8aac120647331d3e94740777d0814d5113600", - "type": "eql", - "version": 3 - } - }, "rule_name": "Polkit Policy Creation", "sha256": "0afcc930436684dfdd61e2ef01cbc1adfa72ab7f84b9fd58280c94953ffdaae0", "type": "eql", "version": 103 }, "0f56369f-eb3d-459c-a00b-87c2bf7bdfc5": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Netcat Listener Established via rlwrap", - "sha256": "79a36ec04c23d206b4a169e76b5d28d8f804a425556086fca9789d4fc8b188da", - "type": "eql", - "version": 4 - } - }, "rule_name": "Netcat Listener Established via rlwrap", "sha256": "4b9e8dd7f874cd95eb91b79ea9ff20499a9372b785b00b28508b0ce941af417e", "type": "eql", @@ -982,7 +796,7 @@ "0f93cb9a-1931-48c2-8cd0-f173fd3e5283": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 309, "rule_name": "Potential LSASS Memory Dump via PssCaptureSnapShot", "sha256": "47eb039775808da28b11790e0cc065e4a50d78e27c509b0d3658b680d0e8afa5", @@ -1035,7 +849,7 @@ "1160dcdb-0a0a-4a79-91d8-9b84616edebd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Potential DLL Side-Loading via Trusted Microsoft Programs", "sha256": "46d8b330ba652e23adf896e687f3e5366a624a5331876fc279966cc8b152cf65", @@ -1051,19 +865,12 @@ "1178ae09-5aff-460a-9f2f-455cd0ac4d8e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "UAC Bypass via Windows Firewall Snap-In Hijack", "sha256": "a994d1f91f21add41bfa56ede5881e607b7400b4d3892076489853ee155f7fce", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "UAC Bypass via Windows Firewall Snap-In Hijack", - "sha256": "153cade6c2583d73aadcdb8e1f138fd04f15225a1d087281dfb8e0a38a94a08d", - "type": "eql", - "version": 213 } }, "rule_name": "UAC Bypass via Windows Firewall Snap-In Hijack", @@ -1086,7 +893,7 @@ "11dd9713-0ec6-4110-9707-32daae1ee68c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 113, "rule_name": "PowerShell Script with Token Impersonation Capabilities", "sha256": "a7ec142dcda7675c77e9b876a21fdbc81216e3a996b187d8b9ce5fb6ee881abc", @@ -1100,16 +907,6 @@ "version": 115 }, "11ea6bec-ebde-4d71-a8e9-784948f8e3e9": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 212, - "rule_name": "Third-party Backup Files Deleted via Unexpected Process", - "sha256": "ee76235d5b6aa99a7637cf85a3aa081f0e5a037d0d480e0ea6da5743bbb38967", - "type": "eql", - "version": 113 - } - }, "rule_name": "Third-party Backup Files Deleted via Unexpected Process", "sha256": "529c6c9afcecffe9bc1f09b979a34bc926f72b18aae363094788855893224f4e", "type": "eql", @@ -1130,7 +927,7 @@ "1224da6c-0326-4b4f-8454-68cdc5ae542b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Suspicious Windows Process Cluster Spawned by a User", "sha256": "36f3d53e0e615d93af889f1a29da008db557f004f34ab0b3a14b5210f0aeee2f", @@ -1158,7 +955,7 @@ "128468bf-cab1-4637-99ea-fdf3780a4609": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Suspicious Lsass Process Access", "sha256": "b5585ef93c094d17af2ec93e821abae35166aff50db392c679bdfd4ad289691e", @@ -1186,19 +983,12 @@ "12de29d4-bbb0-4eef-b687-857e8a163870": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Potential Exploitation of an Unquoted Service Path Vulnerability", "sha256": "272a96e698a6afe16c3181d064b9c894e77f51b3eaf866209b5dce7565d67d30", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Potential Exploitation of an Unquoted Service Path Vulnerability", - "sha256": "dcb9f8fce25461a848fe06439c08665629219e3abdd01025c5555abb22bc059d", - "type": "eql", - "version": 105 } }, "rule_name": "Potential Exploitation of an Unquoted Service Path Vulnerability", @@ -1209,19 +999,12 @@ "12f07955-1674-44f7-86b5-c35da0a6f41a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Suspicious Cmd Execution via WMI", "sha256": "8a50a6a6f107f05960872b508ca599e3ced73c94f3e91ba756d516d1fb627486", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Suspicious Cmd Execution via WMI", - "sha256": "a2f0c592a53ec30b958e963921770be01cdef012944bea22ae236d2713cd09b4", - "type": "eql", - "version": 215 } }, "rule_name": "Suspicious Cmd Execution via WMI", @@ -1232,19 +1015,12 @@ "1327384f-00f3-44d5-9a8c-2373ba071e92": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Persistence via Scheduled Job Creation", "sha256": "17d08d5a22a343108d957c179ce6094d0257d0d8b2579a4951119dda819508f6", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 410, - "rule_name": "Persistence via Scheduled Job Creation", - "sha256": "9e89e81b01768e4420d38600625f002d5442c3b66d427dc5892345446d213aa6", - "type": "eql", - "version": 312 } }, "rule_name": "Persistence via Scheduled Job Creation", @@ -1253,16 +1029,6 @@ "version": 412 }, "135abb91-dcf4-48aa-b81a-5ad036b67c68": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Pluggable Authentication Module (PAM) Version Discovery", - "sha256": "7a40d647d43e173b746b298d0619a6058cb05a2eb33d6e0a4e546788fa16634a", - "type": "eql", - "version": 2 - } - }, "rule_name": "Pluggable Authentication Module (PAM) Version Discovery", "sha256": "8abcc3f4f205afae84358660b95a2527d10a1f5a33fb6aa904c0c1280d8b6805", "type": "eql", @@ -1277,19 +1043,12 @@ "1397e1b9-0c90-4d24-8d7b-80598eb9bc9a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Potential Ransomware Behavior - High count of Readme files by System", "sha256": "39c607c5899fa2a4b06f20c10675605931045838a883996b8978c1a623348ea7", "type": "threshold", "version": 7 - }, - "8.13": { - "max_allowable_version": 206, - "rule_name": "Potential Ransomware Behavior - High count of Readme files by System", - "sha256": "ac05cb0b596f7532273a85d11c32fdb6302791693df41953a29630139fe66853", - "type": "threshold", - "version": 107 } }, "rule_name": "Potential Ransomware Behavior - High count of Readme files by System", @@ -1322,16 +1081,6 @@ "version": 105 }, "14dab405-5dd9-450c-8106-72951af2391f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Office Test Registry Persistence", - "sha256": "3e44efbf96a359a35159414069ff36e12436779f48247e1ebb07a941605b448f", - "type": "eql", - "version": 4 - } - }, "rule_name": "Office Test Registry Persistence", "sha256": "ef730832a93503b501376aacb96760534cb31876eed560a014670d79b2d03b74", "type": "eql", @@ -1346,19 +1095,12 @@ "14ed1aa9-ebfd-4cf9-a463-0ac59ec55204": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Potential Persistence via Time Provider Modification", "sha256": "c1c4d209cde3b94cd2f8c548ecdb34cb3fa679dd0b53e7fdede58f9d1556ead5", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Potential Persistence via Time Provider Modification", - "sha256": "c8f114645f7f362fd704081bd1e07a79689640b1eff476ca39c731460729be8c", - "type": "eql", - "version": 212 } }, "rule_name": "Potential Persistence via Time Provider Modification", @@ -1369,7 +1111,7 @@ "1502a836-84b2-11ef-b026-f661ea17fbcc": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Successful Application SSO from Rare Unknown Client Device", "sha256": "56af4b22ba4a30c2b5b78e2dcfb7357c29381c5d442a322e59257043cb4e98b2", @@ -1404,7 +1146,7 @@ "15a8ba77-1c13-4274-88fe-6bd14133861e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Scheduled Task Execution at Scale via GPO", "sha256": "5590dc04999fc927242cf1926db4e2333087ea2de5e17c69677fa0ce42a76e5b", @@ -1420,19 +1162,12 @@ "15c0b7a7-9c34-4869-b25b-fa6518414899": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Remote File Download via Desktopimgdownldr Utility", "sha256": "59e37cb962abea6a86b2a9384e1f08d2d036cdf4ab29173bc0d6e344af013204", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Remote File Download via Desktopimgdownldr Utility", - "sha256": "d4a8b5bcd2a0a91c59da2511a57220c6075e93ea8e02ea1bbd8d32ce14c24f90", - "type": "eql", - "version": 215 } }, "rule_name": "Remote File Download via Desktopimgdownldr Utility", @@ -1461,7 +1196,7 @@ "166727ab-6768-4e26-b80c-948b228ffc06": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "File Creation Time Changed", "sha256": "4b13b87a19503b754f0e1168a58053e72b7ab57ed3f6b4fa1e85ca983050228f", @@ -1495,7 +1230,7 @@ "16fac1a1-21ee-4ca6-b720-458e3855d046": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Startup/Logon Script added to Group Policy Object", "sha256": "3cc36b41be0eac9cd7741554fb1bd65a80c0a77275abb17d58fd202b42c25c6b", @@ -1515,7 +1250,6 @@ "version": 2 }, "17261da3-a6d0-463c-aac8-ea1718afcd20": { - "min_stack_version": "8.13", "rule_name": "AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User", "sha256": "6862e5d1dee36ec1dcdcd165a67f6c373cd83aaa5f0db1b63ac526b78d346e02", "type": "esql", @@ -1524,7 +1258,7 @@ "1781d055-5c66-4adf-9c59-fc0fa58336a5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Unusual Windows Username", "sha256": "e9ed01e74760cd8f6b5436fa2bf1017b75f7981365876ee0443e0bab995a0f27", @@ -1540,7 +1274,7 @@ "1781d055-5c66-4adf-9c71-fc0fa58338c7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Unusual Windows Service", "sha256": "a1c9cbff26b71eb5194648a9907fd39e1504c7662a8f217cd2e9c099f9e24767", @@ -1556,7 +1290,7 @@ "1781d055-5c66-4adf-9d60-fc0fa58337b6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Suspicious Powershell Script", "sha256": "fc63208d7b1218e72d90948342343c545aab84431421c2d3b6d81b1a925181a1", @@ -1572,7 +1306,7 @@ "1781d055-5c66-4adf-9d82-fc0fa58449c8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Unusual Windows User Privilege Elevation Activity", "sha256": "219fa2a191fb555ae903516b407568cc9bbc7be95ca6f3fb302311ce94382f0f", @@ -1588,7 +1322,7 @@ "1781d055-5c66-4adf-9e93-fc0fa69550c9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Unusual Windows Remote User", "sha256": "c2ce8aa3cd6b41359d2374f00b781728b1d6990960574e1d27d013e9a33cda80", @@ -1608,7 +1342,6 @@ "version": 16 }, "17b3fcd1-90fb-4f5d-858c-dc1d998fa368": { - "min_stack_version": "8.13", "rule_name": "Initramfs Extraction via CPIO", "sha256": "e91def04da5452836c00e38e6652e095e4124c1820f2650c10e07cd01e3fc61b", "type": "eql", @@ -1617,7 +1350,7 @@ "17c7f6a5-5bc9-4e1f-92bf-13632d24384d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Renamed Utility Executed with Short Program Name", "sha256": "3b12641768e2a47b26428daf4f845ab28c7dd839b86550febd738e1e8586d6ff", @@ -1639,19 +1372,12 @@ "181f6b23-3799-445e-9589-0018328a9e46": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Script Execution via Microsoft HTML Application", "sha256": "12f1a83fb96e68e2440fc75a664bb40ec93c873078e8e95f4e7ada4d552370dc", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Script Execution via Microsoft HTML Application", - "sha256": "af9a371780c9a5d15b340de55265c36733b80ec3bd7ae69c38546b2bf617a8bf", - "type": "eql", - "version": 103 } }, "rule_name": "Script Execution via Microsoft HTML Application", @@ -1740,19 +1466,12 @@ "1a6075b0-7479-450e-8fe7-b8b8438ac570": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Execution of COM object via Xwizard", "sha256": "f6391e8f5b0619d0a9d9c44f7eb9fd4ee84d804dce2a33222731c4d7f110975b", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Execution of COM object via Xwizard", - "sha256": "8e04dc1449042764a07c9fc2051bf7a5c8d58e05bafa41e5eaa68ca6baeada51", - "type": "eql", - "version": 213 } }, "rule_name": "Execution of COM object via Xwizard", @@ -1769,19 +1488,12 @@ "1aa9181a-492b-4c01-8b16-fa0735786b2b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "User Account Creation", "sha256": "1046be8b577da52ec4ae4f06bcbf7ac7e32232c0e2d407916cb0474c8add7849", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "User Account Creation", - "sha256": "142471dd697b20805b6879a80f98136fb3c2b5519aa353e6f1ff95700a4f0b04", - "type": "eql", - "version": 211 } }, "rule_name": "User Account Creation", @@ -1796,16 +1508,6 @@ "version": 4 }, "1b21abcc-4d9f-4b08-a7f5-316f5f94b973": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 206, - "rule_name": "Connection to Internal Network via Telnet", - "sha256": "1bc65565de45f1eff32df65b75aff663321aa0ebe9f25ab4bf86a1069147f03e", - "type": "eql", - "version": 108 - } - }, "rule_name": "Connection to Internal Network via Telnet", "sha256": "577e427fc64582ac236a077a7655689420ac05895657991b9b10c235df191853", "type": "eql", @@ -1848,16 +1550,6 @@ "version": 103 }, "1ca62f14-4787-4913-b7af-df11745a49da": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "New GitHub App Installed", - "sha256": "5409f401ac786bdadc45606d8d7f4b4c537367d93cf5555278d620c26f984168", - "type": "eql", - "version": 105 - } - }, "rule_name": "New GitHub App Installed", "sha256": "e00feec6890b2361d7a10a06e2e91c713d0f28c866005e9e1f72610f0dbea4eb", "type": "eql", @@ -1866,7 +1558,7 @@ "1cd01db9-be24-4bef-8e7c-e923f0ff78ab": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Incoming Execution via WinRM Remote Shell", "sha256": "ce97e8b346f6e7bba7e209a95c49253e1561ae4cc80a170c9ae2e23ae6f36dbb", @@ -1882,7 +1574,7 @@ "1ceb05c4-7d25-11ee-9562-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Okta Sign-In Events via Third-Party IdP", "sha256": "a6cd972bd4e61e4b5162bada4abcd0d49ddb1c1219971cdbffbb8efd8589444d", @@ -1905,7 +1597,7 @@ "1d276579-3380-4095-ad38-e596a01bc64f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Remote File Download via Script Interpreter", "sha256": "832c238b226f2b7fbbc201338e1d0dfe12a9a7ebf4a6263a1f038ab6019e0e6f", @@ -1933,7 +1625,7 @@ "1d9aeb0b-9549-46f6-a32d-05e2a001b7fd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "PowerShell Script with Encryption/Decryption Capabilities", "sha256": "bebecc71ea78fc04d87220b72ed8450adc877e7430358cbb0634a5f9ff266344", @@ -1949,19 +1641,12 @@ "1dcc51f6-ba26-49e7-9ef4-2655abb2361e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "UAC Bypass via DiskCleanup Scheduled Task Hijack", "sha256": "56bbd2e4cd59a4c2cde86cbbbfcd9e0afc33c8305d71bab718500435d3a78c7e", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "UAC Bypass via DiskCleanup Scheduled Task Hijack", - "sha256": "34fb9c8b0fd50e111ac85f4594d6ea57df7c600c03164d83b6e2485114ad49ce", - "type": "eql", - "version": 212 } }, "rule_name": "UAC Bypass via DiskCleanup Scheduled Task Hijack", @@ -1978,7 +1663,7 @@ "1defdd62-cd8d-426e-a246-81a37751bb2b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Execution of File Written or Modified by PDF Reader", "sha256": "b1632c3ea7afb58a44d388ad05920751d22614d6714b65ffeb29af66d7ebf70d", @@ -1992,16 +1677,6 @@ "version": 208 }, "1df1152b-610a-4f48-9d7a-504f6ee5d9da": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "Potential Linux Hack Tool Launched", - "sha256": "aa02b181f4f9a4df3460586733ba1ae7481ed321e4ef4e2ed3b418030ef65bc9", - "type": "eql", - "version": 5 - } - }, "rule_name": "Potential Linux Hack Tool Launched", "sha256": "98f03ae22b61103956c3dcf4c477d3dd6c5da89a7c24f1e69a4a6f5f96573033", "type": "eql", @@ -2010,7 +1685,7 @@ "1e0a3f7c-21e7-4bb1-98c7-2036612fb1be": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "PowerShell Script with Discovery Capabilities", "sha256": "84304c49d97dfd2c29bf2dac4eab3f95bd8ec1c210dde0c3c55dffb087436df1", @@ -2032,7 +1707,7 @@ "1e1b2e7e-b8f5-45e5-addc-66cc1224ffbc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Creation of a DNS-Named Record", "sha256": "4955aaefda636b2420e5116875b69def93dd7fd67397cb2a0322de00b946b0fc", @@ -2048,7 +1723,7 @@ "1e6363a6-3af5-41d4-b7ea-d475389c0ceb": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Creation of SettingContent-ms Files", "sha256": "a70ff9e091484d965ff3685d7e196ddebed427ccb1b700563fad5c6a47880a39", @@ -2062,16 +1737,6 @@ "version": 106 }, "1e9b271c-8caa-4e20-aed8-e91e34de9283": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)", - "sha256": "c4f772b100c3877e71a485342787e5f29775002ef02710d07bffd3db397230d0", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT)", "sha256": "3fbd0a6e68860fbf412958b71752c7ba5a4c24d66e5a49b41c27c17021ab596b", "type": "new_terms", @@ -2086,7 +1751,7 @@ "1f0a69c0-3392-4adf-b7d5-6012fd292da8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "Potential Antimalware Scan Interface Bypass via PowerShell", "sha256": "021df20053fabc64b24430c7e4bdb3fa187c6f00b27139bffc24759c4e97b817", @@ -2100,7 +1765,6 @@ "version": 113 }, "1f45720e-5ea8-11ef-90d2-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "AWS Signin Single Factor Console Login with Federated User", "sha256": "67652ae55e23dcc67c6e395bd4b6354b74840c3c0ef81b0abe48e5f0fda50dc7", "type": "esql", @@ -2109,7 +1773,7 @@ "1f460f12-a3cf-4105-9ebb-f788cc63f365": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Unusual Process Execution on WBEM Path", "sha256": "c0c0dc9d02782e6a4e0945d5a4067d3508deaeed48634ba3aa3bce892de5a9c4", @@ -2123,7 +1787,6 @@ "version": 105 }, "1fa350e0-0aa2-4055-bf8f-ab8b59233e59": { - "min_stack_version": "8.13", "rule_name": "High Number of Egress Network Connections from Unusual Executable", "sha256": "d9e8a7e51aa77ead7ce1ea1fea343c35fdb7aa4cc92450f6ebad5433afbc53de", "type": "esql", @@ -2138,7 +1801,7 @@ "1fe3b299-fbb5-4657-a937-1d746f2c711a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Unusual Network Activity from a Windows System Binary", "sha256": "4fefe2cc790c9b5fd8afbd08cfd7bd28ee6f50dffd877ec1400d81c1659bcc36", @@ -2160,19 +1823,12 @@ "201200f1-a99b-43fb-88ed-f65a45c4972c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Suspicious .NET Code Compilation", "sha256": "acfdd598b6015547f15e05e3ee2dd61dec13a52e09ccef1f154e133678cb2e8a", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Suspicious .NET Code Compilation", - "sha256": "891281c4090da3be8a47c99999198fb67201bc47da9b753cd8cdf6b2107a4f86", - "type": "eql", - "version": 213 } }, "rule_name": "Suspicious .NET Code Compilation", @@ -2181,16 +1837,6 @@ "version": 314 }, "202829f6-0271-4e88-b882-11a655c590d4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Executable Masquerading as Kernel Process", - "sha256": "c647d352170795fda0533a278e5c93824030a0e2391afb7d858ddf8fcef50ea3", - "type": "eql", - "version": 4 - } - }, "rule_name": "Executable Masquerading as Kernel Process", "sha256": "5349e739a994b977cd138844e8e7e85da55971fb9e45fb3131eb92be33d3f123", "type": "eql", @@ -2199,19 +1845,12 @@ "203ab79b-239b-4aa5-8e54-fc50623ee8e4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Creation or Modification of Root Certificate", "sha256": "3f84e82e7eeac167ba639d999edb121e0b7b2d9ccae3655a4d3d543667794332", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Creation or Modification of Root Certificate", - "sha256": "1e793bac94cf744476de8ec10572545b6000ddfafffe37170ddb870c9b5c8d94", - "type": "eql", - "version": 211 } }, "rule_name": "Creation or Modification of Root Certificate", @@ -2234,19 +1873,12 @@ "205b52c4-9c28-4af4-8979-935f3278d61a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Werfault ReflectDebugger Persistence", "sha256": "69246453362e5ca8115d5ebc4d54e31708b17fca42e8f1c3289e2f21e27e0982", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "Werfault ReflectDebugger Persistence", - "sha256": "b3cf96a675e8bce7a335b93a6cceb02c5a7c736ced121dac5662c305c9855738", - "type": "eql", - "version": 103 } }, "rule_name": "Werfault ReflectDebugger Persistence", @@ -2257,7 +1889,7 @@ "208dbe77-01ed-4954-8d44-1e5751cb20de": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "LSASS Memory Dump Handle Access", "sha256": "c71196cfccc34b4c3d768cc7220422fdaf2d6163c21dc2b1f3c8d1616a87dfb9", @@ -2303,7 +1935,7 @@ "220be143-5c67-4fdb-b6ce-dd6826d024fd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Full User-Mode Dumps Enabled System-Wide", "sha256": "39e75f704730200ba6057b7687a63159e2080003d55f8b8e6217740e487ab59e", @@ -2347,16 +1979,6 @@ "version": 105 }, "2339f03c-f53f-40fa-834b-40c5983fc41f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Kernel Module Load via insmod", - "sha256": "6d909c9373be54b6dc83f2c1d0b5416582fe6dbf4206daf4e496410ac5913aec", - "type": "eql", - "version": 111 - } - }, "rule_name": "Kernel Module Load via insmod", "sha256": "f32774ffb6275cc6e21892bde0346fec8649a7b12e62823bc9c28ecb5f7291b4", "type": "eql", @@ -2398,16 +2020,6 @@ "version": 204 }, "24401eca-ad0b-4ff9-9431-487a8e183af9": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 205, - "rule_name": "New GitHub Owner Added", - "sha256": "002be9292a0806831cffe8f7c1ae8704f2aba19ded7a11964225cde1c263c851", - "type": "eql", - "version": 107 - } - }, "rule_name": "New GitHub Owner Added", "sha256": "a2e44a9352982f9a7fab91d7a6c0ed56fa52f09663f20c41c246407f643bb81a", "type": "eql", @@ -2416,19 +2028,12 @@ "25224a80-5a4a-4b8a-991e-6ab390465c4f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Lateral Movement via Startup Folder", "sha256": "9a03061d1c7d42331e54fa8c990602900d110a67d95d1245e44eae86e42cdc90", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Lateral Movement via Startup Folder", - "sha256": "9e4c99a01ff339552587a57d476760b6cdeec2634d2f26b6d801a2f3baeb0bd5", - "type": "eql", - "version": 210 } }, "rule_name": "Lateral Movement via Startup Folder", @@ -2439,7 +2044,7 @@ "2553a9af-52a4-4a05-bb03-85b2a479a0a0": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Potential PowerShell HackTool Script by Author", "sha256": "099be59655d3f1d35382b882049816c2c0570633f5d119e1ae6285bf5d5a901c", @@ -2453,16 +2058,6 @@ "version": 105 }, "259be2d8-3b1a-4c2c-a0eb-0c8e77f35e39": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "Potential Reverse Shell via Background Process", - "sha256": "0fee3ba7e3d8302fa7bf7fe483672987cabfa3cd38c2e532907b1b788f7c8260", - "type": "eql", - "version": 5 - } - }, "rule_name": "Potential Reverse Shell via Background Process", "sha256": "5539b5852223d4f71fb0ca5aca8622d8933016111d08f98d0bed0b9f804ddf7e", "type": "eql", @@ -2483,7 +2078,7 @@ "260486ee-7d98-11ee-9599-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "New Okta Authentication Behavior Detected", "sha256": "70f1f9059df5bd8fccefb340c09ead9f96478027b8a573ef31fed90b89e5e935", @@ -2512,7 +2107,7 @@ "263481c8-1e9b-492e-912d-d1760707f810": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Potential Relay Attack against a Domain Controller", "sha256": "54a0ad6f86ecdf068b1aae65f14d158a4f15e61b09a082762d2bd3413455bd6d", @@ -2540,19 +2135,12 @@ "265db8f5-fc73-4d0d-b434-6483b56372e2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Persistence via Update Orchestrator Service Hijack", "sha256": "4cb0180da3ef6e0e18bd152032578629a162d39c81b679998254e1e96d7a7a1e", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Persistence via Update Orchestrator Service Hijack", - "sha256": "04cf4724c581ce8d3a98423140537e39f236a8e0f13794cde43219b0cab63273", - "type": "eql", - "version": 214 } }, "rule_name": "Persistence via Update Orchestrator Service Hijack", @@ -2561,7 +2149,6 @@ "version": 314 }, "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73": { - "min_stack_version": "8.13", "rule_name": "Unusual High Denied Topic Blocks Detected", "sha256": "fe10ea745cf3203f237c4b8a40c63e9cb9d364c796bf52a2377425c3bd013171", "type": "esql", @@ -2574,16 +2161,6 @@ "version": 1 }, "26a726d7-126e-4267-b43d-e9a70bfdee1e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Potential Defense Evasion via Doas", - "sha256": "5a94f36cb64d23ad01b8c1ffe0cbe7229007da049faf46d3b1076badcc0a3714", - "type": "eql", - "version": 2 - } - }, "rule_name": "Potential Defense Evasion via Doas", "sha256": "aeeb4b372fbfd18ee0dfa78606413a606d6bc8e7bee480b01504cbe103fe8006", "type": "eql", @@ -2602,16 +2179,6 @@ "version": 105 }, "26f68dba-ce29-497b-8e13-b4fde1db5a2d": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 308, - "rule_name": "Attempts to Brute Force a Microsoft 365 User Account", - "sha256": "d41060acde6ba44c9fd538c2c2169114bcdd473a35332389b5cd82e9ebef2af9", - "type": "esql", - "version": 211 - } - }, "rule_name": "Attempts to Brute Force a Microsoft 365 User Account", "sha256": "d25046282b20d2a93b29f3016f1dfa97b68488629031ddb7157c032045f36b59", "type": "esql", @@ -2620,7 +2187,7 @@ "27071ea3-e806-4697-8abc-e22c92aa4293": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "PowerShell Script with Archive Compression Capabilities", "sha256": "6bf709b275145a7968784c0cad4cc126d1032ae778c4d23e18d5502e0c430d95", @@ -2634,16 +2201,6 @@ "version": 209 }, "2724808c-ba5d-48b2-86d2-0002103df753": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 104, - "rule_name": "Attempt to Clear Kernel Ring Buffer", - "sha256": "63d9ec6b0b8f754c3d04d1b8509f7978545110c21c7cd36b95629e33e8327e06", - "type": "eql", - "version": 6 - } - }, "rule_name": "Attempt to Clear Kernel Ring Buffer", "sha256": "0940ad2254d8e550d0c01bf6a647edcd02990c8bbae6b9ca4b17522ae43f803d", "type": "eql", @@ -2658,7 +2215,7 @@ "2772264c-6fb9-4d9d-9014-b416eed21254": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Incoming Execution via PowerShell Remoting", "sha256": "21c8229d021bc8b4ae787107ff45217ab56d52e249857ff17e0a4f51ef3c7f85", @@ -2686,7 +2243,7 @@ "2820c9c2-bcd7-4d6e-9eba-faf3891ba450": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 215, "rule_name": "Account Password Reset Remotely", "sha256": "fb5aa2394d8110f0ee46049a6b1ecea7a58a015560ea9e83bc0a7189668b9a9e", @@ -2700,7 +2257,6 @@ "version": 218 }, "28371aa1-14ed-46cf-ab5b-2fc7d1942278": { - "min_stack_version": "8.13", "rule_name": "Potential Widespread Malware Infection Across Multiple Hosts", "sha256": "138552f6df8aee3e8ab2164631ef74888c7d0297c012bbd6ac9ea1c1a37ecc46", "type": "esql", @@ -2709,7 +2265,7 @@ "2856446a-34e6-435b-9fb5-f8f040bfa7ed": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Account Discovery Command via SYSTEM Account", "sha256": "7395e4f0038f91caff80f8f82fb7a573cc2e3be731008e546f8e2f2738da7397", @@ -2753,16 +2309,6 @@ "version": 4 }, "28d39238-0c01-420a-b77a-24e5a7378663": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 105, - "rule_name": "Sudo Command Enumeration Detected", - "sha256": "60350833224cc7d578b57e68377f5c6eec36459f3b1219b27857d2dfb83c1dcb", - "type": "eql", - "version": 7 - } - }, "rule_name": "Sudo Command Enumeration Detected", "sha256": "84fc475479d15e3bc80b09e99dfac0c0b49c2a5edcfc3219f1ab09100b7d1555", "type": "eql", @@ -2771,7 +2317,7 @@ "28eb3afe-131d-48b0-a8fc-9784f3d54f3c": { "min_stack_version": "8.16", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Privilege Escalation via SUID/SGID", "sha256": "6ace4761c9708044d26fcf7337460b8479b0c47a4aad784406a4831f875a8ea1", @@ -2799,19 +2345,12 @@ "290aca65-e94d-403b-ba0f-62f320e63f51": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "UAC Bypass Attempt via Windows Directory Masquerading", "sha256": "d0e818d0f2ad9ea6d298e000b8823c6f9fae9d4ba58fd7d4a769d192a825bb7d", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "UAC Bypass Attempt via Windows Directory Masquerading", - "sha256": "25a8a5e36180af284b27b2a98e81479ace44455516f3093491003f1c052b247d", - "type": "eql", - "version": 216 } }, "rule_name": "UAC Bypass Attempt via Windows Directory Masquerading", @@ -2822,19 +2361,12 @@ "2917d495-59bd-4250-b395-c29409b76086": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Web Shell Detection: Script Process Child of Common Web Processes", "sha256": "28c64115f2234bf5d1fecf8825b0c7f3345d8785463039b6e20726ad83f4fae9", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 414, - "rule_name": "Web Shell Detection: Script Process Child of Common Web Processes", - "sha256": "086feb5b95a941af5edb6a8cda1844381dc9266800897730bb4c7360a6c48c51", - "type": "eql", - "version": 316 } }, "rule_name": "Web Shell Detection: Script Process Child of Common Web Processes", @@ -2845,7 +2377,7 @@ "291a0de9-937a-4189-94c0-3e847c8b13e4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "Enumeration of Privileged Local Groups Membership", "sha256": "74bf38098dbce95a0c1c95412e8fba9a3f5532a02c1838b1198a971eed59d253", @@ -2861,7 +2393,7 @@ "29b53942-7cd4-11ee-b70e-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "New Okta Identity Provider (IdP) Added by Admin", "sha256": "ced824201a88878d9e9186b2e710aea0f3325e0e249c379f3b6cc276abb4e8dd", @@ -2888,16 +2420,6 @@ "version": 2 }, "29f0cf93-d17c-4b12-b4f3-a433800539fa": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "Linux SSH X11 Forwarding", - "sha256": "607bcf6166da9a0c07fa8208a598d656e9da82b719410a4b3861431a7ad23b41", - "type": "eql", - "version": 5 - } - }, "rule_name": "Linux SSH X11 Forwarding", "sha256": "2b3d08f13e7043638c0bb3415d9ada4726d3dd2aa56b93a318ed3b135d0723d2", "type": "eql", @@ -2916,16 +2438,6 @@ "version": 205 }, "2b662e21-dc6e-461e-b5cf-a6eb9b235ec4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "ESXI Discovery via Grep", - "sha256": "0b220ddab575a1241b10575ba0fa022641bb5dd6d7b668a24f6e4e8e7795381c", - "type": "eql", - "version": 8 - } - }, "rule_name": "ESXI Discovery via Grep", "sha256": "8a0b201a019a813afef3eb6ad8931c76409acb49bfb1000a7e441fab4f19f9ba", "type": "eql", @@ -2934,19 +2446,12 @@ "2bf78aa2-9c56-48de-b139-f169bf99cf86": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Adobe Hijack Persistence", "sha256": "c39267858935a1708b5485ab0f15d8fec3c65af74dda3eabe1a645357b6ff54c", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 413, - "rule_name": "Adobe Hijack Persistence", - "sha256": "5d4eda2322ee604b41b05b508100d15e3d8230cf544f5e9685b20c82c9957fc4", - "type": "eql", - "version": 315 } }, "rule_name": "Adobe Hijack Persistence", @@ -2957,19 +2462,12 @@ "2c17e5d7-08b9-43b2-b58a-0270d65ac85b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Windows Defender Exclusions Added via PowerShell", "sha256": "fda9500da0b3d309b22466c14a3b99bc7b486e029d19035500b51c712c4d337d", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Windows Defender Exclusions Added via PowerShell", - "sha256": "bd55b8a641caefe82fd1e124f00f3332b0b81d8efddbe594a1a73415c0a5d41f", - "type": "eql", - "version": 213 } }, "rule_name": "Windows Defender Exclusions Added via PowerShell", @@ -2980,7 +2478,7 @@ "2c3c29a4-f170-42f8-a3d8-2ceebc18eb6a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Suspicious Microsoft Diagnostics Wizard Execution", "sha256": "19459360acfaabbee9191b0bffc67924d652582ec4b24d908ab43e31ed2baf8f", @@ -2996,19 +2494,12 @@ "2c6a6acf-0dcb-404d-89fb-6b0327294cfa": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Potential Foxmail Exploitation", "sha256": "fa4198db44ca8125dc5157ed58f08cb85ded4ed4fdd90a197bd108a4788e7bb9", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Potential Foxmail Exploitation", - "sha256": "3b3410ec8a78d817be6bc0002e08c1aecc291c587a8e5049c46ba2a0ffca42e8", - "type": "eql", - "version": 103 } }, "rule_name": "Potential Foxmail Exploitation", @@ -3019,19 +2510,12 @@ "2d62889e-e758-4c5e-b57e-c735914ee32a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Suspicious PowerShell Execution via Windows Scripts", "sha256": "da7b8fc9196d2268f214a0e688fb4743c4aaac83e91d448cac7edb41ecb0cc4d", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Suspicious PowerShell Execution via Windows Scripts", - "sha256": "da8bbc8a8b7835679b590b3422fc6c384b3818f963248606c077e274ea185f00", - "type": "eql", - "version": 103 } }, "rule_name": "Command and Scripting Interpreter via Windows Scripts", @@ -3048,7 +2532,7 @@ "2dd480be-1263-4d9c-8672-172928f6789a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "Suspicious Process Access via Direct System Call", "sha256": "6f9f6d3a9b1c3c10ee6f372c529e3043cf57abbe70e819991e61b39bd48cfac8", @@ -3062,16 +2546,6 @@ "version": 312 }, "2ddc468e-b39b-4f5b-9825-f3dcb0e998ea": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Potential SSH-IT SSH Worm Downloaded", - "sha256": "fc0687aaffa30b4402ffbb232a6609e8a832a677f70d6f87d826e0967cb6ae18", - "type": "eql", - "version": 4 - } - }, "rule_name": "Potential SSH-IT SSH Worm Downloaded", "sha256": "cd015724526c5fd95611fd542dcd3bf3ae7cf0f17b78feaf63025db570b62459", "type": "eql", @@ -3086,19 +2560,12 @@ "2de87d72-ee0c-43e2-b975-5f0b029ac600": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Wireless Credential Dumping using Netsh Command", "sha256": "a2a8c353c9789286a12acad9ac5ef3f78e625e7f76155b7f8fabe49323aa8e5c", "type": "eql", "version": 11 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "Wireless Credential Dumping using Netsh Command", - "sha256": "8f884c1870437488658be0d2e627b6979914c5073df0908b2386a2d64a3b4140", - "type": "eql", - "version": 111 } }, "rule_name": "Wireless Credential Dumping using Netsh Command", @@ -3116,7 +2583,7 @@ "2e1e835d-01e5-48ca-b9fc-7a61f7f11902": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Renamed AutoIt Scripts Interpreter", "sha256": "3f92ade9c8cf46297f9846194909bde8477311035bce84de538a59154fab0a08", @@ -3132,7 +2599,7 @@ "2e29e96a-b67c-455a-afe4-de6183431d0d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Potential Process Injection via PowerShell", "sha256": "5b87e1ff673e96046b8a94a9a5aa5135f3d5993a7c6cb7cbb27f420605413029", @@ -3148,7 +2615,7 @@ "2e311539-cd88-4a85-a301-04f38795007c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Accessing Outlook Data Files", "sha256": "e16b755ef96474eeeb8efab6ae108f1e9420b53cd1d79d3e822dc3215788f7a9", @@ -3164,20 +2631,13 @@ "2e56e1bc-867a-11ee-b13e-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Okta User Sessions Started from Different Geolocations", "sha256": "154a54c158e1072b12c8c12e5c0b1a4efd33eeb055cc0a97dfbce0af0e73dc48", "type": "threshold", "version": 2 }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Okta User Sessions Started from Different Geolocations", - "sha256": "9d2bcc3e964c0434187bfaa20b0f3273fdedbc87d5c26e8096ceaf6770db9e66", - "type": "esql", - "version": 104 - }, "8.14": { "max_allowable_version": 302, "rule_name": "Okta User Sessions Started from Different Geolocations", @@ -3200,19 +2660,12 @@ "2edc8076-291e-41e9-81e4-e3fcbc97ae5e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Creation of a Hidden Local User Account", "sha256": "79fe2f7b518213d1f446515f7a7b768af9118e6217220e52e9e106464cc3c478", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Creation of a Hidden Local User Account", - "sha256": "a3f55a20eb34eb9f050c14ebec723bf8910a29329d76e98fee0fa59c90d5d247", - "type": "eql", - "version": 211 } }, "rule_name": "Creation of a Hidden Local User Account", @@ -3229,7 +2682,7 @@ "2f2f4939-0b34-40c2-a0a3-844eb7889f43": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "PowerShell Suspicious Script with Audio Capture Capabilities", "sha256": "c854f417e250f05be348cb5bd38338d7abaf467dc4b5ab1ef0fd15c0fe00d652", @@ -3243,16 +2696,6 @@ "version": 212 }, "2f8a1226-5720-437d-9c20-e0029deb6194": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Attempt to Disable Syslog Service", - "sha256": "2ef044a4379ebf8587fd12c998257f558761c47509df7f0295893dd4bb6f34f3", - "type": "eql", - "version": 111 - } - }, "rule_name": "Attempt to Disable Syslog Service", "sha256": "64eabeec581d6804bbb7ed7f4fd9a7792413294be3c0f6b2045dd0e0fe5d0c09", "type": "eql", @@ -3273,7 +2716,7 @@ "2ffa1f1e-b6db-47fa-994b-1512743847eb": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 214, "rule_name": "Windows Defender Disabled via Registry Modification", "sha256": "3a93523d026c5a673617ab034e9aacbeef768ba67239b7db35fd13d4082ed83b", @@ -3305,16 +2748,6 @@ "version": 3 }, "30bfddd7-2954-4c9d-bbc6-19a99ca47e23": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 107, - "rule_name": "ESXI Timestomping using Touch Command", - "sha256": "087ddf9a38cc3a95ddd050c3af74a8205dcf16b78a267a1c40ecab0206895466", - "type": "eql", - "version": 9 - } - }, "rule_name": "ESXI Timestomping using Touch Command", "sha256": "9f0737cd4b53c31a9412db6fe279689258d74cd0462413dbf350f2a1f520f5b9", "type": "eql", @@ -3347,19 +2780,12 @@ "31b4c719-f2b4-41f6-a9bd-fce93c2eaf62": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Bypass UAC via Event Viewer", "sha256": "26c302e48a82a4c71b95bbacfe998d079412e39f679f834e69fae5d875669849", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "Bypass UAC via Event Viewer", - "sha256": "5421bd89d5aebebf2cfa8655a02e73854e34caf836d61a4b91097c5a5fd752a3", - "type": "eql", - "version": 216 } }, "rule_name": "Bypass UAC via Event Viewer", @@ -3374,7 +2800,6 @@ "version": 105 }, "3216949c-9300-4c53-b57a-221e364c6457": { - "min_stack_version": "8.13", "rule_name": "Unusual High Word Policy Blocks Detected", "sha256": "fbc24d43876fb187d170bf7067f200bfc4a9dc9315138429cf73dd99f867b8ba", "type": "esql", @@ -3401,19 +2826,12 @@ "32c5cf9c-2ef8-4e87-819e-5ccb7cd18b14": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Program Files Directory Masquerading", "sha256": "606536c8d6bfe0e947e3e259b6e852bc054d4d698047726f4d5c75b729bf55e1", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Program Files Directory Masquerading", - "sha256": "7a4d10f9a885c140e679ea9b1395f36c0013153e988bda9aadef3631ee490db6", - "type": "eql", - "version": 213 } }, "rule_name": "Program Files Directory Masquerading", @@ -3430,19 +2848,12 @@ "32f4675e-6c49-4ace-80f9-97c9259dca2e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Suspicious MS Outlook Child Process", "sha256": "0c5ba486bee0cc0f0fe8315f14137e5a0062539cbb92e1a748fe09f9371887c7", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 414, - "rule_name": "Suspicious MS Outlook Child Process", - "sha256": "1aefbec4935b19811f4b8ec91466a3726ac0e9ceff35b20a76571ede0a753046", - "type": "eql", - "version": 316 } }, "rule_name": "Suspicious MS Outlook Child Process", @@ -3451,16 +2862,6 @@ "version": 417 }, "3302835b-0049-4004-a325-660b1fba1f67": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Directory Creation in /bin directory", - "sha256": "e2fc0d10f43934c5dfad79a4f0f2618e38c52f91e897b1fbbaeb75b7d2ae0749", - "type": "eql", - "version": 2 - } - }, "rule_name": "Directory Creation in /bin directory", "sha256": "bb642177d5cb1e1bc0f9a0c4cf899a157c7980be76dc66f26d4ba3d13f82b8d6", "type": "eql", @@ -3473,16 +2874,6 @@ "version": 209 }, "33a6752b-da5e-45f8-b13a-5f094c09522f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "ESXI Discovery via Find", - "sha256": "e945a579fb2d4bdd868c12f606098cd96cd82197b76142880a5deab1ab401ab5", - "type": "eql", - "version": 8 - } - }, "rule_name": "ESXI Discovery via Find", "sha256": "ca86b5108a30b8e67c15162b0055562e937ab308d0406d129bc9ad4e2148f2e4", "type": "eql", @@ -3501,16 +2892,6 @@ "version": 3 }, "345889c4-23a8-4bc0-b7ca-756bd17ce83b": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 202, - "rule_name": "GitHub Repository Deleted", - "sha256": "bbc9f533b703f0f2a2aec221e6c184c662bae31b89b8e01b2a7483f00fdbb84b", - "type": "eql", - "version": 104 - } - }, "rule_name": "GitHub Repository Deleted", "sha256": "680ea8566ca2b5e114053f331458450f3a9fdbdcda67246619a56e3304d7d4bb", "type": "eql", @@ -3537,19 +2918,12 @@ "3535c8bb-3bd5-40f4-ae32-b7cd589d5372": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Port Forwarding Rule Addition", "sha256": "1278795e146f4388f338e9288d125c501ac2323f738e27e32771e3f98bf5983d", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 412, - "rule_name": "Port Forwarding Rule Addition", - "sha256": "a5d70c0995622fa1e034a975d14f87929c6bb6032e2a8b710c5619638eeddef7", - "type": "eql", - "version": 313 } }, "rule_name": "Port Forwarding Rule Addition", @@ -3564,7 +2938,6 @@ "version": 5 }, "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc": { - "min_stack_version": "8.13", "rule_name": "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts", "sha256": "3f28423faced2b8aa0493681362683f095c9464aa5ecb67465ac44f2694aefc3", "type": "esql", @@ -3573,19 +2946,12 @@ "35df0dd8-092d-4a83-88c1-5151a804f31b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Unusual Parent-Child Relationship", "sha256": "d1997aecd63bdf78d6a33f57d17ebd466ad6d7b59bc5c9eec9d99fa339cc883b", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Unusual Parent-Child Relationship", - "sha256": "a7bf02c5ce9115c129f0c257b37f8d3759ee1de5c93e961c678bc6ca1e5ac53e", - "type": "eql", - "version": 215 } }, "rule_name": "Unusual Parent-Child Relationship", @@ -3614,19 +2980,12 @@ "36a8e048-d888-4f61-a8b9-0f9e2e40f317": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Suspicious ImagePath Service Creation", "sha256": "e0de6aabadb9b3edc0355ae72df8fa446a91a842ef12b8ef6ec687e906c931f5", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Suspicious ImagePath Service Creation", - "sha256": "cd1475178a3952f625d34aa54ca62f9221babf15037db6ad279da8a14ec58ff7", - "type": "eql", - "version": 210 } }, "rule_name": "Suspicious ImagePath Service Creation", @@ -3641,16 +3000,6 @@ "version": 5 }, "3728c08d-9b70-456b-b6b8-007c7d246128": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 104, - "rule_name": "Potential Suspicious File Edit", - "sha256": "85b4308a095fda0a1a41576379cf8ca6d2bcc3ddb4aaec2c851eb2c5f083e6f8", - "type": "eql", - "version": 6 - } - }, "rule_name": "Potential Suspicious File Edit", "sha256": "31e966ef88fd66e843c9134cfc92578f0c0ef1ff0b8af97d7c96049d2a31ef5b", "type": "eql", @@ -3689,7 +3038,7 @@ "3805c3dc-f82c-4f8d-891e-63c24d3102b0": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 309, "rule_name": "Attempted Bypass of Okta MFA", "sha256": "5e5251cb58730100b0cc28f80d6377c224454944d105b37cfddbc186d96993c8", @@ -3712,7 +3061,7 @@ "3838e0e3-1850-4850-a411-2e8c5ba40ba8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 214, "rule_name": "Network Connection via Certutil", "sha256": "3f6234c8ab1d36fc0aee41b20d47c226fdddafbf988fd7a990edd1967bb6c123", @@ -3770,19 +3119,12 @@ "397945f3-d39a-4e6f-8bcb-9656c2031438": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Persistence via Microsoft Outlook VBA", "sha256": "b4336a223059e535a011019a1195afac85891381ddf49844a802db5e2b477d60", "type": "eql", "version": 108 - }, - "8.13": { - "max_allowable_version": 306, - "rule_name": "Persistence via Microsoft Outlook VBA", - "sha256": "6fea9ce2228537a8fdd8bed28be66ad7dda0b6cab23977c97c5c546f0d948fdd", - "type": "eql", - "version": 208 } }, "rule_name": "Persistence via Microsoft Outlook VBA", @@ -3799,19 +3141,12 @@ "3a59fc81-99d3-47ea-8cd6-d48d561fca20": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Potential DNS Tunneling via NsLookup", "sha256": "fc1b169b413a359de4934f4cdf8bca79458b0cd5efd1a93bba0b8a05aba10b7d", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Potential DNS Tunneling via NsLookup", - "sha256": "24c29c38a11dbe12d6e222a3d69e4c47f41ad46b16d07ca3a63daba9ca761f6d", - "type": "eql", - "version": 212 } }, "rule_name": "Potential DNS Tunneling via NsLookup", @@ -3826,16 +3161,6 @@ "version": 10 }, "3a657da0-1df2-11ef-a327-f661ea17fbcc": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Rapid7 Threat Command CVEs Correlation", - "sha256": "23e49f0f8d57d3b70852d1ff51fde7a12744141f9986f4fa048aba19f7db89a1", - "type": "threat_match", - "version": 3 - } - }, "rule_name": "Rapid7 Threat Command CVEs Correlation", "sha256": "eea438035c9adcd9486112d776374a2097e248b2311e73e0feb0d239e6507a7c", "type": "threat_match", @@ -3867,16 +3192,6 @@ "version": 104 }, "3af4cb9b-973f-4c54-be2b-7623c0e21b2b": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of IP Address For GitHub User", - "sha256": "4d1bb8c98fc64a88e74bb4e5379ca7a368d1223b9cfd87c6711e8cdb55b2e93a", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of IP Address For GitHub User", "sha256": "b7131b6f584015bb7679a12da45a1e4fffb66f5030d7fb222c39607df18a2c54", "type": "new_terms", @@ -3891,19 +3206,12 @@ "3b47900d-e793-49e8-968f-c90dc3526aa1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Unusual Parent Process for cmd.exe", "sha256": "9bd527185ec4c38596e49c3a7ad276daa080ef3cf609a464de4f59e21fc1080d", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 412, - "rule_name": "Unusual Parent Process for cmd.exe", - "sha256": "fbe869ca88d432de9d48ffbb12ee20f5a623aed0aab53eba99bd3e08daf687e4", - "type": "eql", - "version": 314 } }, "rule_name": "Unusual Parent Process for cmd.exe", @@ -3914,19 +3222,12 @@ "3bc6deaa-fbd4-433a-ae21-3e892f95624f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "NTDS or SAM Database File Copied", "sha256": "e7e2e6f51e3b146d38491ba00f4d5be16be218fd4df4c1722005f294e0748e60", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "NTDS or SAM Database File Copied", - "sha256": "99608742b50911e3c5274d4ce68d799cf51f8ea8f82fb9244218fdf266a5cdbd", - "type": "eql", - "version": 216 } }, "rule_name": "NTDS or SAM Database File Copied", @@ -3959,16 +3260,6 @@ "version": 3 }, "3ca81a95-d5af-4b77-b0ad-b02bc746f640": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Unusual Pkexec Execution", - "sha256": "39004fc8c21df3175d05b13e4a85cc34c55f385af7ce819312b04b1a4df1148c", - "type": "new_terms", - "version": 3 - } - }, "rule_name": "Unusual Pkexec Execution", "sha256": "72cce527b0f0efd2f300fcd93f1c0273b4fd5476d6771008722109e0923882a1", "type": "new_terms", @@ -3977,19 +3268,12 @@ "3d00feab-e203-4acc-a463-c3e15b7e9a73": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "ScreenConnect Server Spawning Suspicious Processes", "sha256": "9a8b7d4f395146c067ba15784a025d26856d4595658268dfb01fcc8117120808", "type": "eql", "version": 5 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "ScreenConnect Server Spawning Suspicious Processes", - "sha256": "a9449e758953000ec34ebacbf23f4b51f7f9a60c0a82c08b8aa837d7b750e77a", - "type": "eql", - "version": 104 } }, "rule_name": "ScreenConnect Server Spawning Suspicious Processes", @@ -4000,7 +3284,7 @@ "3d3aa8f9-12af-441f-9344-9f31053e316d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "PowerShell Script with Log Clear Capabilities", "sha256": "8d47f5eaa5c9f058fdbe3f27d372e37c1166e236a41a1ba4383f97faa18e2972", @@ -4034,19 +3318,12 @@ "3e0eeb75-16e8-4f2f-9826-62461ca128b7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Suspicious Execution via Windows Subsystem for Linux", "sha256": "179cea119143b4ac449008db8f5bce05e743da299c57ecb9c2599d4ad223cefe", "type": "eql", "version": 9 - }, - "8.13": { - "max_allowable_version": 206, - "rule_name": "Suspicious Execution via Windows Subsystem for Linux", - "sha256": "89a4b41e934b13c0e79392e7730805f3e18c7d8cb6c3121b8b54b69a1aef8450", - "type": "eql", - "version": 108 } }, "rule_name": "Suspicious Execution via Windows Subsystem for Linux", @@ -4081,19 +3358,12 @@ "3ecbdc9e-e4f2-43fa-8cca-63802125e582": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Privilege Escalation via Named Pipe Impersonation", "sha256": "abfd83fc5f72d9b12cc92cb190d7f4e9f759d7e1b048db54399447345f56c2f1", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Privilege Escalation via Named Pipe Impersonation", - "sha256": "0b2a37b4cf28a7d2b8c35dd53c83291ceed82fe166e96bbe2678a2eb1c0b20f3", - "type": "eql", - "version": 213 } }, "rule_name": "Privilege Escalation via Named Pipe Impersonation", @@ -4104,7 +3374,7 @@ "3ed032b2-45d8-4406-bc79-7ad1eabb2c72": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Suspicious Process Creation CallTrace", "sha256": "198d879bb094b81e6bb30e836abf7c7c2a2d4b08cf6f8de140a531126de8f927", @@ -4161,23 +3431,12 @@ "version": 2 }, "3fac01b2-b811-11ef-b25b-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "Azure Entra MFA TOTP Brute Force Attempts", "sha256": "096663ac4f2f65728b65859267b7a5df52cae07f45541fc4df53d7d2c0162a1c", "type": "esql", "version": 2 }, "3fe4e20c-a600-4a86-9d98-3ecb1ef23550": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "DNF Package Manager Plugin File Creation", - "sha256": "fac0417f4ce9d3dd3a95c48c5bc2916286db6bc572c8a5e31160761ffae8cf56", - "type": "eql", - "version": 4 - } - }, "rule_name": "DNF Package Manager Plugin File Creation", "sha256": "9720e2ceb0deb64ad3773f7fb220ced4722d2586e68fffe60616480b49faf4c5", "type": "eql", @@ -4186,7 +3445,7 @@ "40155ee4-1e6a-4e4d-a63b-e8ba16980cfb": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Unusual Process Spawned by a User", "sha256": "224877a0c6c75c03df527910da6a040b10e978b5277a900b3a5ebd606e5dcebc", @@ -4200,23 +3459,12 @@ "version": 108 }, "4021e78d-5293-48d3-adee-a70fa4c18fab": { - "min_stack_version": "8.13", "rule_name": "Potential Azure OpenAI Model Theft", "sha256": "30578c829bb5b7d12461cb21a6ff53be883d722a8abb7fd76096995c7d54f268", "type": "esql", "version": 1 }, "4030c951-448a-4017-a2da-ed60f6d14f4f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "GitHub User Blocked From Organization", - "sha256": "6f42e7b01599241829e9077f402bbf6ff1ee20d99e201fb4416aeb827edbcce6", - "type": "eql", - "version": 104 - } - }, "rule_name": "GitHub User Blocked From Organization", "sha256": "5256174243858a4702bd8a6c302eec9e92971c529fa90cf3d14016b0f8e7af2e", "type": "eql", @@ -4225,19 +3473,12 @@ "403ef0d3-8259-40c9-a5b6-d48354712e49": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Unusual Persistence via Services Registry", "sha256": "f1c3d405ae61b94497a8a3b5ee7ad7b72dcadfec716c42f2975f6e18b624ec88", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Unusual Persistence via Services Registry", - "sha256": "a73f4f5a3392e6fdcae94374c133aa55cd47a2a5f09dbd25ddec84a3f5d3f29f", - "type": "eql", - "version": 211 } }, "rule_name": "Unusual Persistence via Services Registry", @@ -4252,16 +3493,6 @@ "version": 108 }, "41284ba3-ed1a-4598-bfba-a97f75d9aba2": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Unix Socket Connection", - "sha256": "66104dc588552246b0806f00f248c812a63ff54ca038949740267b9b913b3ec0", - "type": "eql", - "version": 4 - } - }, "rule_name": "Unix Socket Connection", "sha256": "2352b712067a95cbd788c45281d87669b418cd69b48f3cb97e10284c5d8b2777", "type": "eql", @@ -4270,19 +3501,12 @@ "416697ae-e468-4093-a93d-59661fa619ec": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Control Panel Process with Unusual Arguments", "sha256": "78c5895b416222839fc4b6839d36612b1a0f0e27a9024d52f91607da235123e1", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Control Panel Process with Unusual Arguments", - "sha256": "0f1715445403c50fbe30f1278c990d21dcd72f121bf8a03d91d63ff14c00a19d", - "type": "eql", - "version": 214 } }, "rule_name": "Control Panel Process with Unusual Arguments", @@ -4291,16 +3515,6 @@ "version": 315 }, "41761cd3-380f-4d4d-89f3-46d6853ee35d": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of User-Agent For a GitHub User", - "sha256": "a9f5a86fb7a36ee7d65d9e567514f2f7240710d978434b414df63e8a2255365d", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of User-Agent For a GitHub User", "sha256": "430f2a7d89f054dd07b65a39c6bc2206d60a54d4cf60987016ddc2ad868e8952", "type": "new_terms", @@ -4313,7 +3527,6 @@ "version": 104 }, "4182e486-fc61-11ee-a05d-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "AWS EC2 EBS Snapshot Shared or Made Public", "sha256": "f5901faceadcddad30aa0d48e7489446e561374f349a4bacaf544f9c5c418f6c", "type": "esql", @@ -4346,7 +3559,7 @@ "42bf698b-4738-445b-8231-c834ddefd8a0": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "Okta Brute Force or Password Spraying Attack", "sha256": "f65119ef6918a244fc9d7e77a24da44f7c9571685cd9e6c587ea87d19951038a", @@ -4369,7 +3582,7 @@ "42eeee3d-947f-46d3-a14d-7036b962c266": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "Process Creation via Secondary Logon", "sha256": "f79e046cbbec23da583f5a9a5ff0c2359af0a92b60efb6da01790d90fefb9cb9", @@ -4395,16 +3608,6 @@ "version": 101 }, "43d6ec12-2b1c-47b5-8f35-e9de65551d3b": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 107, - "rule_name": "Linux User Added to Privileged Group", - "sha256": "9ea5cc7a7d60adf681ee39ab6a1c142f5864ce9d989756808a78d1d00b5e0a1f", - "type": "eql", - "version": 9 - } - }, "rule_name": "Linux User Added to Privileged Group", "sha256": "dfd9d0ca4de23654268f056431b3427be368d9c063d5991111ed78363645dc4f", "type": "eql", @@ -4413,19 +3616,12 @@ "440e2db4-bc7f-4c96-a068-65b78da59bde": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Startup Persistence by a Suspicious Process", "sha256": "3093b3093e9dfac5593dd9dead91b15345100e95d1bca816d602302c4ad03332", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Startup Persistence by a Suspicious Process", - "sha256": "83e9d41fa1688f6e43f49b8f90e227adc1faa9a2cac3db9e262c7d452e68bc6e", - "type": "eql", - "version": 212 } }, "rule_name": "Startup Persistence by a Suspicious Process", @@ -4436,7 +3632,7 @@ "445a342e-03fb-42d0-8656-0367eb2dead5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Unusual Windows Path Activity", "sha256": "67bd807b50763f06dc6861bd1b4a7ad996afbb5766a7dc22bec1762999b6b281", @@ -4458,7 +3654,7 @@ "44fc462c-1159-4fa8-b1b7-9b6296ab4f96": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 110, "rule_name": "Multiple Vault Web Credentials Read", "sha256": "4ed1c92271f971ccdfb787166f5469edc64084f2b7ec98c1c9f03fa7103e1f23", @@ -4492,7 +3688,7 @@ "45ac4800-840f-414c-b221-53dd36a5aaf7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Windows Event Logs Cleared", "sha256": "03df4c9ba83974ad56a692f1e48ad01c5afbc399f016252d9a8f5d25442ad9c5", @@ -4508,7 +3704,7 @@ "45d273fb-1dca-457d-9855-bcb302180c21": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Encrypting Files with WinRar or 7z", "sha256": "290b151b10a6eaef87bb1d4a1dd273bd7a7c6b9c9c883d653da3bc809f159060", @@ -4524,19 +3720,12 @@ "4630d948-40d4-4cef-ac69-4002e29bc3db": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Adding Hidden File Attribute via Attrib", "sha256": "500d6f2d6faa250fea7e87e78ccb4ffc1ac323562a22fb542e4733f33c5e1d59", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Adding Hidden File Attribute via Attrib", - "sha256": "2283343e54f8b80901fdb4a190d1faa1cf29da2306750a4c22671e80269315d3", - "type": "eql", - "version": 215 } }, "rule_name": "Adding Hidden File Attribute via Attrib", @@ -4547,19 +3736,12 @@ "4682fd2c-cfae-47ed-a543-9bed37657aa6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Potential Local NTLM Relay via HTTP", "sha256": "9738558986f5eefce14d8f415a984acc7980e6eaf9211b61fbccbcf8814b2e06", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Potential Local NTLM Relay via HTTP", - "sha256": "571e3e39632376096348e94fd2d4b9cd15f049eaae21f99650d562ec0140e695", - "type": "eql", - "version": 212 } }, "rule_name": "Potential Local NTLM Relay via HTTP", @@ -4574,16 +3756,6 @@ "version": 106 }, "474fd20e-14cc-49c5-8160-d9ab4ba16c8b": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 112, - "rule_name": "System V Init Script Created", - "sha256": "c38ce796006c8f39b82f0922d30cc71ddfbe8de3d7e7fa13c58947169f07dab2", - "type": "eql", - "version": 14 - } - }, "rule_name": "System V Init Script Created", "sha256": "f1873f6d75f651d8a741c68aeb9b215cc2750c45bc137afd9a6110af092219a1", "type": "eql", @@ -4596,16 +3768,6 @@ "version": 4 }, "476267ff-e44f-476e-99c1-04c78cb3769d": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Cupsd or Foomatic-rip Shell Execution", - "sha256": "725b79909f3f199afec5b728eac38e0b2be9545c1c9fb3963576649af48a2e7a", - "type": "eql", - "version": 3 - } - }, "rule_name": "Cupsd or Foomatic-rip Shell Execution", "sha256": "eb912e24c46ec2f35d9be99c411eb107c6f6cd1ad27b962d4130668320e98388", "type": "eql", @@ -4614,7 +3776,7 @@ "47e22836-4a16-4b35-beee-98f6c4ee9bf2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Suspicious Remote Registry Access via SeBackupPrivilege", "sha256": "1715a0e265def59183c4652ae4742b17cc3578a5d1132831b499ce28f0c7c4a2", @@ -4642,19 +3804,12 @@ "483c4daf-b0c6-49e0-adf3-0bfa93231d6b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Microsoft Exchange Server UM Spawning Suspicious Processes", "sha256": "60cb1aafa8d037f564143057fa316c87b326346f698ec418f9301fe073ccfc7c", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Microsoft Exchange Server UM Spawning Suspicious Processes", - "sha256": "b3690c2cb340baf77c176fc9260e8a138d3d86d5be1255fea5db6edd29d029c5", - "type": "eql", - "version": 212 } }, "rule_name": "Microsoft Exchange Server UM Spawning Suspicious Processes", @@ -4677,7 +3832,7 @@ "48b6edfc-079d-4907-b43c-baffa243270d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "Multiple Logon Failure from the same Source Address", "sha256": "d3b2f8128fcad0de701a9aa48b9d8f5259837ff59505a81935bc2e5b6d3f3c38", @@ -4711,20 +3866,10 @@ "493834ca-f861-414c-8602-150d5505b777": { "rule_name": "Agent Spoofing - Multiple Hosts Using Same Agent", "sha256": "6144987feeea5f57fa67484e121452ca28b0a522c8ee105f48e14de7fd4ef115", - "type": "threshold", - "version": 103 - }, - "494ebba4-ecb7-4be4-8c6f-654c686549ad": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 107, - "rule_name": "Potential Linux Backdoor User Account Creation", - "sha256": "e9fba7cb50d7c0edfe213e52665e64b9fbaf596bbc274d66c2677a16b6524e00", - "type": "eql", - "version": 9 - } - }, + "type": "threshold", + "version": 103 + }, + "494ebba4-ecb7-4be4-8c6f-654c686549ad": { "rule_name": "Potential Linux Backdoor User Account Creation", "sha256": "691cfec23b704e2589edfb62980284fec4ac438776a1a88edb7605ee5e54698f", "type": "eql", @@ -4745,7 +3890,7 @@ "4982ac3e-d0ee-4818-b95d-d9522d689259": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Process Discovery Using Built-in Tools", "sha256": "d6a6479c0c7905bb1f2dd6b93ad2e973b02944bfa46b720e228d49bb15ccb7ec", @@ -4765,16 +3910,6 @@ "version": 107 }, "4a99ac6f-9a54-4ba5-a64f-6eb65695841b": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 104, - "rule_name": "Potential Unauthorized Access via Wildcard Injection Detected", - "sha256": "2bfb9d1c293185db7cebfaf6649ecce4d26ca6bd6e8f6fb252e811960272d4e7", - "type": "eql", - "version": 6 - } - }, "rule_name": "Potential Unauthorized Access via Wildcard Injection Detected", "sha256": "6496b33df954b86a762df6202f068d413cf231e273ca8e1a2c0ceefa6e1d127a", "type": "eql", @@ -4795,19 +3930,12 @@ "4b438734-3793-4fda-bd42-ceeada0be8f9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Disable Windows Firewall Rules via Netsh", "sha256": "5f73d21d945760cc5f0e2e9e4f3a20183956cd20ac5963505a49fc7c29dd290a", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Disable Windows Firewall Rules via Netsh", - "sha256": "71f49bcedcd05061a38576f6d9093f3b6b397fb89b780ddaeeb881c146979a84", - "type": "eql", - "version": 212 } }, "rule_name": "Disable Windows Firewall Rules via Netsh", @@ -4822,16 +3950,6 @@ "version": 6 }, "4b868f1f-15ff-4ba3-8c11-d5a7a6356d37": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "ProxyChains Activity", - "sha256": "6d2bb84fbddf0c3a063f3b83fe3182017edbe19020c1e1dafc558ec07a767a0b", - "type": "eql", - "version": 5 - } - }, "rule_name": "ProxyChains Activity", "sha256": "3ddce01b59f5987dd1a83755af79e6e993de5f67f97b960b4b2b544be9e1609a", "type": "eql", @@ -4846,19 +3964,12 @@ "4bd1c1af-79d4-4d37-9efa-6e0240640242": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Unusual Process Execution Path - Alternate Data Stream", "sha256": "c6c357f72dda9ad192ec0f1297502bd068bf0cbdcc97ab58e49d86e7cfdde988", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Unusual Process Execution Path - Alternate Data Stream", - "sha256": "57c2b49691db8ebbed599f9985cf9d43545ea46a7e458dd4a28bd20f0f0476ca", - "type": "eql", - "version": 210 } }, "rule_name": "Unusual Process Execution Path - Alternate Data Stream", @@ -4875,7 +3986,7 @@ "4c59cff1-b78a-41b8-a9f1-4231984d1fb6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 110, "rule_name": "PowerShell Share Enumeration Script", "sha256": "95583fef64f6c5454d616320d43ceda2a467cb8e217231374faa423e8363fdf1", @@ -4889,16 +4000,6 @@ "version": 111 }, "4d4c35f4-414e-4d0c-bb7e-6db7c80a6957": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Kernel Load or Unload via Kexec Detected", - "sha256": "d477a1c1cf4b80c1c4b058813b66f4952e183bd224d21bd44d145c7845ff027f", - "type": "eql", - "version": 8 - } - }, "rule_name": "Kernel Load or Unload via Kexec Detected", "sha256": "f8166b3c126f6350077c04381eff45f180452c93b70be54c18aa91ff15e512f0", "type": "eql", @@ -4919,19 +4020,12 @@ "4de76544-f0e5-486a-8f84-eae0b6063cdc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Disable Windows Event and Security Logs Using Built-in Tools", "sha256": "214f871b4ac72ba8d644b997c7991d4b88cfc32320409761af37fcb8717ce0a7", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Disable Windows Event and Security Logs Using Built-in Tools", - "sha256": "d6cd69282faee07d4379290d7a9b450bf5743e257e64562c47f8cb180ad3e5f4", - "type": "eql", - "version": 214 } }, "rule_name": "Disable Windows Event and Security Logs Using Built-in Tools", @@ -4942,7 +4036,7 @@ "4e85dc8a-3e41-40d8-bc28-91af7ac6cf60": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 110, "rule_name": "Multiple Logon Failure Followed by Logon Success", "sha256": "a850bf83897d0291d578f2f0ac69c11ed4288d5da688c63475e863bfc7edebc4", @@ -4956,16 +4050,6 @@ "version": 113 }, "4ec47004-b34a-42e6-8003-376a123ea447": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 109, - "rule_name": "Process Spawned from Message-of-the-Day (MOTD)", - "sha256": "26c209b252768d129ab5bccfb4006456a5cd64d7ed097dd81d513beb333d8d7e", - "type": "eql", - "version": 11 - } - }, "rule_name": "Process Spawned from Message-of-the-Day (MOTD)", "sha256": "f680d6c8ee7249b89249a6710ce30801b2c982cef68f015538d7cfac8430cc94", "type": "eql", @@ -4974,19 +4058,12 @@ "4ed493fc-d637-4a36-80ff-ac84937e5461": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Execution via MSSQL xp_cmdshell Stored Procedure", "sha256": "706691106e2a013f1cf173681567fcb4f84c44db8406ee24fd96b866d5d17888", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Execution via MSSQL xp_cmdshell Stored Procedure", - "sha256": "dbce5c4fe73c141fb1017f8304b12ad1eef85b8956b21b7d8ab9fe9470bdf390", - "type": "eql", - "version": 213 } }, "rule_name": "Execution via MSSQL xp_cmdshell Stored Procedure", @@ -4997,7 +4074,7 @@ "4ed678a9-3a4f-41fb-9fea-f85a6e0a0dff": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Suspicious Script Object Execution", "sha256": "d03461949ea02ae5d1a9afa32408fcc350c90751725cecedddb19bc153f58ba7", @@ -5013,7 +4090,7 @@ "4edd3e1a-3aa0-499b-8147-4d2ea43b1613": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Unauthorized Access to an Okta Application", "sha256": "7c9a2609b0c927d2b54d9609d677f0379515475dbcb523900a3bab9c18910f63", @@ -5040,7 +4117,6 @@ "version": 3 }, "4f855297-c8e0-4097-9d97-d653f7e471c4": { - "min_stack_version": "8.13", "rule_name": "Unusual High Confidence Content Filter Blocks Detected", "sha256": "c2e729e23f37d687504d5c86cb91f01a1d9363cd489f06a54723e557f02903cd", "type": "esql", @@ -5049,19 +4125,12 @@ "4fe9d835-40e1-452d-8230-17c147cafad8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Execution via TSClient Mountpoint", "sha256": "9ff2cb9dd5ea847ba0e865edd15a145b5015f7bfd5601d9a07a3ad7c4aa13b0c", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Execution via TSClient Mountpoint", - "sha256": "b2c9ec4c6421a7af0b6c97d70741ef5f1274b2a973dde460f3469cb59b8a37d4", - "type": "eql", - "version": 214 } }, "rule_name": "Execution via TSClient Mountpoint", @@ -5072,7 +4141,7 @@ "50887ba8-7ff7-11ee-a038-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Multiple Okta User Auth Events with Same Device Token Hash Behind a Proxy", "sha256": "3fd4abe84fade840ddabfa0b4a59937c3d0c030a1681cc96bef3b4c37db789f7", @@ -5101,7 +4170,7 @@ "51176ed2-2d90-49f2-9f3d-17196428b169": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Windows System Information Discovery", "sha256": "17e4aea652e17a149717afe81d8d917e26f0dbd3d4cad9923c0e7cb71eac92e7", @@ -5115,16 +4184,6 @@ "version": 109 }, "5124e65f-df97-4471-8dcb-8e3953b3ea97": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Hidden Files and Directories via Hidden Flag", - "sha256": "48ab779e161fbd3bfc978ec8def0e6511023cebad2f6c5874cc71cd14d2da1d4", - "type": "eql", - "version": 4 - } - }, "rule_name": "Hidden Files and Directories via Hidden Flag", "sha256": "b33bbf177156fd682cccd98b3b5e214c494c17ac29770c3ef6e211cd2b8f26f9", "type": "eql", @@ -5133,19 +4192,12 @@ "513f0ffd-b317-4b9c-9494-92ce861f22c7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Registry Persistence via AppCert DLL", "sha256": "13b9667f77ece11fa75c760717a7f1a7474e6cf3583c6d428b0b835bbb79c161", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 411, - "rule_name": "Registry Persistence via AppCert DLL", - "sha256": "4605f205b084980b9052a6f82ff9ace18abaddddba5a0901b25ee42d0a048865", - "type": "eql", - "version": 313 } }, "rule_name": "Registry Persistence via AppCert DLL", @@ -5168,19 +4220,12 @@ "5188c68e-d3de-4e96-994d-9e242269446f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Service DACL Modification via sc.exe", "sha256": "0103f881f5ee4e7c9d82ed15157325d5b5a58d4e397d6367d4da02bbf8ce0034", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Service DACL Modification via sc.exe", - "sha256": "f3deede5cd5976b88fba9f4fe5814c558ca142f46001382dd888e8f1294a9892", - "type": "eql", - "version": 104 } }, "rule_name": "Service DACL Modification via sc.exe", @@ -5197,7 +4242,7 @@ "51ce96fb-9e52-4dad-b0ba-99b54440fc9a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Incoming DCOM Lateral Movement with MMC", "sha256": "341be9c43bad17537b54fdc7f40f8c156c772443e30caf8193c825ef8ae6e632", @@ -5237,7 +4282,7 @@ "52aaab7b-b51c-441a-89ce-4387b3aea886": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Unusual Network Connection via RunDLL32", "sha256": "30b9af8ec0f1c7c96bfc668ec005cc11e6b68a9d649ea1270b7f576bc393b37b", @@ -5301,19 +4346,12 @@ "53a26770-9cbd-40c5-8b57-61d01a325e14": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Suspicious PDF Reader Child Process", "sha256": "33313501aab3ebd4c97177b9d2f9462691e4c62a10efc4c19fc3417517abfbcf", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Suspicious PDF Reader Child Process", - "sha256": "c1564d323c28e030be7c14bef921f65cc3c1eaa43178ee7dae1db64c56d0f89b", - "type": "eql", - "version": 213 } }, "rule_name": "Suspicious PDF Reader Child Process", @@ -5324,7 +4362,7 @@ "53dedd83-1be7-430f-8026-363256395c8b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Binary Content Copy via Cmd.exe", "sha256": "83eb2f905a505910e8693162369ba3f7e06a7c2f331aa002af5bb31379c6e46d", @@ -5346,7 +4384,7 @@ "54902e45-3467-49a4-8abc-529f2c8cfb80": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Uncommon Registry Persistence Change", "sha256": "44240eefb782b212aa0e92aa499c5c53a15dd47c2d5ccd8d5bbd7e730a2ced0d", @@ -5362,7 +4400,7 @@ "54a81f68-5f2a-421e-8eed-f888278bb712": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Exchange Mailbox Export via PowerShell", "sha256": "e09d7504c58220644bf1c098939cbcec1d55363c7d058a31754ae18efb66dc74", @@ -5378,7 +4416,7 @@ "54c3d186-0461-4dc3-9b33-2dc5c7473936": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Network Logon Provider Registry Modification", "sha256": "c1d15e3f87d0c06656e38903de062e3f17bdbd3884c26fd330cb747036019545", @@ -5394,7 +4432,7 @@ "55c2bf58-2a39-4c58-a384-c8b1978153c2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Windows Service Installed via an Unusual Client", "sha256": "24bc059a551799ed770e0ee2992748c8016fcfa722ee640541fdedaa89f5f742", @@ -5410,7 +4448,7 @@ "55d551c6-333b-4665-ab7e-5d14a59715ce": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "PsExec Network Connection", "sha256": "b8614692008af5d487ed9f78c60675e92dacc3a24fce20a66b3c3b9fd0567f66", @@ -5432,7 +4470,7 @@ "56004189-4e69-4a39-b4a9-195329d226e9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Unusual Process Spawned by a Host", "sha256": "20041d45b1675b29ac029036acb9a791d296507da6fc2d342c22e8ae9d37add9", @@ -5448,7 +4486,7 @@ "5610b192-7f18-11ee-825b-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Stolen Credentials Used to Login to Okta Account After MFA Reset", "sha256": "ec566f4e3388dd1ab9134b4f1fd960d63dab606c6ad5802edbbc41f539136c3f", @@ -5471,7 +4509,7 @@ "56557cde-d923-4b88-adee-c61b3f3b5dc3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall)", "sha256": "844fb3c0e49c833039ab4433243235fa41c2d67fe700084b9c97c8c5d547ccf1", @@ -5505,7 +4543,7 @@ "56f2e9b5-4803-4e44-a0a4-a52dc79d57fe": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "PowerShell PSReflect Script", "sha256": "9075bac2c658f9cd09ae5480d64a0005ed4877f273b113b12c5c9d38098e5c35", @@ -5545,7 +4583,7 @@ "577ec21e-56fe-4065-91d8-45eb8224fe77": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "PowerShell MiniDump Script", "sha256": "e3e3e2fe5144a3499378aee5b2b69396812d7753cec0e05000a5910187f5684b", @@ -5561,7 +4599,7 @@ "57bccf1d-daf5-4e1a-9049-ff79b5254704": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "File Staged in Root Folder of Recycle Bin", "sha256": "314fd493ccc29a7d204cbc4bd9b1fee4617aab19751fa9b6d304348f028bc6eb", @@ -5577,19 +4615,12 @@ "57bfa0a9-37c0-44d6-b724-54bf16787492": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "DNS Global Query Block List Modified or Disabled", "sha256": "7d36f22f3ea3b4008813322aadd11c5d337d890ad99892df41b2e3154c755ed8", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "DNS Global Query Block List Modified or Disabled", - "sha256": "fdd70a684195301172c2093025954070437de67b7110b4c2fd82167df76f3b5d", - "type": "eql", - "version": 104 } }, "rule_name": "DNS Global Query Block List Modified or Disabled", @@ -5600,19 +4631,12 @@ "581add16-df76-42bb-af8e-c979bfb39a59": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Deleting Backup Catalogs with Wbadmin", "sha256": "6165559b4653bf1ee1706a1331a547f918100b0ced5790793d5e5ba4d729ede0", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Deleting Backup Catalogs with Wbadmin", - "sha256": "26274955479837e6e770a906ce9ccdae8b70df5dbfa218c458061353440320d2", - "type": "eql", - "version": 214 } }, "rule_name": "Deleting Backup Catalogs with Wbadmin", @@ -5623,19 +4647,12 @@ "58aa72ca-d968-4f34-b9f7-bea51d75eb50": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "RDP Enabled via Registry", "sha256": "cc3b7feb0e1ccaa779028782f8c1ca3d74ab3205d07bed48fd41e36f7a0e35a1", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "RDP Enabled via Registry", - "sha256": "ad5f6e2a7ed2a334c068a318cce1628f5eba03cc5188384b8936624810b633fa", - "type": "eql", - "version": 212 } }, "rule_name": "RDP Enabled via Registry", @@ -5692,16 +4709,6 @@ "version": 2 }, "5a138e2e-aec3-4240-9843-56825d0bc569": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "IPv4/IPv6 Forwarding Activity", - "sha256": "8662d51b058ba0aaa8beb626fa104c2c7f6ee6f1970db79c6ab2615a567e699f", - "type": "eql", - "version": 2 - } - }, "rule_name": "IPv4/IPv6 Forwarding Activity", "sha256": "8396ecbd7798a0b4e17254a7e80dffd7b731859eb3d11dbb07f51ddbfdad095e", "type": "eql", @@ -5710,19 +4717,12 @@ "5a14d01d-7ac8-4545-914c-b687c2cf66b3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "UAC Bypass Attempt via Privileged IFileOperation COM Interface", "sha256": "195101291410db100f83b2bbb0bb45a23a5d3c84f0b3cc59e3e80543531dd5e1", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "UAC Bypass Attempt via Privileged IFileOperation COM Interface", - "sha256": "2213291fff0bb1ba56efbcc8b9b3bbeca328b89b52cf3e419b4fb6e70936dad0", - "type": "eql", - "version": 210 } }, "rule_name": "UAC Bypass Attempt via Privileged IFileOperation COM Interface", @@ -5743,16 +4743,6 @@ "version": 2 }, "5ae02ebc-a5de-4eac-afe6-c88de696477d": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Potential Chroot Container Escape via Mount", - "sha256": "bf4217022061a7456c301cffe1ab6dd6d9298a3c45e206c125c42667862de6e1", - "type": "eql", - "version": 3 - } - }, "rule_name": "Potential Chroot Container Escape via Mount", "sha256": "135b3d3e2b3be70b8da8cfd2806556b9b14bc02f669d6789237a56b36d345398", "type": "eql", @@ -5767,19 +4757,12 @@ "5aee924b-6ceb-4633-980e-1bde8cdb40c5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Potential Secure File Deletion via SDelete Utility", "sha256": "b6aed219192c8865a107b6529d4d67d837edb4ed446fb8d026683108c4fbcd30", "type": "eql", "version": 109 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Potential Secure File Deletion via SDelete Utility", - "sha256": "f758d94665be51996867211777d79e6aed92bf1caef03e695a48519325656443", - "type": "eql", - "version": 209 } }, "rule_name": "Potential Secure File Deletion via SDelete Utility", @@ -5800,16 +4783,6 @@ "version": 8 }, "5b18eef4-842c-4b47-970f-f08d24004bde": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Suspicious which Enumeration", - "sha256": "81bdb21ca450212add8a85c321bb3987998e8f5dada389fbc8a46fa1d740581c", - "type": "eql", - "version": 8 - } - }, "rule_name": "Suspicious which Enumeration", "sha256": "8c27bb4dfd65956ad41dd52d71f7c946aaf21e52ea1956d82fe54231ac8a17f1", "type": "eql", @@ -5830,19 +4803,12 @@ "5bb4a95d-5a08-48eb-80db-4c3a63ec78a8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Suspicious PrintSpooler Service Executable File Creation", "sha256": "35874a6b3415659603a51352ab4aafe03d8e2d816f25c4f343115687e555aa00", "type": "new_terms", "version": 115 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "Suspicious PrintSpooler Service Executable File Creation", - "sha256": "5ca5d9dba9c3eda093b2a3b2260982c127108c3167436867c912cf29f5129f87", - "type": "new_terms", - "version": 215 } }, "rule_name": "Suspicious PrintSpooler Service Executable File Creation", @@ -5851,7 +4817,6 @@ "version": 315 }, "5bda8597-69a6-4b9e-87a2-69a7c963ea83": { - "min_stack_version": "8.13", "rule_name": "Boot File Copy", "sha256": "24d0894ed6959d5f54396c957e8dcd3de231026e473c753ef10c5c033f991857", "type": "eql", @@ -5884,7 +4849,7 @@ "5c602cba-ae00-4488-845d-24de2b6d8055": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "PowerShell Script with Veeam Credential Access Capabilities", "sha256": "5ae470e75de9bdbb84070a55c7cfbd9143654a72f9e9193782aea6145b12fd1e", @@ -5900,7 +4865,7 @@ "5c6f4c58-b381-452a-8976-f1b1c6aa0def": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 112, "rule_name": "FirstTime Seen Account Performing DCSync", "sha256": "7183be4ca315578faaa377e9a60195ad188e37db8da8a104b351536251c77267", @@ -5920,16 +4885,6 @@ "version": 1 }, "5c832156-5785-4c9c-a2e7-0d80d2ba3daa": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Pluggable Authentication Module (PAM) Creation in Unusual Directory", - "sha256": "5236ec39f5b96c9f3b575a920dbd695b7473c5bafe7625e03799f60d559b28e9", - "type": "eql", - "version": 2 - } - }, "rule_name": "Pluggable Authentication Module (PAM) Creation in Unusual Directory", "sha256": "23f889cc4747d5ad5d505549b4301b18abb715f10d21b48a1c87dbd95cef2f29", "type": "eql", @@ -5948,16 +4903,6 @@ "version": 105 }, "5c9ec990-37fa-4d5c-abfc-8d432f3dedd0": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Potential Defense Evasion via PRoot", - "sha256": "5be300eea96d7d3fff01d8e2f1ce70318e82a027159669467454f10cf243e208", - "type": "eql", - "version": 8 - } - }, "rule_name": "Potential Defense Evasion via PRoot", "sha256": "c5995d0265ad4c7e35124856effd41c95caad3e3178a67f3c5bc6122df89e317", "type": "eql", @@ -5966,7 +4911,7 @@ "5cd55388-a19c-47c7-8ec4-f41656c2fded": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Outbound Scheduled Task Activity via PowerShell", "sha256": "881e17596c2ce4e314625942adb04235a12e70f19501ddbf53391bfe02dd03f9", @@ -5982,7 +4927,7 @@ "5cd8e1f7-0050-4afc-b2df-904e40b2f5ae": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "User Added to Privileged Group", "sha256": "70bef882918b9abe618227f6f577a2900d5d565d841c12e47a5347e679d614d3", @@ -5998,19 +4943,12 @@ "5cf6397e-eb91-4f31-8951-9f0eaa755a31": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Persistence via PowerShell profile", "sha256": "e2a9084a8e3062415cf21a33d22098b3e31cd354006e57075af67e820641af92", "type": "eql", "version": 10 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "Persistence via PowerShell profile", - "sha256": "0383a8c5a6705916613f80d301ca0dea35cf7ff7cb13b719320e19c6dfeaffb4", - "type": "eql", - "version": 110 } }, "rule_name": "Persistence via PowerShell profile", @@ -6027,7 +4965,7 @@ "5d1d6907-0747-4d5d-9b24-e4a18853dc0a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Suspicious Execution via Scheduled Task", "sha256": "975967ec3e4989e05b906196e1492ea1f24ac1162211d54845e8c1f682036f71", @@ -6043,7 +4981,7 @@ "5d676480-9655-4507-adc6-4eec311efff8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Unsigned DLL loaded by DNS Service", "sha256": "8f2d6fb941f3e9f2fe599164f806804b1b09b4c08131d79eb3e7ecaab5034c05", @@ -6069,16 +5007,6 @@ "version": 107 }, "5e4023e7-6357-4061-ae1c-9df33e78c674": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Memory Swap Modification", - "sha256": "d3233c88cf4a2b91daeca4e6247bb3758023b234d009f522b19223f87aeae20f", - "type": "eql", - "version": 2 - } - }, "rule_name": "Memory Swap Modification", "sha256": "9b2b90fcdbd4c8d61fb415c8648a5fbb45acf0f721bc6639adae981cb9d9ce1c", "type": "eql", @@ -6097,7 +5025,6 @@ "version": 100 }, "5f0234fd-7f21-42af-8391-511d5fd11d5c": { - "min_stack_version": "8.13", "rule_name": "AWS S3 Bucket Enumeration or Brute Force", "sha256": "e65db1e4cf78b27ce4ca6092bbbb6900c749dbda0d96ee608ec1954757cb9862", "type": "esql", @@ -6106,19 +5033,12 @@ "5f2f463e-6997-478c-8405-fb41cc283281": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Potential File Download via a Headless Browser", "sha256": "4d8ace1351c9ae35691f8b6021a49e99b73411ceef1141b2991a256639c06fc2", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "Potential File Download via a Headless Browser", - "sha256": "5bd523abcb57834d143196bb1efad15e311915b353c6a8159fabd756bae168b3", - "type": "eql", - "version": 103 } }, "rule_name": "Potential File Download via a Headless Browser", @@ -6153,7 +5073,7 @@ "610949a1-312f-4e04-bb55-3a79b8c95267": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Unusual Process Network Connection", "sha256": "be0a23cd5db1b1e9744ba6f8cfcbf419e70e2759108952394b4fd53a17da615c", @@ -6167,16 +5087,6 @@ "version": 208 }, "61336fe6-c043-4743-ab6e-41292f439603": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "New User Added To GitHub Organization", - "sha256": "90e535bf6daf394c14fb7d463f3a44120bd3a7a8df82406b1481123c490c23e8", - "type": "eql", - "version": 104 - } - }, "rule_name": "New User Added To GitHub Organization", "sha256": "2c3b9ea33c3871c5cd9de7aa8d9393e10da0eae719587560cacb5d0c445e6dd4", "type": "eql", @@ -6185,7 +5095,7 @@ "61766ef9-48a5-4247-ad74-3349de7eb2ad": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Interactive Logon by an Unusual Process", "sha256": "132f771ca6058156fbc2c515ad591010a1372d2130f37e7a4b0526d53e0d792f", @@ -6201,7 +5111,7 @@ "61ac3638-40a3-44b2-855a-985636ca985e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "PowerShell Suspicious Discovery Related Windows API Functions", "sha256": "4674c3f02c5b785102dd9e8a442c1cb0f8c3692d1e1ab3997c6c1e52679754b8", @@ -6223,7 +5133,7 @@ "61d29caf-6c15-4d1e-9ccb-7ad12ccc0bc7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "AdminSDHolder SDProp Exclusion Added", "sha256": "2df55d0ae697d20c47f22d5c616f9c06bb6c4c9fbac2aebb282caa3d9f7e4e1b", @@ -6239,7 +5149,7 @@ "621e92b6-7e54-11ee-bdc0-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Multiple Okta Sessions Detected for a Single User", "sha256": "f472608d534083bdf5f50a92951a81599a2b3dce40e413de960019aa9f7435f5", @@ -6262,7 +5172,7 @@ "622ecb68-fa81-4601-90b5-f8cd661e4520": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Incoming DCOM Lateral Movement via MSHTA", "sha256": "facf2b369187ce8da1649950be8b3e38f3c4c1ec81f490fa646827baf5d2427a", @@ -6276,16 +5186,6 @@ "version": 208 }, "627374ab-7080-4e4d-8316-bef1122444af": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Private Key Searching Activity", - "sha256": "d14cd033b213dd2aa22e191e4316a3e9399efede1e2a54e6b84c28fc98e43248", - "type": "eql", - "version": 2 - } - }, "rule_name": "Private Key Searching Activity", "sha256": "ac4b591b30cbfb1cecd4fab9a4c521aa12bf95897eab976edf79d520b5eeedfc", "type": "eql", @@ -6294,7 +5194,7 @@ "62a70f6f-3c37-43df-a556-f64fa475fba2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Account Configured with Never-Expiring Password", "sha256": "7d8a44d4634bce7a7e5cbf983f840157836ac6945cc140dda1a4f4a3b3b0717d", @@ -6314,7 +5214,6 @@ "version": 6 }, "63153282-12da-415f-bad8-c60c9b36cbe3": { - "min_stack_version": "8.13", "rule_name": "Process Backgrounded by Unusual Parent", "sha256": "208219618907f9af2a97a782d360496106265946d0d6b37aa5eb4369f2bd210a", "type": "new_terms", @@ -6353,7 +5252,7 @@ "63e65ec3-43b1-45b0-8f2d-45b34291dc44": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Network Connection via Signed Binary", "sha256": "66192fcde84de1d9b0e809854015279f1016447b2e2de3d0f3f81aad88df91bf", @@ -6399,19 +5298,12 @@ "65432f4a-e716-4cc1-ab11-931c4966da2d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "MsiExec Service Child Process With Network Connection", "sha256": "0dec5c209de4432366d522c8479caa203fc027282bbca7df21df60a9a9ff41e1", "type": "eql", "version": 2 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "MsiExec Service Child Process With Network Connection", - "sha256": "fae229cedfaca7b7e8f9a7e40a573cc0933889bf6fd0a9add01469c2f12bd0bd", - "type": "eql", - "version": 102 } }, "rule_name": "MsiExec Service Child Process With Network Connection", @@ -6440,7 +5332,7 @@ "6649e656-6f85-11ef-8876-f661ea17fbcc": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials", "sha256": "45313bcc54d11c7433f8c8ef41f60e3119084e324e71751db6bb9fb549a3f1b4", @@ -6463,7 +5355,7 @@ "665e7a4f-c58e-4fc6-bc83-87a7572670ac": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "WebServer Access Logs Deleted", "sha256": "3d41e0a751de0eefc517ae323b3602930bdfa24fbf61b7c15235e4be117511ac", @@ -6489,16 +5381,6 @@ "version": 117 }, "66c058f3-99f4-4d18-952b-43348f2577a0": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Linux Process Hooking via GDB", - "sha256": "d6069d2128de9e65240d1c2a03f27f397f632fbdb78102892e58b51e395c942a", - "type": "eql", - "version": 4 - } - }, "rule_name": "Linux Process Hooking via GDB", "sha256": "6124499edac0ee53fc52e4a4b588db2d5747ae4fb3770c91307fd25814704939", "type": "eql", @@ -6513,7 +5395,7 @@ "670b3b5a-35e5-42db-bd36-6c5b9b4b7313": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 112, "rule_name": "Modification of the msPKIAccountCredentials", "sha256": "a2b0e85ea8b810a2ed22188f8d14303a6077c51b2edeaf8e5f5007a0c9644381", @@ -6529,7 +5411,7 @@ "6731fbf2-8f28-49ed-9ab9-9a918ceb5a45": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Modify an Okta Policy", "sha256": "5f3b2cab91a23497765bc0fae4150faf15cabcee773619d90db0cd3edbdb1473", @@ -6558,7 +5440,7 @@ "676cff2b-450b-4cf1-8ed2-c0c58a4a2dd7": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Revoke Okta API Token", "sha256": "2beaa220e872f7c47a050dd650ebe4576eafc89a94944115406a4f6b6692a213", @@ -6599,19 +5481,12 @@ "6839c821-011d-43bd-bd5b-acff00257226": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Image File Execution Options Injection", "sha256": "8107c66fd0a677b8966bf0f40409dfdac75050d7a2372a8e4ba10ce0350e6dfd", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Image File Execution Options Injection", - "sha256": "2eb29b66dbef8063acbd04479aaeb1f14fc4d5f7235afe9076fdfc86d199e837", - "type": "eql", - "version": 210 } }, "rule_name": "Image File Execution Options Injection", @@ -6628,7 +5503,7 @@ "6885d2ae-e008-4762-b98a-e8e1cd3a81e9": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Okta ThreatInsight Threat Suspected Promotion", "sha256": "465ed6fbfaa4576c8e9945c4d9ae53d4c2bcee360bb998f6c0ba5454d2c5a4bd", @@ -6651,19 +5526,12 @@ "68921d85-d0dc-48b3-865f-43291ca2c4f2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Persistence via TelemetryController Scheduled Task Hijack", "sha256": "fb1c6b89350f0562319e1eaccabc46a2a855fb936516da145a6c640de6692808", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Persistence via TelemetryController Scheduled Task Hijack", - "sha256": "8ef4dbaed0d772335a6ecbc53e69cdd287bf9e163b38772bcb8865cc4488b8a5", - "type": "eql", - "version": 213 } }, "rule_name": "Persistence via TelemetryController Scheduled Task Hijack", @@ -6680,7 +5548,7 @@ "689b9d57-e4d5-4357-ad17-9c334609d79a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Scheduled Task Created by a Windows Script", "sha256": "a55f600e7c4e20a4be4404040ef2bc40bd6288c5aa54fc3a6d52c192f117858e", @@ -6702,7 +5570,7 @@ "68ad737b-f90a-4fe5-bda6-a68fa460044e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Suspicious Access to LDAP Attributes", "sha256": "3f6e6dde427189d7e561da47cb689604201870715612cc80e8bc8f4247d1a7c6", @@ -6724,7 +5592,7 @@ "68d56fdc-7ffa-4419-8e95-81641bd6f845": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "UAC Bypass via ICMLuaUtil Elevated COM Interface", "sha256": "88f491fbc91172a9ce530e464d3e41d098720ae427782544b68895129cdc1564", @@ -6744,7 +5612,6 @@ "version": 107 }, "696015ef-718e-40ff-ac4a-cc2ba88dbeeb": { - "min_stack_version": "8.13", "rule_name": "AWS IAM User Created Access Keys For Another User", "sha256": "6f69dc6e309b86b281bd3f02594a03d86ba15d5835011a2b37a7ce21f3da291d", "type": "esql", @@ -6765,19 +5632,12 @@ "69c251fb-a5d6-4035-b5ec-40438bd829ff": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Modification of Boot Configuration", "sha256": "ccaafef97b4bdf8ae36b9c2337353a7b352d18f0aeb421cddbace9a8b130b15e", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Modification of Boot Configuration", - "sha256": "6d87681179c69071fef468569680dec1534f711bc8955e8b6bd0c7c1f1865e61", - "type": "eql", - "version": 211 } }, "rule_name": "Modification of Boot Configuration", @@ -6792,16 +5652,6 @@ "version": 207 }, "6a058ed6-4e9f-49f3-8f8e-f32165ae7ebf": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Attempt to Disable Auditd Service", - "sha256": "f5fa9bfd7d9d2f03fb2e6f1b264a7b0f0f433bfb3953f27bed2afda53a7af098", - "type": "eql", - "version": 2 - } - }, "rule_name": "Attempt to Disable Auditd Service", "sha256": "a21ae8ad2d9a9aa7f634479e7b2fdea05a56714d0e14c6541044895377b4f628", "type": "eql", @@ -6816,19 +5666,12 @@ "6a8ab9cc-4023-4d17-b5df-1a3e16882ce7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Unusual Service Host Child Process - Childless Service", "sha256": "5f2f1310bff01d3a4c1ca2605ab01c632f85b21d4078a06cb88c4ffeabc174ff", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Unusual Service Host Child Process - Childless Service", - "sha256": "0b7fffd5409c0d916c6b441f0f6eb2c95550d8c5c9d74192d312b7ec442372ac", - "type": "eql", - "version": 211 } }, "rule_name": "Unusual Service Host Child Process - Childless Service", @@ -6839,19 +5682,12 @@ "6aace640-e631-4870-ba8e-5fdda09325db": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Exporting Exchange Mailbox via PowerShell", "sha256": "9c37ce484fd50f922517f40b9bd1a5a55b402537ccb8f7e8f0b06c3b83261bf7", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 415, - "rule_name": "Exporting Exchange Mailbox via PowerShell", - "sha256": "7c60b373a1ff43f76c7bd51cf35948ea0b81fc7b62b8615816088d88f52bd9b9", - "type": "eql", - "version": 317 } }, "rule_name": "Exporting Exchange Mailbox via PowerShell", @@ -6860,23 +5696,12 @@ "version": 418 }, "6ace94ba-f02c-4d55-9f53-87d99b6f9af4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Suspicious Utility Launched via ProxyChains", - "sha256": "1c1d57466f2540ce62774922d5711359a9650bd523baf98fa3d13d5c17151881", - "type": "eql", - "version": 8 - } - }, "rule_name": "Suspicious Utility Launched via ProxyChains", "sha256": "7ed5babe4ccddd47a42992b6b092c794c17adfe49c0418a399fb645487d38e68", "type": "eql", "version": 109 }, "6b341d03-1d63-41ac-841a-2009c86959ca": { - "min_stack_version": "8.13", "rule_name": "Potential Port Scanning Activity from Compromised Host", "sha256": "74d1c8ea528608283c391f89ec9ff4dde0f4b2322eaa210dd37ca0602055b311", "type": "esql", @@ -6891,7 +5716,7 @@ "6bed021a-0afb-461c-acbe-ffdb9574d3f3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Remote Computer Account DnsHostName Update", "sha256": "574bda4d46d48399ba9e29a6e639b33f8f103bb7c85f9e7c935581bb3c63ca37", @@ -6913,19 +5738,12 @@ "6cd1779c-560f-4b68-a8f1-11009b27fe63": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Microsoft Exchange Server UM Writing Suspicious Files", "sha256": "545b3d224a0f1f8ebeb0d9f6ca6077c60c57b650d6a3daa51b4a8b30de55da39", "type": "eql", "version": 109 - }, - "8.13": { - "max_allowable_version": 307, - "rule_name": "Microsoft Exchange Server UM Writing Suspicious Files", - "sha256": "1b469660f4b28888121b5610c6034c3b0a309f63debe06bd347750f423362cf6", - "type": "eql", - "version": 209 } }, "rule_name": "Microsoft Exchange Server UM Writing Suspicious Files", @@ -6934,16 +5752,6 @@ "version": 309 }, "6cea88e4-6ce2-4238-9981-a54c140d6336": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "GitHub Repo Created", - "sha256": "51c2e55a0721646f1d729d916086c9574f76dff3a8c826d5d3295432d0ed3b09", - "type": "eql", - "version": 104 - } - }, "rule_name": "GitHub Repo Created", "sha256": "9c57ec5b44ac7672c65aed3037e55ef4d50dd74364153a908f67c92bdf8f4126", "type": "eql", @@ -6958,7 +5766,7 @@ "6d448b96-c922-4adb-b51c-b767f1ea5b76": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Unusual Process For a Windows Host", "sha256": "a84737464ef6658f7587d12e88f77356e079d797986616813ffb6be47e2abaa0", @@ -6978,16 +5786,6 @@ "version": 6 }, "6ded0996-7d4b-40f2-bf4a-6913e7591795": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Root Certificate Installation", - "sha256": "f8f51e4211d34c59185c437d929b82051162d84c2c026d0a311fd0d6f40f2099", - "type": "eql", - "version": 3 - } - }, "rule_name": "Root Certificate Installation", "sha256": "f253848012c90e8fdcf02df03d40dbb169248ea5c7555e85d439610392aa81ee", "type": "eql", @@ -6996,7 +5794,7 @@ "6e1a2cc4-d260-11ed-8829-f661ea17fbcc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "First Time Seen Commonly Abused Remote Access Tool Execution", "sha256": "3e70cb8e8c6dafe24f60de10cdfcbe05df8d323ef0caf42790714990ebee78c0", @@ -7018,7 +5816,7 @@ "6e40d56f-5c0e-4ac6-aece-bee96645b172": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Anomalous Process For a Windows Population", "sha256": "aa536cbc660cc56dffc7bd3cbb4098aacc6c96df9edb4d4dbe8f33414448b4d3", @@ -7034,7 +5832,7 @@ "6e9130a5-9be6-48e5-943a-9628bfc74b18": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "AdminSDHolder Backdoor", "sha256": "43aaf38f234d7186a1f9dca4f91a364e5afa675e3cade497946daf63f3b20ada", @@ -7056,7 +5854,7 @@ "6ea41894-66c3-4df7-ad6b-2c5074eb3df8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Potential Windows Error Manager Masquerading", "sha256": "736e277394bca054547364d6d99541019679fc36129d52d20115c635cea06701", @@ -7072,7 +5870,7 @@ "6ea55c81-e2ba-42f2-a134-bccf857ba922": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Security Software Discovery using WMIC", "sha256": "6d179ca370610d0b32e8d97afeb4610e7efea1ad82eefdd0c4d5eeca33d29549", @@ -7092,16 +5890,6 @@ "version": 100 }, "6ee947e9-de7e-4281-a55d-09289bdf947e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Potential Linux Tunneling and/or Port Forwarding", - "sha256": "eb944b67560451bef538d988be2f0fcfd42f4a6dce1a2f67fc23ef34d93692e8", - "type": "eql", - "version": 8 - } - }, "rule_name": "Potential Linux Tunneling and/or Port Forwarding", "sha256": "a1f2cd2fc7257d7c204df51ffec3d086f341240896b38551b8acc005408ce357", "type": "eql", @@ -7110,7 +5898,7 @@ "6f024bde-7085-489b-8250-5957efdf1caf": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Active Directory Group Modification by SYSTEM", "sha256": "525d8781dc9e163d70a8889b89be269f79c5df5c44403c7e5d713b19ce001c82", @@ -7132,7 +5920,7 @@ "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "First Occurrence of Okta User Session Started via Proxy", "sha256": "8e24f0277992e974a8ec25803576d40f21206d6466ecaa82e2df16fab17d5dd8", @@ -7179,7 +5967,7 @@ "708c9d92-22a3-4fe0-b6b9-1f861c55502d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Suspicious Execution via MSIEXEC", "sha256": "c4f5fe8318695f565656b31a0fdcf38991cdd94e72a60ba5abb460557280dd27", @@ -7219,19 +6007,12 @@ "71bccb61-e19b-452f-b104-79a60e546a95": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 214, "rule_name": "Unusual File Creation - Alternate Data Stream", "sha256": "021ab9fdaf96cad949b46c2810f09637e27d34d4870bb4544afe5e33d4fcc8fa", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 314, - "rule_name": "Unusual File Creation - Alternate Data Stream", - "sha256": "b28951fe4ef7053b478f08929474a4220e85d70c52a9d83f2779447c8b6a5cfd", - "type": "eql", - "version": 216 } }, "rule_name": "Unusual File Creation - Alternate Data Stream", @@ -7242,7 +6023,7 @@ "71c5cb27-eca5-4151-bb47-64bc3f883270": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Suspicious RDP ActiveX Client Loaded", "sha256": "4465fa5b7551e881e3e5b66b1cfae96e4f8459191b87e2266b1fc1998c26d690", @@ -7274,7 +6055,6 @@ "version": 207 }, "725a048a-88c5-4fc7-8677-a44fc0031822": { - "min_stack_version": "8.13", "rule_name": "AWS Bedrock Detected Multiple Validation Exception Errors by a Single User", "sha256": "f61560b78b79c873453bce1b3947231b6df1c967d0f2a49efefd56bbfb7bfc59", "type": "esql", @@ -7283,7 +6063,7 @@ "729aa18d-06a6-41c7-b175-b65b739b1181": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Reset MFA Factors for an Okta User Account", "sha256": "ac791f5dd84722e6c346e3b3a523b739bbce0ddb484f53d49ed5d1a2ebfe7c7b", @@ -7318,19 +6098,12 @@ "730ed57d-ae0f-444f-af50-78708b57edd5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Suspicious JetBrains TeamCity Child Process", "sha256": "172c7bb001f289281c519a30ba17e66fad2c3a149e5493bc5d33d6253730f818", "type": "eql", "version": 5 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Suspicious JetBrains TeamCity Child Process", - "sha256": "3c672bb24b9e07004c8a40ebed60ab266f23360a5ff613994eb639fc5d98b97a", - "type": "eql", - "version": 105 } }, "rule_name": "Suspicious JetBrains TeamCity Child Process", @@ -7353,7 +6126,7 @@ "7405ddf1-6c8e-41ce-818f-48bea6bcaed8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Potential Modification of Accessibility Binaries", "sha256": "491014d84ab03e206e7acd9755d0269b2830a9b3f9c44913c29682c433c740a6", @@ -7385,7 +6158,6 @@ "version": 105 }, "74f45152-9aee-11ef-b0a5-f661ea17fbcd": { - "min_stack_version": "8.13", "rule_name": "AWS Discovery API Calls via CLI from a Single Resource", "sha256": "f5789d775fa4739d37c91b2704142e6834659dfa48c0b2678871113ce335b642", "type": "esql", @@ -7424,7 +6196,7 @@ "764c9fcd-4c4c-41e6-a0c7-d6c46c2eff66": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 111, "rule_name": "Access to a Sensitive LDAP Attribute", "sha256": "4d4b321e49dadb001df32d6acd71103bd41b71124f92b855ea4335c99dfa105a", @@ -7438,16 +6210,6 @@ "version": 114 }, "766d3f91-3f12-448c-b65f-20123e9e9e8c": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Creation of Hidden Shared Object File", - "sha256": "d821f3e5a0bf1e2dedce1bdaf15fe58785f4e47e81a99103fd0c35cb62e5fbf2", - "type": "eql", - "version": 111 - } - }, "rule_name": "Creation of Hidden Shared Object File", "sha256": "1a48028da247ad699969d0714a5b03ca294e28d99adad7b3fb9ada639aca982c", "type": "eql", @@ -7456,7 +6218,7 @@ "76ddb638-abf7-42d5-be22-4a70b0bf7241": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Privilege Escalation via Rogue Named Pipe Impersonation", "sha256": "d7ae7c609b2c09df86e03eb23c9f3d9c19a114f3e9e69d99121828e0555ea7ff", @@ -7478,19 +6240,12 @@ "76fd43b7-3480-4dd9-8ad7-8bd36bfad92f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Potential Remote Desktop Tunneling Detected", "sha256": "bb7f0c41faf746a3298480bfc47800f229539f64b5ce87b3bf40574b2c3dca0a", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 413, - "rule_name": "Potential Remote Desktop Tunneling Detected", - "sha256": "55e82b40384974580c7b1d4cba55767c941680a4032a373ba1346ff812d0eb3f", - "type": "eql", - "version": 316 } }, "rule_name": "Potential Remote Desktop Tunneling Detected", @@ -7501,19 +6256,12 @@ "770e0c4d-b998-41e5-a62e-c7901fd7f470": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Enumeration Command Spawned via WMIPrvSE", "sha256": "e5462ca4e56f7f3ff1144cc8980d76abdfa350e122d9e02fdbc203194900825b", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Enumeration Command Spawned via WMIPrvSE", - "sha256": "fa3eab2d298379b76f9013f4e96b00f215f422400565f4e592daaa3453aec8ed", - "type": "eql", - "version": 215 } }, "rule_name": "Enumeration Command Spawned via WMIPrvSE", @@ -7522,7 +6270,6 @@ "version": 316 }, "77122db4-5876-4127-b91b-6c179eb21f88": { - "min_stack_version": "8.13", "rule_name": "Potential Malware-Driven SSH Brute Force Attempt", "sha256": "4afa072ed68e90305237cd0f8aa0ab67f7a60db42826cb74af1abf9bc161cfa2", "type": "esql", @@ -7553,16 +6300,6 @@ "version": 11 }, "78390eb5-c838-4c1d-8240-69dd7397cfb7": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Yum/DNF Plugin Status Discovery", - "sha256": "edc1dcf2de6b0222d78f62e7eac490f5069a3917f49022d78a3b84b59739ac14", - "type": "eql", - "version": 3 - } - }, "rule_name": "Yum/DNF Plugin Status Discovery", "sha256": "b945c19be36ede477ceb6eb65ff7fa6d2271d7458820139d0bdd9ad8b8633143", "type": "eql", @@ -7589,19 +6326,12 @@ "78de1aeb-5225-4067-b8cc-f4a1de8a8546": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Suspicious ScreenConnect Client Child Process", "sha256": "beba3270fb78600264fbe41ac386fb2d7c7f6877563ed96e2b7ca2778bbd1b7f", "type": "eql", "version": 5 - }, - "8.13": { - "max_allowable_version": 304, - "rule_name": "Suspicious ScreenConnect Client Child Process", - "sha256": "29f77275c99c2a00e8878dc18a7448e25ad430cce3bdf957ce1ae1307622ea8a", - "type": "eql", - "version": 208 } }, "rule_name": "Suspicious ScreenConnect Client Child Process", @@ -7641,16 +6371,6 @@ "version": 3 }, "7957f3b9-f590-4062-b9f9-003c32bfc7d6": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "SSL Certificate Deletion", - "sha256": "7c7dddf409d27c4336808578a23adad99b63a0ffdc3ca7a3651f429905241271", - "type": "eql", - "version": 2 - } - }, "rule_name": "SSL Certificate Deletion", "sha256": "7e7cc3077f9f831c4c0bf8d8d0cbdb3ab9244f904d9ecc9698a4a1790edb925d", "type": "eql", @@ -7671,19 +6391,12 @@ "79f0a1f7-ed6b-471c-8eb1-23abd6470b1c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Potential File Transfer via Certreq", "sha256": "c1f7d50618580187b015a4aadd76a9e484eb5bb8ce8143e052cb8118a678c4d1", "type": "eql", "version": 11 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "Potential File Transfer via Certreq", - "sha256": "11dc705c82fee3ada817dbe4ff1e934ddeb2ba159d164dbb5a0048d92bc04d6b", - "type": "eql", - "version": 111 } }, "rule_name": "Potential File Transfer via Certreq", @@ -7694,7 +6407,7 @@ "79f97b31-480e-4e63-a7f4-ede42bf2c6de": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Potential Shadow Credentials added to AD Object", "sha256": "42853b04a39893088bdb0ebf5c479305c2f34e5352c3ccfa65ef5146efc6e8a4", @@ -7746,7 +6459,7 @@ "7b8bfc26-81d2-435e-965c-d722ee397ef1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Windows Network Enumeration", "sha256": "2bd4c58be4ce436e2d00994654b5252ddc7e40ee04cda79c22e1632ab1dcb486", @@ -7762,7 +6475,7 @@ "7b981906-86b7-4544-8033-c30ec6eb45fc": { "min_stack_version": "8.16", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "SELinux Configuration Creation or Renaming", "sha256": "7b361ea07b92064cb854e35573c5988af529ce6fb75a264cdd27ff53b0963e28", @@ -7778,7 +6491,7 @@ "7ba58110-ae13-439b-8192-357b0fcfa9d7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Suspicious LSASS Access via MalSecLogon", "sha256": "9abb27e289a572393ecc8c26044e5a71196cc1d77d152f84fbee7138251de7de", @@ -7810,16 +6523,6 @@ "version": 107 }, "7ce5e1c7-6a49-45e6-a101-0720d185667f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Git Hook Child Process", - "sha256": "cbfd0389fa0ca95a4de245b02e374ee3f3a3981798ed207f5f5ceff7808d654b", - "type": "eql", - "version": 3 - } - }, "rule_name": "Git Hook Child Process", "sha256": "3aeeab0a9f9e1baa8c36a0d3aca397ac0be75278ca1a51b60022819bf9ea8cde", "type": "eql", @@ -7844,16 +6547,6 @@ "version": 100 }, "7df3cb8b-5c0c-4228-b772-bb6cd619053c": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "SSH Key Generated via ssh-keygen", - "sha256": "7841db675589b43a0132206eb7b239ca46f3ac97ad9193dcf04937159707d691", - "type": "eql", - "version": 4 - } - }, "rule_name": "SSH Key Generated via ssh-keygen", "sha256": "5a08a86502f4db05eca4b25e854f8f9be1f852325a962075dea70815aacf6764", "type": "eql", @@ -7868,19 +6561,12 @@ "7e23dfef-da2c-4d64-b11d-5f285b638853": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Microsoft Management Console File from Unusual Path", "sha256": "1cc5185969e04329ea04aa4bf8d5d1e3a8d47fa9e0ac1f47e3012111ef6c91be", "type": "eql", "version": 6 - }, - "8.13": { - "max_allowable_version": 304, - "rule_name": "Microsoft Management Console File from Unusual Path", - "sha256": "72222c6f6a422dc7edd2b2143a7b80819949cb1356894fe018a138774633fee6", - "type": "eql", - "version": 208 } }, "rule_name": "Microsoft Management Console File from Unusual Path", @@ -7896,16 +6582,6 @@ "version": 1 }, "7efca3ad-a348-43b2-b544-c93a78a0ef92": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Security File Access via Common Utilities", - "sha256": "46ed777838914f516739b0d329e16d62457fc60aedd877440c7cc4022d7ed059", - "type": "eql", - "version": 2 - } - }, "rule_name": "Security File Access via Common Utilities", "sha256": "6ba9893d93ba8852cad33b67e46d3ffda3bb3282cf04264efb77ba683e837231", "type": "eql", @@ -7914,7 +6590,7 @@ "7f370d54-c0eb-4270-ac5a-9a6020585dc6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Suspicious WMIC XSL Script Execution", "sha256": "1fcee1562ccb772f6a7729303e250ead257201a219aa8ffee182b66f784076d3", @@ -7946,7 +6622,6 @@ "version": 16 }, "7fda9bb2-fd28-11ee-85f9-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "Potential AWS S3 Bucket Ransomware Note Uploaded", "sha256": "c074c4066439731cdb1ca074f41712d8139ba7383e854e9990c3f5fef99a6a9e", "type": "esql", @@ -7967,7 +6642,7 @@ "8025db49-c57c-4fc0-bd86-7ccd6d10a35a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Potential PowerShell Obfuscated Script", "sha256": "1106414c1ef42b911e2c96ae0a545a86614b9a568aa9742419c22b0a71a0e879", @@ -7989,7 +6664,7 @@ "808291d3-e918-4a3a-86cd-73052a0c9bdc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Suspicious Troubleshooting Pack Cabinet Execution", "sha256": "f3e0f53c321d7760c971547d90245085ba16e37bb4a6cbbb16a17e495f180f1d", @@ -8023,19 +6698,12 @@ "818e23e6-2094-4f0e-8c01-22d30f3506c6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "PowerShell Script Block Logging Disabled", "sha256": "e35e69e41855d8858d5ae3ebe2faaa97f0b2ec25d6211a2998a8ea57f7b9f7bc", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "PowerShell Script Block Logging Disabled", - "sha256": "fc4ff95d31809bdc72563ba4251142cb5a33e5239d3cb64a0b877a31f6ba05d4", - "type": "eql", - "version": 210 } }, "rule_name": "PowerShell Script Block Logging Disabled", @@ -8052,7 +6720,7 @@ "81fe9dc6-a2d7-4192-a2d8-eed98afc766a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "PowerShell Suspicious Payload Encoded and Compressed", "sha256": "efc3d78e44e73f61be6817f00d4df5af584ce5e02e96ca5fb45a45d84d771116", @@ -8068,7 +6736,7 @@ "81ff45f8-f8c2-4e28-992e-5a0e8d98e0fe": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Temporarily Scheduled Task Creation", "sha256": "f3147338285b65e5fc2727bb5e244417230a438c509b93732c76fc659df7a77e", @@ -8094,7 +6762,6 @@ "version": 2 }, "834ee026-f9f9-4ec7-b5e0-7fbfe84765f4": { - "min_stack_version": "8.13", "rule_name": "Manual Dracut Execution", "sha256": "dbd9afc54fc7a771ed98faffa779d382c2b1962cedf84ec2dd45606550e37857", "type": "eql", @@ -8121,19 +6788,12 @@ "83bf249e-4348-47ba-9741-1202a09556ad": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Suspicious Windows Powershell Arguments", "sha256": "d97f88a21e5ef203f235aaa22174e05b7a3af6d503f8955c63fbad955ab56a5b", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Suspicious Windows Powershell Arguments", - "sha256": "d452c13b253efe39545cb5208cb8dcc730eec15c3cf732e06e875f95f930d0a7", - "type": "eql", - "version": 103 } }, "rule_name": "Suspicious Windows Powershell Arguments", @@ -8142,16 +6802,6 @@ "version": 204 }, "83e9c2b3-24ef-4c1d-a8cd-5ebafb5dfa2f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 108, - "rule_name": "Attempt to Disable IPTables or Firewall", - "sha256": "6662212297b3975808144113e634d7165b30280989ae8729d7cd570603f52193", - "type": "eql", - "version": 10 - } - }, "rule_name": "Attempt to Disable IPTables or Firewall", "sha256": "549c19f864332988b6fb45817a74e1dab49339388224f5b36cdaf30d80d21bda", "type": "eql", @@ -8166,7 +6816,7 @@ "846fe13f-6772-4c83-bd39-9d16d4ad1a81": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Microsoft Exchange Transport Agent Install Script", "sha256": "6c50456e5c405b545f31c8c93d71b2f1614b64bd732ca548127db4db6230c412", @@ -8186,16 +6836,6 @@ "version": 3 }, "84d1f8db-207f-45ab-a578-921d91c23eb2": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Potential Upgrade of Non-interactive Shell", - "sha256": "5add5265cea65ff564e6f374b8d963ea6af326fbed8d8d0b3ad11829c55033e6", - "type": "eql", - "version": 4 - } - }, "rule_name": "Potential Upgrade of Non-interactive Shell", "sha256": "559158e7c30d5871bbf29e70aef9a1d8def80199a6ab18a0f76d1363c713891c", "type": "eql", @@ -8204,7 +6844,7 @@ "84da2554-e12a-11ec-b896-f661ea17fbcd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Enumerating Domain Trusts via NLTEST.EXE", "sha256": "ed8b2a515385353dbfff6d484b45000dd49af48e2b5abc8e44406fa955d7225e", @@ -8230,7 +6870,6 @@ "version": 211 }, "860f2a03-a1cf-48d6-a674-c6d62ae608a1": { - "min_stack_version": "8.13", "rule_name": "Potential Subnet Scanning Activity from Compromised Host", "sha256": "3ca0053a517e206cbd88cae6c14ed9398b99f6ee5021cef8d89c40b9a66ba4f8", "type": "esql", @@ -8255,7 +6894,6 @@ "version": 207 }, "86aa8579-1526-4dff-97cd-3635eb0e0545": { - "min_stack_version": "8.13", "rule_name": "NetworkManager Dispatcher Script Creation", "sha256": "183f75eab447dce4523d4f25e514acf26cfbdf05b137fd5a3fd9eb1b968d86ee", "type": "eql", @@ -8276,7 +6914,7 @@ "871ea072-1b71-4def-b016-6278b505138d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Enumeration of Administrator Accounts", "sha256": "f8c272cacf74e41908905fbe517ec45ff817e7a6f81d7a2cc3997687c84ad708", @@ -8334,7 +6972,7 @@ "891cb88e-441a-4c3e-be2d-120d99fe7b0d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Suspicious WMI Image Load from MS Office", "sha256": "8809aba8865764ab7fa1c657c37778c6657378dc4f2cfb4c6127be5e794149ed", @@ -8350,7 +6988,7 @@ "894326d2-56c0-4342-b553-4abfaf421b5b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Potential WPAD Spoofing via DNS Record Creation", "sha256": "e247d1c92d0054f5c3a3d6aa1d7d50053e63ec57610f92bf623e1c665d5fef72", @@ -8364,7 +7002,6 @@ "version": 105 }, "894b7cc9-040b-427c-aca5-36b40d3667bf": { - "min_stack_version": "8.13", "rule_name": "Unusual File Creation by Web Server", "sha256": "8cae8e72cd21c891b3a56fb7489a1dd3047402b91600b8407a06bd207d353617", "type": "esql", @@ -8377,16 +7014,6 @@ "version": 100 }, "897dc6b5-b39f-432a-8d75-d3730d50c782": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Kerberos Traffic from Unusual Process", - "sha256": "7120f5e967222b6743edb0bc495b3453b4d26dc1f63088bff68607f6220e8b59", - "type": "eql", - "version": 111 - } - }, "rule_name": "Kerberos Traffic from Unusual Process", "sha256": "14dc4752088817761b090bd9e818c960db21258c4ce1aff3ce6e86dbe199d127", "type": "eql", @@ -8395,7 +7022,7 @@ "89f9a4b0-9f8f-4ee0-8823-c4751a6d6696": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Command Prompt Network Connection", "sha256": "95c1cb5499a597411e4e3b7103680f9d8fb49cf5fc8cb6f354b9483142545adc", @@ -8423,7 +7050,7 @@ "8a0fbd26-867f-11ee-947c-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Potential Okta MFA Bombing via Push Notifications", "sha256": "0a419be8ba1ef4b746cee1fe87e2a2459a10566938e2b5114a985c15c294088a", @@ -8444,16 +7071,6 @@ "version": 208 }, "8a0fd93a-7df8-410d-8808-4cc5e340f2b9": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "GitHub PAT Access Revoked", - "sha256": "2da8385cb4225c3a080f85def407322ed423d41cdeaec25622ddcced2bad28a4", - "type": "eql", - "version": 104 - } - }, "rule_name": "GitHub PAT Access Revoked", "sha256": "ce7ded3ad0a0a070017efa54dff9afe6f0d43284222f27cd5eaedfb2ad660df5", "type": "eql", @@ -8468,7 +7085,7 @@ "8a1d4831-3ce6-4859-9891-28931fa6101d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Suspicious Execution from a Mounted Device", "sha256": "cd861b1c03ef17e10978c9c1e342be58e0362cd9eef31c85cb7b40568cf5fa52", @@ -8484,7 +7101,7 @@ "8a5c1e5f-ad63-481e-b53a-ef959230f7f1": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Deactivate an Okta Network Zone", "sha256": "8206b3e0f7284ae1caf2453d9befae81b545dea65fad93c30bf6b827be016118", @@ -8505,7 +7122,6 @@ "version": 411 }, "8a7933b4-9d0a-4c1c-bda5-e39fb045ff1d": { - "min_stack_version": "8.13", "rule_name": "Unusual Command Execution from Web Server Parent", "sha256": "2eb13bc908da7bb2301a0f62d0860956cb7aa1d99d970bbb6e6d6b32dfc428ca", "type": "esql", @@ -8518,16 +7134,6 @@ "version": 209 }, "8af5b42f-8d74-48c8-a8d0-6d14b4197288": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "Potential Sudo Privilege Escalation via CVE-2019-14287", - "sha256": "2753a4670d4217cc050e838bf5a7f4843db23df0caa83fc1017d346297e4922f", - "type": "eql", - "version": 5 - } - }, "rule_name": "Potential Sudo Privilege Escalation via CVE-2019-14287", "sha256": "f2b61c3ff7a9e998f71f19335af6dfe69db48ae9d7098fcf270a3dc44ec4fb48", "type": "eql", @@ -8536,19 +7142,12 @@ "8b2b3a62-a598-4293-bc14-3d5fa22bb98f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Executable File Creation with Multiple Extensions", "sha256": "79486f56c33d6afd1cec4fbf8dc404d0f0e9fc38b19572051d537f800d601ed5", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Executable File Creation with Multiple Extensions", - "sha256": "8706ffd6a46a7cdbd2b6400c609ec39bf1f1bf833ecccf2d71a38a9316b96ccd", - "type": "eql", - "version": 210 } }, "rule_name": "Executable File Creation with Multiple Extensions", @@ -8559,19 +7158,12 @@ "8b4f0816-6a65-4630-86a6-c21c179c0d09": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Enable Host Network Discovery via Netsh", "sha256": "91cdd11fc144f89b569a54e7275f2028a431bf4b3f898c924be4ca038ed1e1db", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Enable Host Network Discovery via Netsh", - "sha256": "10276d358882ef3da69495c0a49a1a76d8f27b5759699cd6abe910853de7d0a3", - "type": "eql", - "version": 211 } }, "rule_name": "Enable Host Network Discovery via Netsh", @@ -8594,19 +7186,12 @@ "8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Unusual Child Process of dns.exe", "sha256": "911e718531c11fae196314f279f6f059a3a14dee38701be164c18c20a69be5a8", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Unusual Child Process of dns.exe", - "sha256": "684919ee328c12075a6ff89741a91ca29400e405462c9ae06ea7003439680d37", - "type": "eql", - "version": 213 } }, "rule_name": "Unusual Child Process of dns.exe", @@ -8651,16 +7236,6 @@ "version": 5 }, "8da41fc9-7735-4b24-9cc6-c78dfc9fc9c9": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 207, - "rule_name": "Potential Privilege Escalation via PKEXEC", - "sha256": "b3457a5fe20b9065c1d9ebd5a8629e04c5ec7633c1976306c1002925a7819bac", - "type": "eql", - "version": 109 - } - }, "rule_name": "Potential Privilege Escalation via PKEXEC", "sha256": "5c75901a24944ea9bb7731dfa441ca4c2e49cba2cc2cf98c4bf84dc0fb10506d", "type": "eql", @@ -8675,19 +7250,12 @@ "8e2485b6-a74f-411b-bf7f-38b819f3a846": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Potential WSUS Abuse for Lateral Movement", "sha256": "cc8123040408a5a7b8824468814a4a6152edc5a53ce52f8d4a21411633b35e12", "type": "eql", "version": 5 - }, - "8.13": { - "max_allowable_version": 203, - "rule_name": "Potential WSUS Abuse for Lateral Movement", - "sha256": "c3e58264f54e251fc042b772277da53c784ead76674487f0c33c678b7dd0a9b5", - "type": "eql", - "version": 106 } }, "rule_name": "Potential WSUS Abuse for Lateral Movement", @@ -8704,7 +7272,7 @@ "8eec4df1-4b4b-4502-b6c3-c788714604c9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Bitsadmin Activity", "sha256": "96da24c5865af45e8f97dda18459a22901c821608d0882b14b8d21d20c5db1f3", @@ -8718,7 +7286,6 @@ "version": 106 }, "8eeeda11-dca6-4c3e-910f-7089db412d1c": { - "min_stack_version": "8.13", "rule_name": "Unusual File Transfer Utility Launched", "sha256": "f8716bca394f674cd16c413cffed7862bb3e4038a525c750adf70d3d2406ed09", "type": "esql", @@ -8727,7 +7294,7 @@ "8f242ffb-b191-4803-90ec-0f19942e17fd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Potential ADIDNS Poisoning via Wildcard Record Creation", "sha256": "b3f6fd62337753431592f0b819d7b43364bec6c27449bda2d19dedddedc22d07", @@ -8749,7 +7316,7 @@ "8f919d4b-a5af-47ca-a594-6be59cd924a4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows", "sha256": "fcce93128b54c854991bf62a7016a112b1eae5e6fa8d95fc7f0ce183c1695e49", @@ -8773,18 +7340,8 @@ "sha256": "7e88fe635274dd47f23d744bd4b8fb482ab86c8b1b6db9434d64ab40c7edbb62", "type": "eql", "version": 100 - }, - "90169566-2260-4824-b8e4-8615c3b4ed52": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 207, - "rule_name": "Hping Process Activity", - "sha256": "58160571062e081d702d11bf00b07b9ca2dc75b7463e22d6eb58eb8c00ac7ae2", - "type": "eql", - "version": 109 - } - }, + }, + "90169566-2260-4824-b8e4-8615c3b4ed52": { "rule_name": "Hping Process Activity", "sha256": "fe079acfbd59f33d0829da92c4e2e587c3f846c53a875510463da0438f0c4a0b", "type": "eql", @@ -8797,16 +7354,6 @@ "version": 207 }, "907a26f5-3eb6-4338-a70e-6c375c1cde8a": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Simple HTTP Web Server Creation", - "sha256": "4717868c8d8d29e5d6f9a575a34fa4d179d67b8a82e17f838845ba5c125ee114", - "type": "eql", - "version": 2 - } - }, "rule_name": "Simple HTTP Web Server Creation", "sha256": "df11460970a3eeb111f933ea0c48401c916e8f2f9ba35b1c8595a215b624242d", "type": "eql", @@ -8827,7 +7374,7 @@ "90babaa8-5216-4568-992d-d4a01a105d98": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "InstallUtil Activity", "sha256": "e5667b196187758d6237ff6bf5f23a6f6e1aeb96192193c9497c622982907440", @@ -8883,16 +7430,6 @@ "version": 105 }, "929223b4-fba3-4a1c-a943-ec4716ad23ec": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "GitHub UEBA - Multiple Alerts from a GitHub Account", - "sha256": "e05cc04048543a016fd0b4cfe4f9c7ef35ce1777a691f3305b103b16989fb6eb", - "type": "threshold", - "version": 2 - } - }, "rule_name": "GitHub UEBA - Multiple Alerts from a GitHub Account", "sha256": "e05cc04048543a016fd0b4cfe4f9c7ef35ce1777a691f3305b103b16989fb6eb", "type": "threshold", @@ -8901,7 +7438,7 @@ "92984446-aefb-4d5e-ad12-598042ca80ba": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "PowerShell Suspicious Script with Clipboard Retrieval Capabilities", "sha256": "85b4d7774d3dfb59ebe89003974ca0946860cd98d777fdd46fbdb3ebfa77815f", @@ -8917,7 +7454,7 @@ "92a6faf5-78ec-4e25-bea1-73bacc9b59d9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "A scheduled task was created", "sha256": "b1fa6b0fe20d2fd8ffedb8e8b14ef7d3b57c533ea32c88b2841028986b3bf6f7", @@ -8933,7 +7470,7 @@ "92d3a04e-6487-4b62-892d-70e640a590dc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Potential Evasion via Windows Filtering Platform", "sha256": "b0a73c7ef98e6c64fd9209a4d9dd91fd447c52af2d20f698ea91c6b7221d922e", @@ -8965,16 +7502,6 @@ "version": 209 }, "93b22c0a-06a0-4131-b830-b10d5e166ff4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Suspicious SolarWinds Child Process", - "sha256": "2ff5b58315d4aee44cd2bcec8d5026cc4e7770e3bb4d906ca2489e2385babf3f", - "type": "eql", - "version": 111 - } - }, "rule_name": "Suspicious SolarWinds Child Process", "sha256": "55c655f3c81ec5fc6d674e2429a40bd0ea00235f4ce1935765a26941a143cde9", "type": "eql", @@ -8983,19 +7510,12 @@ "93c1ce76-494c-4f01-8167-35edfb52f7b1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Encoded Executable Stored in the Registry", "sha256": "de92e4d989f9d5610e757c673fbdc4c456231b4ef81e7f4504698b6c264f9962", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 410, - "rule_name": "Encoded Executable Stored in the Registry", - "sha256": "d85365573dabbdc204f56fef122dd591e689ffd34004f20d74d2c47e2aa4ec5b", - "type": "eql", - "version": 312 } }, "rule_name": "Encoded Executable Stored in the Registry", @@ -9016,16 +7536,6 @@ "version": 205 }, "94418745-529f-4259-8d25-a713a6feb6ae": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "Executable Bit Set for Potential Persistence Script", - "sha256": "16145a1b22661ff2e88c9e1ba07836862628630beefcda649d52f876480530d4", - "type": "eql", - "version": 5 - } - }, "rule_name": "Executable Bit Set for Potential Persistence Script", "sha256": "b5f2d2b732ed56124dc1f618c8aaa4a1b035b3af81246aca47b16d675c5888f0", "type": "eql", @@ -9040,19 +7550,12 @@ "94a401ba-4fa2-455c-b7ae-b6e037afc0b7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Group Policy Discovery via Microsoft GPResult Utility", "sha256": "46c457a7a1a2443ebb06f362b2f728a3fa9ea4f0c6261d4bdc32a7de7e92ab6e", "type": "eql", "version": 12 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "Group Policy Discovery via Microsoft GPResult Utility", - "sha256": "3bf1f307ad367938a343c262bcf271d1e172a74528f40a5f70364cbfd688a804", - "type": "eql", - "version": 111 } }, "rule_name": "Group Policy Discovery via Microsoft GPResult Utility", @@ -9092,7 +7595,7 @@ "951779c2-82ad-4a6c-82b8-296c1f691449": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Potential PowerShell Pass-the-Hash/Relay Script", "sha256": "30e9709aa596d9469d905ec6593683478b4eeb9a2d40edb724b0c2e5f1ba6bd2", @@ -9106,7 +7609,6 @@ "version": 105 }, "952c92af-d67f-4f01-8a9c-725efefa7e07": { - "min_stack_version": "8.13", "rule_name": "D-Bus Service Created", "sha256": "f49342d2753a20175c2dbbc0a575357ee2a7bbc665af3267b73778f6270b6bcc", "type": "eql", @@ -9115,7 +7617,7 @@ "954ee7c8-5437-49ae-b2d6-2960883898e9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Remote Scheduled Task Creation", "sha256": "48228fde14a00d80993e815c4517cda88186986de1c72b6ab1503cfbced929f8", @@ -9131,7 +7633,7 @@ "959a7353-1129-4aa7-9084-30746b256a70": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "PowerShell Suspicious Script with Screenshot Capabilities", "sha256": "ec182387ccb79ee33c05281674fdc60fea9112866634a0782d814363c238711c", @@ -9180,16 +7682,6 @@ "version": 4 }, "968ccab9-da51-4a87-9ce2-d3c9782fd759": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 211, - "rule_name": "File made Immutable by Chattr", - "sha256": "61a885e5fd8caa58db1e46f7ac46a9212cb60f45987a57654e44fccf0044273d", - "type": "eql", - "version": 113 - } - }, "rule_name": "File made Immutable by Chattr", "sha256": "38909ad9aefb85b3686d7ce1ad51131ea6f34ac9a0f3636eff945237ca572566", "type": "eql", @@ -9198,7 +7690,7 @@ "96b9f4ea-0e8c-435b-8d53-2096e75fcac5": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Attempt to Create Okta API Token", "sha256": "8b9151616759ad5ef0331c84d359b1fac9dd5625d8bccc8ccfc29b6edec463ec", @@ -9233,7 +7725,7 @@ "97020e61-e591-4191-8a3b-2861a2b887cd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "SeDebugPrivilege Enabled by a Suspicious Process", "sha256": "1a312776aa0b8db999e00c4e025deb6da554ec3738734de8d788a6e8c2d8b957", @@ -9247,7 +7739,6 @@ "version": 110 }, "9705b458-689a-4ec6-afe8-b4648d090612": { - "min_stack_version": "8.13", "rule_name": "Unusual D-Bus Daemon Child Process", "sha256": "047f6e5a12bc33a0db9822bfcc4d9532eb5bb20f261dc8d5d0a6b9d335db1175", "type": "eql", @@ -9272,7 +7763,6 @@ "version": 3 }, "976b2391-413f-4a94-acb4-7911f3803346": { - "min_stack_version": "8.13", "rule_name": "Unusual Process Spawned from Web Server Parent", "sha256": "65425366319a1036000c5b118c93b8838f7357205eb7f98d09811cd3d417fdac", "type": "esql", @@ -9287,7 +7777,7 @@ "97a8e584-fd3b-421f-9b9d-9c9d9e57e9d7": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 311, "rule_name": "Potentially Successful MFA Bombing via Push Notifications", "sha256": "c3895c292a7d6d01c0202991f5bd5c8286f59782f74ce2d31d2e5154428be6e1", @@ -9310,19 +7800,12 @@ "97aba1ef-6034-4bd3-8c1a-1e0996b27afa": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Suspicious Zoom Child Process", "sha256": "89aac019d039da3e9cc8d5a90ad24c527336df5dcb17667cd41e0bee861b36af", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 413, - "rule_name": "Suspicious Zoom Child Process", - "sha256": "81d81d2a203cc3c331a1a84c28d088567742339d61e0f33dde9e1035758db531", - "type": "eql", - "version": 317 } }, "rule_name": "Suspicious Zoom Child Process", @@ -9367,16 +7850,6 @@ "version": 3 }, "986361cd-3dac-47fe-afa1-5c5dd89f2fb4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Suspicious Execution from Foomatic-rip or Cupsd Parent", - "sha256": "71605f19bbfc7c7d7b38c3c938e25db98327f11a8597bfc3707c0b7936fc407f", - "type": "eql", - "version": 3 - } - }, "rule_name": "Suspicious Execution from Foomatic-rip or Cupsd Parent", "sha256": "701bf23c547307a946220bd3957b0adca6d9935dc5ddd0a2d59e97125e3cbd06", "type": "eql", @@ -9385,7 +7858,7 @@ "98843d35-645e-4e66-9d6a-5049acd96ce1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Indirect Command Execution via Forfiles/Pcalua", "sha256": "8f278d6cccbc4ea629a93950010eaec7cf14434d52853ef5918623c532fa1fbf", @@ -9431,7 +7904,7 @@ "994e40aa-8c85-43de-825e-15f665375ee8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score", "sha256": "f9bab10027d4eaff5c7cadc5613cfdfe2caf71917f01c2298779b3693e458905", @@ -9447,7 +7920,7 @@ "9960432d-9b26-409f-972b-839a959e79e2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 309, "rule_name": "Potential Credential Access via LSASS Memory Dump", "sha256": "d1a480f7832f8712d06096eb7dd3d5ff5ebd8c57a23ccb530abd85f8523c12ad", @@ -9461,32 +7934,12 @@ "version": 311 }, "999565a2-fc52-4d72-91e4-ba6712c0377e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Access Control List Modification via setfacl", - "sha256": "59b417d5b2a03bba13ec5f3948f8dea5787846aa669acafde0f1edf8f4c9179b", - "type": "eql", - "version": 3 - } - }, "rule_name": "Access Control List Modification via setfacl", "sha256": "265d70cfdc84fddd988dbe3b110c25de72fe374209a1e78e667c309c70c3b13e", "type": "eql", "version": 104 }, "99c2b626-de44-4322-b1f9-157ca408c17e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Web Server Spawned via Python", - "sha256": "590abb2de8685e9ba6ac1bb26b5ba6e6799b404bca1b24fed7d7e3c37f8f4452", - "type": "eql", - "version": 2 - } - }, "rule_name": "Web Server Spawned via Python", "sha256": "e40443f15069a79c93f3af2ef411178ce68866881149524dbc2a1822cecdc3ee", "type": "eql", @@ -9499,7 +7952,6 @@ "version": 105 }, "9a1a2dae-0b5f-4c3d-8305-a268d404c306": { - "min_stack_version": "8.12", "rule_name": "Endpoint Security (Elastic Defend)", "sha256": "30950c93c8eddc61c365791e8c2b74e80d7890fcc2f73f740c5eb9d5481f3b4a", "type": "query", @@ -9520,19 +7972,12 @@ "9a5b4e31-6cde-4295-9ff7-6be1b8567e1b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Suspicious Explorer Child Process", "sha256": "dd9f2215be389c33f7a237f9116f9ebfcdc92de051c6babfea314a2664c84bd0", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Suspicious Explorer Child Process", - "sha256": "a2a0a26741e33b91efa6e94308f5e4734607222ce87fffcf03ad1682e63fe624", - "type": "eql", - "version": 210 } }, "rule_name": "Suspicious Explorer Child Process", @@ -9543,19 +7988,12 @@ "9aa0e1f6-52ce-42e1-abb3-09657cee2698": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Scheduled Tasks AT Command Enabled", "sha256": "a89728e7de28de1f41f89eae6884b7434dbd8f948cd682f6a0621a4cd7027067", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Scheduled Tasks AT Command Enabled", - "sha256": "bb878ddab8423add89b2fa6d67e8fb17d61aea08318d7adcc5f16859511228ec", - "type": "eql", - "version": 211 } }, "rule_name": "Scheduled Tasks AT Command Enabled", @@ -9564,23 +8002,12 @@ "version": 311 }, "9aa4be8d-5828-417d-9f54-7cd304571b24": { - "min_stack_version": "8.13", "rule_name": "AWS IAM AdministratorAccess Policy Attached to User", "sha256": "5261d7a8d3df0f503139f70be2c16478f9da435dcb45315321b70c9f0136c973", "type": "esql", "version": 5 }, "9b343b62-d173-4cfd-bd8b-e6379f964ca4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 205, - "rule_name": "GitHub Owner Role Granted To User", - "sha256": "161fe9bc03f0a9bd845c1f1a27a75b057d54285240798bac0af9d268896a8ec6", - "type": "eql", - "version": 107 - } - }, "rule_name": "GitHub Owner Role Granted To User", "sha256": "17b30931a90a1e2a268c89b8ca1c50d33a9ad847cf40b03526748115fa47df6f", "type": "eql", @@ -9589,19 +8016,12 @@ "9b6813a1-daf1-457e-b0e6-0bb4e55b8a4c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Persistence via WMI Event Subscription", "sha256": "1ca4124ab56004a70f6da7a9a4d37c4f17b4b6f6dae275a42b309b567ba942ab", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Persistence via WMI Event Subscription", - "sha256": "84f14d803c60917b6e0fc1ed345759a7a8cba6fcc2cb04ce790c8f6f410b8789", - "type": "eql", - "version": 214 } }, "rule_name": "Persistence via WMI Event Subscription", @@ -9618,7 +8038,7 @@ "9c260313-c811-4ec8-ab89-8f6530e0246c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Hosts File Modified", "sha256": "9857acc6de8b05c65a249bb32fb2aa5bb50283f5ac6aa34dfc4285a8a1abb5e2", @@ -9640,7 +8060,7 @@ "9c865691-5599-447a-bac9-b3f2df5f9a9d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Remote Scheduled Task Creation via RPC", "sha256": "16a3342d1003ae1b974b870f7a8388dbc7041f06704202c476621831405e4ad9", @@ -9662,19 +8082,12 @@ "9ccf3ce0-0057-440a-91f5-870c6ad39093": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Command Shell Activity Started via RunDLL32", "sha256": "97790052feabd6d8d92049481818933f920d5128b459958b23b4f454788e1926", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Command Shell Activity Started via RunDLL32", - "sha256": "b70867b53f9047d648a74ee785fbfb344461397ac17e24dfb7d85c50b80bd906", - "type": "eql", - "version": 211 } }, "rule_name": "Command Shell Activity Started via RunDLL32", @@ -9697,7 +8110,7 @@ "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "Microsoft Build Engine Started by a Script Process", "sha256": "c6feee8b5f84305767251a5980243998d9d4ba2743ad9874895791e3fa10e948", @@ -9713,19 +8126,12 @@ "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Microsoft Build Engine Started by a System Process", "sha256": "3bd8a686c90d2b907e79cb8d81ba383c30178ea847082f7fe1759d803be174af", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Microsoft Build Engine Started by a System Process", - "sha256": "a5612eb45ae24f371fdd1a61b1d6c0ca308cc2c8dc2fab9ac4bd95b6f32b8fc4", - "type": "eql", - "version": 213 } }, "rule_name": "Microsoft Build Engine Started by a System Process", @@ -9736,7 +8142,7 @@ "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Microsoft Build Engine Using an Alternate Name", "sha256": "1658b389087bc7cd6ee91ffc89a1714168b562dd44451d4c4d6f72702036b9a4", @@ -9752,7 +8158,7 @@ "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Potential Credential Access via Trusted Developer Utility", "sha256": "0bb18ca3b493310ba23b616de3d39cfba94773b53140eafec03abd781a5897c2", @@ -9768,7 +8174,7 @@ "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 313, "rule_name": "Microsoft Build Engine Started an Unusual Process", "sha256": "fdb27be4ce2b9a135b03186611685488a9d4a989738c3edd28687e83b9f7e349", @@ -9784,7 +8190,7 @@ "9d110cb3-5f4b-4c9a-b9f5-53f0a1707ae9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Process Injection by the Microsoft Build Engine", "sha256": "6e08e0961e8712e3fa798614ceba20842f1fd9e78569f3efb5b0236bd2ffaadf", @@ -9822,16 +8228,6 @@ "version": 3 }, "9f1c4ca3-44b5-481d-ba42-32dc215a2769": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Potential Protocol Tunneling via EarthWorm", - "sha256": "3e4eea02a43d60f58a4be4bea2a88713ba7724676b52851025572c1bbe451d5d", - "type": "eql", - "version": 111 - } - }, "rule_name": "Potential Protocol Tunneling via EarthWorm", "sha256": "41e4276d49f03093af17d2254ee773f8643d1c0aa8b8ac61d01ccefd7bdc22e8", "type": "eql", @@ -9840,7 +8236,7 @@ "9f962927-1a4f-45f3-a57b-287f2c7029c1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 214, "rule_name": "Potential Credential Access via DCSync", "sha256": "b5ad0d7ace8669b1eea8d9a58c38cb027d236901af048b6f308e8b921b7fb4a0", @@ -9868,7 +8264,7 @@ "a02cb68e-7c93-48d1-93b2-2c39023308eb": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "A scheduled task was updated", "sha256": "24db103856c5596c20cce21e7e92ea1d20a82b95691be3b31c7718f15984c193", @@ -9896,7 +8292,7 @@ "a13167f1-eec2-4015-9631-1fee60406dcf": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "InstallUtil Process Making Network Connections", "sha256": "009c0f45c6d544d656f91b1a17dc4ca36d2fa5cda90732b95d8cc0840b82684f", @@ -9910,16 +8306,6 @@ "version": 208 }, "a1329140-8de3-4445-9f87-908fb6d824f4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 208, - "rule_name": "File Deletion via Shred", - "sha256": "cb4768e9cc77383814b6bf126bda3c193dae302c4d755159f2ce1e4079e49733", - "type": "eql", - "version": 110 - } - }, "rule_name": "File Deletion via Shred", "sha256": "6cf3281eed4a567e7fadf7e7a60a25d32be3683088852fd6cac2b340214c17d3", "type": "eql", @@ -9928,7 +8314,7 @@ "a16612dd-b30e-4d41-86a0-ebe70974ec00": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Potential LSASS Clone Creation via PssCaptureSnapShot", "sha256": "5fa1a396391aee8e4f152b75cbd71a7944b0a4850e20e3496a5de3f463d46031", @@ -9944,19 +8330,12 @@ "a1699af0-8e1e-4ed0-8ec1-89783538a061": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Windows Subsystem for Linux Distribution Installed", "sha256": "60b4da3686af1892886ef1568adc3da363b41fa02069a8ad5f02c1f13fc5e375", "type": "eql", "version": 9 - }, - "8.13": { - "max_allowable_version": 207, - "rule_name": "Windows Subsystem for Linux Distribution Installed", - "sha256": "a95daf1b60dd955c84fe99495d627e26da5f8c3071938bff985159d488d74b35", - "type": "eql", - "version": 109 } }, "rule_name": "Windows Subsystem for Linux Distribution Installed", @@ -9991,19 +8370,12 @@ "a22a09c2-2162-4df0-a356-9aacbeb56a04": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "DNS-over-HTTPS Enabled via Registry", "sha256": "06f788f98600e28f36873cfa890ce266317a1b101169c481fb3099d9c0e35eae", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "DNS-over-HTTPS Enabled via Registry", - "sha256": "db4b51eff904ef0ef94f2e68fa3ac4e7e64a9bc8c6e03af8a426537789e233c8", - "type": "eql", - "version": 212 } }, "rule_name": "DNS-over-HTTPS Enabled via Registry", @@ -10032,7 +8404,7 @@ "a2d04374-187c-4fd9-b513-3ad4e7fdd67a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "PowerShell Mailbox Collection Script", "sha256": "9da52a8d28edcb2f709109145e35bbb279d16227c6d4836c727a6764e3fffd58", @@ -10048,19 +8420,12 @@ "a3ea12f3-0d4e-4667-8b44-4230c63f3c75": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Execution via local SxS Shared Module", "sha256": "c70b5b61b3ea697efa1bbf34aede51b77d26f0af37f29414c403967c589fa37a", "type": "eql", "version": 109 - }, - "8.13": { - "max_allowable_version": 307, - "rule_name": "Execution via local SxS Shared Module", - "sha256": "7f90a2bcf9eeaff4a2dc027ec117964bf311dedcbc86cba03a8615c9780c68bc", - "type": "eql", - "version": 209 } }, "rule_name": "Execution via local SxS Shared Module", @@ -10131,19 +8496,12 @@ "a624863f-a70d-417f-a7d2-7a404638d47f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Suspicious MS Office Child Process", "sha256": "5c80f53958876a026ffb64b1eeee262e9fc7df01ceba845b9e2d9690744fc22a", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Suspicious MS Office Child Process", - "sha256": "bb2821c8c28461a976dec059fb9da7427ebafa6082a3aa9095dc1b42eabb8054", - "type": "eql", - "version": 214 } }, "rule_name": "Suspicious MS Office Child Process", @@ -10178,19 +8536,12 @@ "a7e7bfa3-088e-4f13-b29e-3986e0e756b8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Credential Acquisition via Registry Hive Dumping", "sha256": "f94eed7bd541165126c32c94597db40548996aafff6604d4461961c9daa182ee", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Credential Acquisition via Registry Hive Dumping", - "sha256": "b114be44b544deba03a1417c2ce3c4a5e94689f375f28e7a41fefee718c6c001", - "type": "eql", - "version": 212 } }, "rule_name": "Credential Acquisition via Registry Hive Dumping", @@ -10255,7 +8606,7 @@ "a9b05c3b-b304-4bf9-970d-acdfaef2944c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Persistence via Hidden Run Key Detected", "sha256": "521b0deac4fa27230216cb8daf48bee86c9bbef64c5b0dc90d5dbd5acbb31f0e", @@ -10281,16 +8632,6 @@ "version": 105 }, "aa895aea-b69c-4411-b110-8d7599634b30": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 211, - "rule_name": "System Log File Deletion", - "sha256": "9e7b2926bab16d0e65d0b84a1ec35d2ebfe3b10e1f219c4a9f7a8d87a9e5a132", - "type": "eql", - "version": 113 - } - }, "rule_name": "System Log File Deletion", "sha256": "af1173cc43f540a885c1fe5ff3ca083ca2e96ae5d484216e8cafe707ef9ef2b3", "type": "eql", @@ -10299,7 +8640,7 @@ "aa9a274d-6b53-424d-ac5e-cb8ca4251650": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Remotely Started Services via RPC", "sha256": "c5ae21879f28fadb1daca353f3c354f8f96a89ebe15eb191af73bbe85a2e1b0f", @@ -10325,7 +8666,6 @@ "version": 9 }, "aabdad51-51fb-4a66-9d82-3873e42accb8": { - "min_stack_version": "8.13", "rule_name": "GRUB Configuration Generation through Built-in Utilities", "sha256": "6c9d7d72e70ba8fa7028586f7dd96f22a714aea37e9b6a748c48f4c2b84cf5bd", "type": "eql", @@ -10338,7 +8678,6 @@ "version": 117 }, "ab8f074c-5565-4bc4-991c-d49770e19fc9": { - "min_stack_version": "8.13", "rule_name": "AWS S3 Object Encryption Using External KMS Key", "sha256": "c58bc9bcee72af710a07f880ed3df3eceef229e97454f6ad449273d078b06c4b", "type": "esql", @@ -10347,7 +8686,7 @@ "abae61a8-c560-4dbd-acca-1e1438bff36b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Unusual Windows Process Calling the Metadata Service", "sha256": "83e5654634806cf836873526072beb4a411dbe215b4be002f799dc0eb0866d82", @@ -10369,19 +8708,12 @@ "ac5012b8-8da8-440b-aaaf-aedafdea2dff": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Suspicious WerFault Child Process", "sha256": "5a3182ca2012152d9bd5c912111d82b1f3214a893d6da8417d00cde83cc42f7b", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 414, - "rule_name": "Suspicious WerFault Child Process", - "sha256": "9e5fa90d4dcc2b7ba457b5d5c1701304fd158e99a68fb7fddee7dee79f9b55f3", - "type": "eql", - "version": 316 } }, "rule_name": "Suspicious WerFault Child Process", @@ -10390,16 +8722,6 @@ "version": 416 }, "ac531fcc-1d3b-476d-bbb5-1357728c9a37": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Git Hook Created or Modified", - "sha256": "ec16be4f5fe86ad7212a2520875b8f40ee71728666d7085220d272f1e3929d89", - "type": "eql", - "version": 4 - } - }, "rule_name": "Git Hook Created or Modified", "sha256": "0c1a8c2bb10aaf8e8c9dc4c3c70b9fcafe1230ffe0687aa31e5909bf176ee7e9", "type": "eql", @@ -10408,19 +8730,12 @@ "ac5a2759-5c34-440a-b0c4-51fe674611d6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Outlook Home Page Registry Modification", "sha256": "9e311415c8086b3934da0eeaa5ccac777e192f9c2c9953b705e3368c14fad664", "type": "eql", "version": 2 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Outlook Home Page Registry Modification", - "sha256": "981f0b0dbe49943a8536ee475f57749dedc4e10f1c32351e9ee5c122813eed48", - "type": "eql", - "version": 102 } }, "rule_name": "Outlook Home Page Registry Modification", @@ -10431,7 +8746,7 @@ "ac6bc744-e82b-41ad-b58d-90654fa4ebfb": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "WPS Office Exploitation via DLL Hijack", "sha256": "f0b9a400aad8092fd6bd78cf6124173e5d87d3a8d40fb37af54e7611a60734de", @@ -10459,7 +8774,7 @@ "ac96ceb8-4399-4191-af1d-4feeac1f1f46": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Potential Invoke-Mimikatz PowerShell Script", "sha256": "73aa4e201e1220c47c689009c0c24f4ef6a0dcdab57655d7f25c5525472d28b4", @@ -10493,19 +8808,12 @@ "acf738b5-b5b2-4acc-bad9-1e18ee234f40": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Suspicious Managed Code Hosting Process", "sha256": "71cf5c81124dd45113bcb530642c295387bd2b68ee1236cb2a3e8e2f0f0aca2a", "type": "eql", "version": 109 - }, - "8.13": { - "max_allowable_version": 307, - "rule_name": "Suspicious Managed Code Hosting Process", - "sha256": "86ac334bd5ab8b6d729a0fd45b6134932f7b204b865b83dd786664d0984c3da3", - "type": "eql", - "version": 209 } }, "rule_name": "Suspicious Managed Code Hosting Process", @@ -10516,19 +8824,12 @@ "ad0d2742-9a49-11ec-8d6b-acde48001122": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Signed Proxy Execution via MS Work Folders", "sha256": "ce99c263910efa69241137ea09accded8b37ab436213bd6a80d3c8736c01d957", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Signed Proxy Execution via MS Work Folders", - "sha256": "d7fd7b183cdcd959de4cad44e21af6a406556b7a2d7848338dff1bda0a4e4947", - "type": "eql", - "version": 210 } }, "rule_name": "Signed Proxy Execution via MS Work Folders", @@ -10549,16 +8850,6 @@ "version": 206 }, "ad5a3757-c872-4719-8c72-12d3f08db655": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Openssl Client or Server Activity", - "sha256": "8eb908bf23fa02ea31de0dcd624ff3541d1bc60c2389d04820670c32bd4b7244", - "type": "eql", - "version": 3 - } - }, "rule_name": "Openssl Client or Server Activity", "sha256": "075631e1ef46d21f816f96cd248fbd08db4840dda4f701989973b31ee3dc8dcb", "type": "eql", @@ -10573,7 +8864,7 @@ "ad84d445-b1ce-4377-82d9-7c633f28bf9a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Suspicious Portable Executable Encoded in Powershell Script", "sha256": "e36bc47e8ad58d550eb0511c38b7e7ebe9f68e088ec6215f78f7a2780d0f4e24", @@ -10593,32 +8884,12 @@ "version": 107 }, "ad959eeb-2b7b-4722-ba08-a45f6622f005": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 103, - "rule_name": "Suspicious APT Package Manager Execution", - "sha256": "a1f733e8c14c8a8ddb91a5c919f8598d6578b992ab231ea6130ddff737d80b25", - "type": "eql", - "version": 5 - } - }, "rule_name": "Suspicious APT Package Manager Execution", "sha256": "290226c3c245c0651561503b7e5851aa8176ccbb1907d504d82489d72d110b36", "type": "eql", "version": 106 }, "adb961e0-cb74-42a0-af9e-29fc41f88f5f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "File Transfer or Listener Established via Netcat", - "sha256": "883178d57a5f0e0cf1ea5d9e4c778051a895d0e41a27aea175cfeec0058c9573", - "type": "eql", - "version": 111 - } - }, "rule_name": "File Transfer or Listener Established via Netcat", "sha256": "c88c77cee5c1ccbc6718afa7c168a3a9e42405d8647f11cde44e6f0355fd5399", "type": "eql", @@ -10631,16 +8902,6 @@ "version": 7 }, "ae343298-97bc-47bc-9ea2-5f2ad831c16e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 104, - "rule_name": "Suspicious File Creation via Kworker", - "sha256": "cc84e69331853cce8fdc6642b517c1976575b91f66f2e049315267bc2bc1c035", - "type": "eql", - "version": 6 - } - }, "rule_name": "Suspicious File Creation via Kworker", "sha256": "946a500a38cf03cc2200ba5c9f94b883db01f72d046965428ba893157a5c0fb1", "type": "eql", @@ -10649,19 +8910,12 @@ "ae8a142c-6a1d-4918-bea7-0b617e99ecfa": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Suspicious Execution via Microsoft Office Add-Ins", "sha256": "e98a3d6c4df8d691ad52d2e09453788cdd9059b5d1d1417f8c27adb82ad82604", "type": "eql", "version": 6 - }, - "8.13": { - "max_allowable_version": 204, - "rule_name": "Suspicious Execution via Microsoft Office Add-Ins", - "sha256": "6f87d083a88525ef7eb03a6d4dde91d57fecb67021008268bbe38eddcb8de46b", - "type": "eql", - "version": 106 } }, "rule_name": "Suspicious Execution via Microsoft Office Add-Ins", @@ -10690,7 +8944,7 @@ "afcce5ad-65de-4ed2-8516-5e093d3ac99a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Local Scheduled Task Creation", "sha256": "153a680562c2db766ddc13960ff0b1b1d40590dbbf944177fdb07680c4695cbe", @@ -10728,7 +8982,6 @@ "version": 107 }, "b0450411-46e5-46d2-9b35-8b5dd9ba763e": { - "min_stack_version": "8.13", "rule_name": "Potential Denial of Azure OpenAI ML Service", "sha256": "e06e9851654f73dc96d981f25bb9fe7241126b9b028623c499bea1026e7e7bff", "type": "esql", @@ -10737,19 +8990,12 @@ "b0638186-4f12-48ac-83d2-47e686d08e82": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Netsh Helper DLL", "sha256": "ae6521e56ff6823f52f0061b21556a43efe712f7fd43485bcc1e437849bb0c4d", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "Netsh Helper DLL", - "sha256": "f6a3950e6a53ae6b222eafb2db8745cb0c160be006a075c08b5fd6a0a7f9a7aa", - "type": "eql", - "version": 103 } }, "rule_name": "Netsh Helper DLL", @@ -10758,23 +9004,12 @@ "version": 203 }, "b15a15f2-becf-475d-aa69-45c9e0ff1c49": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Hidden Directory Creation via Unusual Parent", - "sha256": "6108a4f29f29a7a3de508648ab5fc9681b4307662435aa380267f50682002e00", - "type": "eql", - "version": 2 - } - }, "rule_name": "Hidden Directory Creation via Unusual Parent", "sha256": "cf1573124222ea0894d4b604d5b227b43a2853f0b399f63d080624ef5a1144c8", "type": "eql", "version": 103 }, "b1773d05-f349-45fb-9850-287b8f92f02d": { - "min_stack_version": "8.13", "rule_name": "Potential Abuse of Resources by High Token Count and Large Response Sizes", "sha256": "0ec57bc339f3fce1eca49752d9517e31d376889501714169d4c2e86fc43c6d2e", "type": "esql", @@ -10789,7 +9024,7 @@ "b2318c71-5959-469a-a3ce-3a0768e63b9c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Potential Network Share Discovery", "sha256": "e984a3d3d48ac2c527b8cc9639ad36794477d63017e31f65023ddef04404f01d", @@ -10809,16 +9044,6 @@ "version": 105 }, "b25a7df2-120a-4db2-bd3f-3e4b86b24bee": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 211, - "rule_name": "Remote File Copy via TeamViewer", - "sha256": "0d0bd0de1c42b394ca6d718a32761db9128689309c818676ea02bd44009e6f48", - "type": "eql", - "version": 113 - } - }, "rule_name": "Remote File Copy via TeamViewer", "sha256": "c8f3a33a1eda62ed530a6fc161bba9b0b5971ab42727c08f73a793be0b2199f8", "type": "eql", @@ -10833,7 +9058,7 @@ "b29ee2be-bf99-446c-ab1a-2dc0183394b8": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Network Connection via Compiled HTML File", "sha256": "8eed8d54357b27cc75f72fb6d8bfbf8329b2bd2a0c09b43187d7132a3a6e195c", @@ -10861,19 +9086,12 @@ "b41a13c6-ba45-4bab-a534-df53d0cfed6a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Suspicious Endpoint Security Parent Process", "sha256": "bb3314617957ebc4e0040f77083a7b5191ad7d4aac12c6f8e24d76b9157acc0d", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Suspicious Endpoint Security Parent Process", - "sha256": "b5f67f0db406d5c2ba14017d2992671bb8f8d5baecbff16bb3dc5c7a9f5349fc", - "type": "eql", - "version": 215 } }, "rule_name": "Suspicious Endpoint Security Parent Process", @@ -10884,19 +9102,12 @@ "b43570de-a908-4f7f-8bdb-b2df6ffd8c80": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Code Signing Policy Modification Through Built-in tools", "sha256": "827b2e6312c74d28a9c2c605507eb0ece093b284e60e26bfc9107c6733929d1b", "type": "eql", "version": 11 - }, - "8.13": { - "max_allowable_version": 208, - "rule_name": "Code Signing Policy Modification Through Built-in tools", - "sha256": "880efdb0e8afa50b33a2244e2d322195958eb94a5cf7d3350bc81687308d4ed0", - "type": "eql", - "version": 111 } }, "rule_name": "Code Signing Policy Modification Through Built-in tools", @@ -10919,7 +9130,7 @@ "b483365c-98a8-40c0-92d8-0458ca25058a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "At.exe Command Lateral Movement", "sha256": "a1aa72dc7cf218498b4bd3cb3adceb831db178df81c7bcd254159323dda53cc1", @@ -10935,7 +9146,7 @@ "b4bb1440-0fcb-4ed1-87e5-b06d58efc5e9": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Delete an Okta Policy", "sha256": "c8c6556d38f9955cc734b183b4e55614674315ba1a83737244551d638477aa88", @@ -10964,19 +9175,12 @@ "b5877334-677f-4fb9-86d5-a9721274223b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Clearing Windows Console History", "sha256": "d42b2a9e2f10c1fcdb5ef9f4e61976c421ed73777e0d9e8ce2cf19cd049ea169", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Clearing Windows Console History", - "sha256": "d749f074e83e0054eee1daa97f50831d810c8082d16bb985c7e98ff4618ec2c7", - "type": "eql", - "version": 213 } }, "rule_name": "Clearing Windows Console History", @@ -10987,19 +9191,12 @@ "b5ea4bfe-a1b2-421f-9d47-22a75a6f2921": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Volume Shadow Copy Deleted or Resized via VssAdmin", "sha256": "efddb07094d4112b3fe52e056949b21c437249bb7173dcd0184fef80a1591834", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Volume Shadow Copy Deleted or Resized via VssAdmin", - "sha256": "3712d140a6e40ecb5f5069fda566444132ed4b17f3d0102195b93ebae8b4175e", - "type": "eql", - "version": 213 } }, "rule_name": "Volume Shadow Copy Deleted or Resized via VssAdmin", @@ -11022,7 +9219,7 @@ "b64b183e-1a76-422d-9179-7b389513e74d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Windows Script Interpreter Executing Process via WMI", "sha256": "60fa1c1f92316dff5dbafafb8828c4493eb084e0a892fef14665afb65d337269", @@ -11038,19 +9235,12 @@ "b661f86d-1c23-4ce7-a59e-2edbdba28247": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Potential Veeam Credential Access Command", "sha256": "4e3ae75a438564e128dbbe0d7dfbb9db97cbd49cea4ca9c060dffec9d64e974b", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "Potential Veeam Credential Access Command", - "sha256": "7fc925d9354790c0cb64f217ce0c978632281ba46ab5e671f3f3d092d609f03c", - "type": "eql", - "version": 104 } }, "rule_name": "Potential Veeam Credential Access Command", @@ -11061,7 +9251,7 @@ "b66b7e2b-d50a-49b9-a6fc-3a383baedc6b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Potential Privilege Escalation via Service ImagePath Modification", "sha256": "84cb2fa184205ec6c7b5ebef44c3cf43d7a24ecba9aec4c0f148e7a5973fe61e", @@ -11083,7 +9273,7 @@ "b719a170-3bdb-4141-b0e3-13e3cf627bfe": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Deactivate an Okta Policy", "sha256": "bab968eb40f5ad626342a32f0e22e901245c3618d0f488c7dbc51fd7db2ce2c7", @@ -11112,7 +9302,7 @@ "b8075894-0b62-46e5-977c-31275da34419": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Administrator Privileges Assigned to an Okta Group", "sha256": "0041448b174d360c353186f2289154e2647e516ccf083b80c30bbe9a7e80e4f5", @@ -11141,7 +9331,7 @@ "b8386923-b02c-4b94-986a-d223d9b01f88": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "PowerShell Invoke-NinjaCopy script", "sha256": "5378b4cd6c7252bdbb61701c4637a20d365562603144a04e17b271ccfaa83a21", @@ -11157,19 +9347,12 @@ "b83a7e96-2eb3-4edf-8346-427b6858d3bd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Creation or Modification of Domain Backup DPAPI private key", "sha256": "07495ad3087d7d941d4ac6b44ccb6b4afffd0b7a10b6cd91e41dc91e2c8bf5df", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 410, - "rule_name": "Creation or Modification of Domain Backup DPAPI private key", - "sha256": "dbe3ce72ae96d9a388571dbaee69e57b2e0783bfb28d89c12682e731babdc79f", - "type": "eql", - "version": 312 } }, "rule_name": "Creation or Modification of Domain Backup DPAPI private key", @@ -11180,7 +9363,7 @@ "b86afe07-0d98-4738-b15d-8d7465f95ff5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Network Connection via MsXsl", "sha256": "6fa622d8cf25c559993ee681c4c59fe4875676f7a1e75fae7f9837ae73c39837", @@ -11196,19 +9379,12 @@ "b8f8da2d-a9dc-48c0-90e4-955c0aa1259a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Kirbi File Creation", "sha256": "c10cf18764bba367c5dc4f521024dc94ef68710285c6f90a067c4237780913a5", "type": "eql", "version": 8 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Kirbi File Creation", - "sha256": "e4040481f58c3fe815861e36ac5ce0ae5800f0c677fbfe8fb4f3b92a3ed843e3", - "type": "eql", - "version": 211 } }, "rule_name": "Kirbi File Creation", @@ -11219,19 +9395,12 @@ "b90cdde7-7e0d-4359-8bf0-2c112ce2008a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface", "sha256": "58aa89bc163a9683f9b49afe3a23214fc5db86e93510a6cec8b716e16e93cbe1", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface", - "sha256": "cbcbee9fed32c048febce9bb94050b601d2a11f48b70199fced4a32261b24be1", - "type": "eql", - "version": 210 } }, "rule_name": "UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface", @@ -11240,16 +9409,6 @@ "version": 310 }, "b910f25a-2d44-47f2-a873-aabdc0d355e6": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 212, - "rule_name": "Chkconfig Service Add", - "sha256": "86f0056ad335bea28f944aa15d086beedcd4cf45c699a155c5d200a3c5f35630", - "type": "eql", - "version": 114 - } - }, "rule_name": "Chkconfig Service Add", "sha256": "8be542194e5f7b449a76977f17589bb7036a11db9dd64f5714117a25453d652a", "type": "eql", @@ -11270,7 +9429,7 @@ "b9554892-5e0e-424b-83a0-5aef95aa43bf": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Group Policy Abuse for Privilege Addition", "sha256": "afa94a71cd99d31b1c816a7710f3e00e86c7854df6db0f251d9194ed981a82b7", @@ -11292,19 +9451,12 @@ "b9960fef-82c6-4816-befa-44745030e917": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "SolarWinds Process Disabling Services via Registry", "sha256": "30d3fcfb86a4c9e23c5563059dc2df4b75f106ceedf2a7f57f7731cb984430bc", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "SolarWinds Process Disabling Services via Registry", - "sha256": "021d6661e231a18c2c0c62fe88c1b3a16cf3dfa20e449e7d6c704c50f70616ce", - "type": "eql", - "version": 212 } }, "rule_name": "SolarWinds Process Disabling Services via Registry", @@ -11313,16 +9465,6 @@ "version": 312 }, "b9b14be7-b7f4-4367-9934-81f07d2f63c4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "File Creation by Cups or Foomatic-rip Child", - "sha256": "19b3cd102fa17756195c9b9ed7ab06bb5a730f2d79302f0afa39106c89e7525e", - "type": "eql", - "version": 2 - } - }, "rule_name": "File Creation by Cups or Foomatic-rip Child", "sha256": "9e1dc7c6029f13f97226975ccefeaa350760e8b64f53830c0dc035cc458248e9", "type": "eql", @@ -11331,7 +9473,7 @@ "ba342eb2-583c-439f-b04d-1fdd7c1417cc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Unusual Windows Network Activity", "sha256": "cd715d2616e427081beaa901230dba625ab6c14e52d0571ae643a92f04c77435", @@ -11359,7 +9501,7 @@ "baa5d22c-5e1c-4f33-bfc9-efa73bb53022": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Suspicious Image Load (taskschd.dll) from MS Office", "sha256": "998cfcfee5231e24bd5fb08c5921e0c9915f8d4b9db65d1b7daaa574cbf601af", @@ -11465,7 +9607,7 @@ "bd2c86a0-8b61-4457-ab38-96943984e889": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 214, "rule_name": "PowerShell Keylogging Script", "sha256": "0a89a374c16157d812750b375b94189e976d23406e4d8b78579bfa2b3128dd7e", @@ -11481,7 +9623,7 @@ "bd3d058d-5405-4cee-b890-337f09366ba2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Potential Defense Evasion via CMSTP.exe", "sha256": "1a4b9e6b364c8dab7b70af95029c1837cef25faa14161bce57283c750b0f6c1b", @@ -11497,7 +9639,7 @@ "bd7eefee-f671-494e-98df-f01daf9e5f17": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Suspicious Print Spooler Point and Print DLL", "sha256": "e65486c1eace3f2cba2f77b32a8523d31ee20a81635805ba14e9344aff57dabc", @@ -11519,7 +9661,7 @@ "bdcf646b-08d4-492c-870a-6c04e3700034": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Potential Privileged Escalation via SamAccountName Spoofing", "sha256": "ca3c535c19bcb70517a067c7f2fee45d4cda7183c15f51ff65edc5558f9180d4", @@ -11551,7 +9693,7 @@ "bdfebe11-e169-42e3-b344-c5d2015533d3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Suspicious Windows Process Cluster Spawned by a Host", "sha256": "a2ccf5e3e960c49d64850d992659f30b31d2b4619143f6ace9586298ada41e55", @@ -11573,19 +9715,12 @@ "be8afaed-4bcd-4e0a-b5f9-5562003dde81": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Searching for Saved Credentials via VaultCmd", "sha256": "b92d79f08cb700838477ef425e6e82c0645fa7621fc8db3acfcacbe1b383f49c", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Searching for Saved Credentials via VaultCmd", - "sha256": "83ee3ea43af4877d7c995fd8d7a2ef67b13bbdf1e5ef140fad511c76c5676d9d", - "type": "eql", - "version": 213 } }, "rule_name": "Searching for Saved Credentials via VaultCmd", @@ -11614,7 +9749,7 @@ "bfeaf89b-a2a7-48a3-817f-e41829dc61ee": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Suspicious DLL Loaded for Persistence or Privilege Escalation", "sha256": "7378116f20ca82f38e2d2d44d954660fb4b53cc6eae4276a1084e6a27ae5cf7f", @@ -11636,19 +9771,12 @@ "c0429aa8-9974-42da-bfb6-53a0a515a145": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Creation or Modification of a new GPO Scheduled Task or Service", "sha256": "7e6ca9dcd52afbbcb0b9a55e6aa6e2769fa1ec0eea2be911c612512a3d980c07", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Creation or Modification of a new GPO Scheduled Task or Service", - "sha256": "2c89d3ecf4ae5e9471d08131a67258ada5c25e166066700187f8fb376b224e4b", - "type": "eql", - "version": 211 } }, "rule_name": "Creation or Modification of a new GPO Scheduled Task or Service", @@ -11657,7 +9785,6 @@ "version": 311 }, "c04be7e0-b0fc-11ef-a826-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "AWS IAM Login Profile Added for Root", "sha256": "260baba4a026a272e648f568530059f1eea3a4f0c91f0895da0a4110d7f684aa", "type": "esql", @@ -11678,7 +9805,7 @@ "c124dc1b-cef2-4d01-8d74-ff6b0d5096b6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "PowerShell Script with Windows Defender Tampering Capabilities", "sha256": "5c39497f70b4e79c852ff920c53d16372dc40b66f86e903ce98d506347d5aca2", @@ -11730,19 +9857,12 @@ "c25e9c87-95e1-4368-bfab-9fd34cf867ec": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Microsoft IIS Connection Strings Decryption", "sha256": "fc1b233c930cf034d1c534a92b4ee42fffb15b398da01bad0b93741527b11b4d", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Microsoft IIS Connection Strings Decryption", - "sha256": "876985abcedfa9f369eb1b552bcf96e7ba482aee631b990fce2007928b0355cd", - "type": "eql", - "version": 213 } }, "rule_name": "Microsoft IIS Connection Strings Decryption", @@ -11771,7 +9891,7 @@ "c2d90150-0133-451c-a783-533e736c12d7": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Mshta Making Network Connections", "sha256": "1df29ad5d0ca0a28702b68944cb3950151ce264faeed1d0cac6cdc59be122b4b", @@ -11805,19 +9925,12 @@ "c3b915e0-22f3-4bf7-991d-b643513c722f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Persistence via BITS Job Notify Cmdline", "sha256": "2f351a320cf7736fa0382f0a514fc587d7a9a6e9df3e0fa798996b1378845e86", "type": "eql", "version": 109 - }, - "8.13": { - "max_allowable_version": 409, - "rule_name": "Persistence via BITS Job Notify Cmdline", - "sha256": "858019a92e6dbfe1af3a06f1d96710314aa12802e6db988f1f4a9c5bd6fbfe5a", - "type": "eql", - "version": 311 } }, "rule_name": "Persistence via BITS Job Notify Cmdline", @@ -11834,19 +9947,12 @@ "c4210e1c-64f2-4f48-b67e-b5a8ffe3aa14": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Mounting Hidden or WebDav Remote Shares", "sha256": "7da7deae7aaaaa19159214551ee72b6c0cf82a2eca4ae8edb3eaefe8aa0a69a8", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Mounting Hidden or WebDav Remote Shares", - "sha256": "2189d24d38c91a875a7ef420d330d9f074f3f874a38e25a6082487a328b98b28", - "type": "eql", - "version": 212 } }, "rule_name": "Mounting Hidden or WebDav Remote Shares", @@ -11857,19 +9963,12 @@ "c4818812-d44f-47be-aaef-4cfb2f9cc799": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Suspicious Print Spooler File Deletion", "sha256": "04b3ecf212987b57bdaedbb14a301b6f913473e5abb301dc94b6371c56d73567", "type": "eql", "version": 108 - }, - "8.13": { - "max_allowable_version": 306, - "rule_name": "Suspicious Print Spooler File Deletion", - "sha256": "3cde3fd44462edc279d64b412008d521638ddabb0029d151dc594348b04ed627", - "type": "eql", - "version": 208 } }, "rule_name": "Suspicious Print Spooler File Deletion", @@ -11886,7 +9985,7 @@ "c55badd3-3e61-4292-836f-56209dc8a601": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Attempted Private Key Access", "sha256": "ca0b00b33c8214c0a733b6e9ab2291c4a4e2bc92103a928da8778c792f66d428", @@ -11900,7 +9999,6 @@ "version": 108 }, "c5637438-e32d-4bb3-bc13-bd7932b3289f": { - "min_stack_version": "8.13", "rule_name": "Unusual Base64 Encoding/Decoding Activity", "sha256": "0a148e281a7113c56b07159b06c263d44a96451217b4ed1cfb60d2187f87efd7", "type": "esql", @@ -11909,7 +10007,7 @@ "c5677997-f75b-4cda-b830-a75920514096": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Service Path Modification via sc.exe", "sha256": "a2d3d1147504ad2b3c7930bba24c2055e523d84b2feeb737211417cb72d8eb56", @@ -11925,19 +10023,12 @@ "c57f8579-e2a5-4804-847f-f2732edc5156": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Potential Remote Desktop Shadowing Activity", "sha256": "f23375e5d2e676c1e1abe448a171c858dc5ad2300e66ef5c599e7e8325cb3390", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Potential Remote Desktop Shadowing Activity", - "sha256": "fc5dcf6dd48339a257eefaebdb911d38f7a3a6bfd632423bee74a204c7834344", - "type": "eql", - "version": 210 } }, "rule_name": "Potential Remote Desktop Shadowing Activity", @@ -11954,7 +10045,7 @@ "c5c9f591-d111-4cf8-baec-c26a39bc31ef": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Potential Credential Access via Renamed COM+ Services DLL", "sha256": "7e9ee856f86f121f008eb8a3304b4955828d5b4d5333a47de3f36d478e0562e7", @@ -11970,19 +10061,12 @@ "c5ce48a6-7f57-4ee8-9313-3d0024caee10": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Installation of Custom Shim Databases", "sha256": "e23bdb57b42ec1bbefbace5a408e8ede22db9bd8be59fae66e1ed6803db76173", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Installation of Custom Shim Databases", - "sha256": "5a38f511fb995bba2a90739bb1fb7a241b0db108f50e9c84fb52f75652a1ab64", - "type": "eql", - "version": 210 } }, "rule_name": "Installation of Custom Shim Databases", @@ -11993,19 +10077,12 @@ "c5dc3223-13a2-44a2-946c-e9dc0aa0449c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Microsoft Build Engine Started by an Office Application", "sha256": "4daab056bff3e4d5ae1ad7c4643448ae6fa836f83f095a5cc615f506cad68e8c", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Microsoft Build Engine Started by an Office Application", - "sha256": "9a5614b3e8f31ae092611d49189818157e18dda6ceb19becc0f624b2a81938ff", - "type": "eql", - "version": 212 } }, "rule_name": "Microsoft Build Engine Started by an Office Application", @@ -12020,7 +10097,6 @@ "version": 103 }, "c5fc788c-7576-4a02-b3d6-d2c016eb85a6": { - "min_stack_version": "8.13", "rule_name": "Initramfs Unpacking via unmkinitramfs", "sha256": "e0db18142f2246b20e8ced81755abfe720896bdb3f739e08b18c4aab3a6a9f43", "type": "eql", @@ -12029,19 +10105,12 @@ "c6453e73-90eb-4fe7-a98c-cde7bbfc504a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Remote File Download via MpCmdRun", "sha256": "67e77129c5ce0eb04df88c0d64d4f387ef1de59bc03f8d9e7eb11e9c050cd0c0", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Remote File Download via MpCmdRun", - "sha256": "8ca38e918ccb9a3bebd448356f11e4ebbbdd1fde86f8cf71f7b8c36eedc5ae79", - "type": "eql", - "version": 215 } }, "rule_name": "Remote File Download via MpCmdRun", @@ -12056,7 +10125,6 @@ "version": 100 }, "c6655282-6c79-11ef-bbb5-f661ea17fbcc": { - "min_stack_version": "8.13", "rule_name": "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source", "sha256": "5dc411adacd7845d2c32dfe1d1b08f2b7cfb75f5e07a9ca693f8b1050edb2fa3", "type": "esql", @@ -12065,7 +10133,7 @@ "c749e367-a069-4a73-b1f2-43a3798153ad": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Delete an Okta Network Zone", "sha256": "dad15ba894bcc5ff04c6d29ad18348d0ae785598205d8bfce378e6652e599f4b", @@ -12088,7 +10156,7 @@ "c74fd275-ab2c-4d49-8890-e2943fa65c09": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Attempt to Modify an Okta Application", "sha256": "759198a89c60e9ee7a73bbd3954fd8b6224469a0a0e9f9ba0f9006b461325f05", @@ -12123,7 +10191,7 @@ "c7894234-7814-44c2-92a9-f7d851ea246a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Unusual Network Connection via DllHost", "sha256": "1cd890b963ab7a701f5a6c45943d20f22cb173ff36b6ca80955b13239be44860", @@ -12145,7 +10213,7 @@ "c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Unusual File Modification by dns.exe", "sha256": "a3a91a39decef3a359f4dc95bc8be0401664ca49546b526ad694a3154ce425b6", @@ -12209,19 +10277,12 @@ "c8b150f0-0164-475b-a75e-74b47800a9ff": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Suspicious Startup Shell Folder Modification", "sha256": "b02f2bf5fccfed2accfb810dd6c38be499cc9fd52c4d23309848eb8170f374a8", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Suspicious Startup Shell Folder Modification", - "sha256": "c33b3be4b6a67c4dae7fba0831280618a7986cfaaebd4795ec7543db5a63792b", - "type": "eql", - "version": 214 } }, "rule_name": "Suspicious Startup Shell Folder Modification", @@ -12232,19 +10293,12 @@ "c8cccb06-faf2-4cd5-886e-2c9636cfcb87": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Disabling Windows Defender Security Settings via PowerShell", "sha256": "e9d9ba83d54f62f31234ba17fcc63773d044a09d7ccbdfb8a1a86e2031ae84a8", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Disabling Windows Defender Security Settings via PowerShell", - "sha256": "8e261fd99ec8e3455388206109e90213fa0b5ebbcbdfc02b64bfa47746b86c16", - "type": "eql", - "version": 213 } }, "rule_name": "Disabling Windows Defender Security Settings via PowerShell", @@ -12265,7 +10319,6 @@ "version": 104 }, "ca3bcacc-9285-4452-a742-5dae77538f61": { - "min_stack_version": "8.13", "rule_name": "Polkit Version Discovery", "sha256": "1daa21e6f3922e8216a3796c9b65d303920190bb2ffd847324cb55eff3517452", "type": "eql", @@ -12322,20 +10375,13 @@ "cc382a2e-7e52-11ee-9aac-f661ea17fbcd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Multiple Okta Client Addresses for a Single User Session", "sha256": "1fd88b6e7c9bf6b2176da46f28e40a91cff9746a635071e899bf47a6176021a5", "type": "threshold", "version": 2 }, - "8.13": { - "max_allowable_version": 203, - "rule_name": "Multiple Device Token Hashes for Single Okta Session", - "sha256": "7a54288765d90440a1d3da5ea46ee1746323c6b4268a456262dce90422b820cd", - "type": "esql", - "version": 105 - }, "8.14": { "max_allowable_version": 303, "rule_name": "Multiple Device Token Hashes for Single Okta Session", @@ -12370,7 +10416,7 @@ "cc92c835-da92-45c9-9f29-b4992ad621a0": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 309, "rule_name": "Attempt to Deactivate an Okta Policy Rule", "sha256": "710c62d83fdaa016127ed9e29d989f772587c9eab5f3cf3062bacc34d969a8f2", @@ -12391,7 +10437,6 @@ "version": 412 }, "cca64114-fb8b-11ef-86e2-f661ea17fbce": { - "min_stack_version": "8.13", "rule_name": "Azure Entra ID Password Spraying (Non-Interactive SFA)", "sha256": "6c701e58e1612d0491da0b3b77e57b49ef3688848d3a1110cfa3ed6f1210f903", "type": "esql", @@ -12406,7 +10451,7 @@ "cd16fb10-0261-46e8-9932-a0336278cdbe": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Modification or Removal of an Okta Application Sign-On Policy", "sha256": "6b030bb11fda77cb9c68d2328306b80b13f3d9a055aa8504740c09a98e57139d", @@ -12439,16 +10484,6 @@ "version": 105 }, "cd66a5af-e34b-4bb0-8931-57d0a043f2ef": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Kernel Module Removal", - "sha256": "d72671bd3bab4e18d0837fc746481567bb678e23b73c20159cfbcaa361b9912c", - "type": "eql", - "version": 111 - } - }, "rule_name": "Kernel Module Removal", "sha256": "838080c3b478f8de7d167a575f607f38e06a9411041e29d5a0f3c8be72f1f054", "type": "eql", @@ -12463,7 +10498,7 @@ "cd89602e-9db0-48e3-9391-ae3bf241acd8": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "MFA Deactivation with no Re-Activation for Okta User Account", "sha256": "48fedc9e649a01c172f18890a7ad9521f25b3c6d743edaaccebba5be9cb4e759", @@ -12486,7 +10521,7 @@ "cdbebdc1-dc97-43c6-a538-f26a20c0a911": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 309, "rule_name": "Okta User Session Impersonation", "sha256": "384b87d73752bb34af3573330f4217d16470de86054bb4c2c698c6434d47cdde", @@ -12509,7 +10544,7 @@ "cde1bafa-9f01-4f43-a872-605b678968b0": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 110, "rule_name": "Potential PowerShell HackTool Script by Function Names", "sha256": "a02aef3d53b50e1841dd01ee25f506dc63a897f003265f8678ef3f82fa618670", @@ -12529,23 +10564,12 @@ "version": 3 }, "ce08b55a-f67d-4804-92b5-617b0fe5a5b5": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence GitHub Event for a Personal Access Token (PAT)", - "sha256": "557be18d473f0dab21314e36e19724bf288eed2289446960d75923b23429b4ca", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence GitHub Event for a Personal Access Token (PAT)", "sha256": "17f2719c6e034e7a588f73376d1be4be6bbd4e9d1b03c74549ce551686c80a14", "type": "new_terms", "version": 204 }, "ce4a32e5-32aa-47e6-80da-ced6d234387d": { - "min_stack_version": "8.13", "rule_name": "GRUB Configuration File Creation", "sha256": "cf29eec9c7946126d6e84a24c8c726e02c45cc182ef0dbc48dcb9b388761509a", "type": "eql", @@ -12554,19 +10578,12 @@ "ce64d965-6cb0-466d-b74f-8d2c76f47f05": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "New ActiveSyncAllowedDeviceID Added via PowerShell", "sha256": "0d3af72ea1eb174dd4aa290ec7c8e3e240acb51358169eb0529e77b099a7dfca", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "New ActiveSyncAllowedDeviceID Added via PowerShell", - "sha256": "3b3aadecba256b51549529cae3290f4a09328fef1f5fabd621ec318d51a049ce", - "type": "eql", - "version": 212 } }, "rule_name": "New ActiveSyncAllowedDeviceID Added via PowerShell", @@ -12601,19 +10618,12 @@ "cff92c41-2225-4763-b4ce-6f71e5bda5e6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Execution from Unusual Directory - Command Line", "sha256": "4f9cf9d0307112c1578c481ffc975559438e8151e1dfaf9597d21d7a66cea7fa", "type": "eql", "version": 116 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "Execution from Unusual Directory - Command Line", - "sha256": "b124bcc3b121f9136501c7d4ce5d1419c47a828e64480ae750e0906b25489af2", - "type": "eql", - "version": 216 } }, "rule_name": "Execution from Unusual Directory - Command Line", @@ -12628,16 +10638,6 @@ "version": 2 }, "d00f33e7-b57d-4023-9952-2db91b1767c4": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 108, - "rule_name": "Namespace Manipulation Using Unshare", - "sha256": "0f000268fdc695dfbee160cd34e2e1321d37c12eac2a69d832aef01d5306655d", - "type": "eql", - "version": 10 - } - }, "rule_name": "Namespace Manipulation Using Unshare", "sha256": "e0b9b778b8c39963c3189778b579a80dba4ae66cc8cd73cf01120c8b0ffe0d27", "type": "eql", @@ -12652,19 +10652,12 @@ "d0e159cf-73e9-40d1-a9ed-077e3158a855": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Registry Persistence via AppInit DLL", "sha256": "4bb55e1f7ac32a17597deba9c24186c785abfcd6953b10305a596ff29a27dd63", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Registry Persistence via AppInit DLL", - "sha256": "c97fbd41a9b9ac3b79c7459e0bf3c636d1652d33043f7e530ccd2e038f258b18", - "type": "eql", - "version": 212 } }, "rule_name": "Registry Persistence via AppInit DLL", @@ -12675,19 +10668,12 @@ "d117cbb4-7d56-41b4-b999-bdf8c25648a0": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Symbolic Link to Shadow Copy Created", "sha256": "29b901e2e2a500cc3e5930938d94b49c5b7f44fe6564aadc087f290832d6d74a", "type": "eql", - "version": 114 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Symbolic Link to Shadow Copy Created", - "sha256": "ee54b6b3c0af6cbb6be3c7dd4c8f04d47eb50a579955817390e77e0cbc7eadd9", - "type": "eql", - "version": 213 + "version": 114 } }, "rule_name": "Symbolic Link to Shadow Copy Created", @@ -12728,19 +10714,12 @@ "d31f183a-e5b1-451b-8534-ba62bca0b404": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Disabling User Account Control via Registry Modification", "sha256": "34bc05c49fe69684173e6c0af5c4c6df3091c20e5dbbf5a9dd943525aba4fed7", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Disabling User Account Control via Registry Modification", - "sha256": "b4d0f51e31276b87a2d2f365694f02f3826550163ef41d500b69e5a188479123", - "type": "eql", - "version": 212 } }, "rule_name": "Disabling User Account Control via Registry Modification", @@ -12751,19 +10730,12 @@ "d331bbe2-6db4-4941-80a5-8270db72eb61": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Clearing Windows Event Logs", "sha256": "43df104be9f108fd08b8d71599f09bd2a9e4f98e5df1e6d8b0c41786bf127629", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "Clearing Windows Event Logs", - "sha256": "a10ce3920c7f51ff84dd06f0d4c83d000d591660132213cb6aa19fca1059919c", - "type": "eql", - "version": 215 } }, "rule_name": "Clearing Windows Event Logs", @@ -12774,7 +10746,7 @@ "d33ea3bf-9a11-463e-bd46-f648f2a0f4b1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Remote Windows Service Installed", "sha256": "1f3ebacad2b755fcdf9e30e67395eb3ae6c0947abedc632542b5b4eb17039d93", @@ -12790,7 +10762,7 @@ "d3551433-782f-4e22-bbea-c816af2d41c6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "WMI WBEMTEST Utility Execution", "sha256": "5a91c133bc777a7e2499b024f42ebe1be6983609c8f38e00a4d81924dc72acc8", @@ -12818,7 +10790,7 @@ "d48e1c13-4aca-4d1f-a7b1-a9161c0ad86f": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Attempt to Delete an Okta Application", "sha256": "08df81b97dfa133653055496f11e710598c74c28c4fdaf0efd0a3f3ea2cfe666", @@ -12857,16 +10829,6 @@ "version": 105 }, "d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 105, - "rule_name": "Linux init (PID 1) Secret Dump via GDB", - "sha256": "3ac7fcb80411d506306b5e742ea93bc2592f558ea93ac74f82e98b6453cf1094", - "type": "eql", - "version": 7 - } - }, "rule_name": "Linux init (PID 1) Secret Dump via GDB", "sha256": "12f7f9d6ea55e9ff587c8130acae50e3081e10e1ee41b58149e1a4cb74d2eb85", "type": "eql", @@ -12887,19 +10849,12 @@ "d563aaba-2e72-462b-8658-3e5ea22db3a6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Privilege Escalation via Windir Environment Variable", "sha256": "517d28ddbcd9550ac85394cdac2cee0844bc448d4be9b4e4aa81be52e1275002", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 307, - "rule_name": "Privilege Escalation via Windir Environment Variable", - "sha256": "76d7e76f6c26a0e245b833dbed9be07a49f80004d68992ad351a789ab93f06d6", - "type": "eql", - "version": 209 } }, "rule_name": "Privilege Escalation via Windir Environment Variable", @@ -12910,7 +10865,7 @@ "d5d86bf5-cf0c-4c06-b688-53fdc072fdfd": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Delete an Okta Policy Rule", "sha256": "6f347c2a22c881f591ab308ee4e149bb0d2460d463ea37ee64dd2a3445863f2c", @@ -12933,7 +10888,7 @@ "d61cbcf8-1bc1-4cff-85ba-e7b21c5beedc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Service Command Lateral Movement", "sha256": "0d07056086afc2ae7fc3933f654811d9b31cbcf86939f52cea27261c807c0b8c", @@ -12973,7 +10928,7 @@ "d68e95ad-1c82-4074-a12a-125fe10ac8ba": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 113, "rule_name": "System Information Discovery via Windows Command Shell", "sha256": "272699ab944dda3fb2374c7f0cba8b4585ace10fee2a21b12b9c6215519c3c29", @@ -12995,7 +10950,7 @@ "d703a5af-d5b0-43bd-8ddb-7a5d500b7da5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Modification of WDigest Security Provider", "sha256": "a44e75aa48733736e80047d4c1c565d7ba7683ae2f63255605eb0a8fc3fd8d5e", @@ -13011,19 +10966,12 @@ "d72e33fc-6e91-42ff-ac8b-e573268c5a87": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Command Execution via SolarWinds Process", "sha256": "cc15c76a2369027ba3e6633b87d7a3839f5365946de2dcfe4ec1b82a982e4641", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Command Execution via SolarWinds Process", - "sha256": "2a7761657cfa115b0d73fce0563817e7b4a07b1c776039e0570d60c26f45b79c", - "type": "eql", - "version": 214 } }, "rule_name": "Command Execution via SolarWinds Process", @@ -13038,16 +10986,6 @@ "version": 207 }, "d74d6506-427a-4790-b170-0c2a6ddac799": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 102, - "rule_name": "Suspicious Memory grep Activity", - "sha256": "be15becb96ba5f7d3bbfbb8d336acdd122a95f155d4235a4e3941eefa4d8fa70", - "type": "eql", - "version": 4 - } - }, "rule_name": "Suspicious Memory grep Activity", "sha256": "b32fe770424c2bb1f42c024250666ed6908c7309fc3bb52716853793ca7deb49", "type": "eql", @@ -13060,16 +10998,6 @@ "version": 207 }, "d76b02ef-fc95-4001-9297-01cb7412232f": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Interactive Terminal Spawned via Python", - "sha256": "aa0975e7620cba81ba4d6b2b9aa05da8913d3f309cb4803fbff2ac88f7d9a4e0", - "type": "eql", - "version": 111 - } - }, "rule_name": "Interactive Terminal Spawned via Python", "sha256": "b9ec78f42bbee517ba762cc989682ed667042fa1dbbf00a51d635480508b7d19", "type": "eql", @@ -13114,19 +11042,12 @@ "d93e61db-82d6-4095-99aa-714988118064": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "NTDS Dump via Wbadmin", "sha256": "0ec890060837395012ad0a162820039feccc988f8395fc1078f45daf4bc7abb3", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "NTDS Dump via Wbadmin", - "sha256": "021063dbb016001657028d480f2e2a48e6eaf2e544441b2ea8dd23cd9fe1deb7", - "type": "eql", - "version": 104 } }, "rule_name": "NTDS Dump via Wbadmin", @@ -13137,19 +11058,12 @@ "d99a037b-c8e2-47a5-97b9-170d076827c4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Volume Shadow Copy Deletion via PowerShell", "sha256": "9b8ad5964185c38f5bff7a86e3f4cef521ba3f743dafbe475f84111b6c97c473", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Volume Shadow Copy Deletion via PowerShell", - "sha256": "88280b0f1705bc61a7d02fd3670dfb3d6b3364732637b21cf99e9543d1a98e05", - "type": "eql", - "version": 213 } }, "rule_name": "Volume Shadow Copy Deletion via PowerShell", @@ -13160,19 +11074,12 @@ "d9ffc3d6-9de9-4b29-9395-5757d0695ecf": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Suspicious Windows Command Shell Arguments", "sha256": "fbe7d02b10b540aff7b825dc36b8716bf16c7de4668ecbad5001a3239c6c5166", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Suspicious Windows Command Shell Arguments", - "sha256": "8fd732f25e901ace558a167c84fa62b658c0f38ab260059e37ffdb4d690fb45f", - "type": "eql", - "version": 103 } }, "rule_name": "Suspicious Windows Command Shell Arguments", @@ -13183,19 +11090,12 @@ "da7733b1-fe08-487e-b536-0a04c6d8b0cd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 110, "rule_name": "Code Signing Policy Modification Through Registry", "sha256": "fc23e41a7d22a46223a5b1ed558336101405e6adad108127504e440c44d82a19", "type": "eql", "version": 12 - }, - "8.13": { - "max_allowable_version": 210, - "rule_name": "Code Signing Policy Modification Through Registry", - "sha256": "9d490d625ede5483e6874408d935d1e8ae2e654bf38990bd8ec90cac8d61e7e4", - "type": "eql", - "version": 112 } }, "rule_name": "Code Signing Policy Modification Through Registry", @@ -13212,7 +11112,7 @@ "da87eee1-129c-4661-a7aa-57d0b9645fad": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "Suspicious Service was Installed in the System", "sha256": "9a42aaff1236e24c34e84e08efd9a7e42009c0c63b347d4fe373822df560b886", @@ -13234,7 +11134,7 @@ "daafdf96-e7b1-4f14-b494-27e0d24b11f6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "Potential Pass-the-Hash (PtH) Attempt", "sha256": "6d19402e85f66e45583b1eeb0c1b22e5641e069db1d10342a0bde8f44b0fae5d", @@ -13256,19 +11156,12 @@ "db65f5ba-d1ef-4944-b9e8-7e51060c2b42": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Network-Level Authentication (NLA) Disabled", "sha256": "f070b0885fd560dca726ee750baad0826feb31d8d40ccb087eb224a1ea7abfbc", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Network-Level Authentication (NLA) Disabled", - "sha256": "042a48825a4fad14bc7163dd1ec03c4495809a3b597ef85c391fa358b2abf475", - "type": "eql", - "version": 104 } }, "rule_name": "Network-Level Authentication (NLA) Disabled", @@ -13279,19 +11172,12 @@ "db7dbad5-08d2-4d25-b9b1-d3a1e4a15efd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Execution via Windows Subsystem for Linux", "sha256": "9aadc22b5ec9cea06ee0b9088f5ccbd36a3306d609eac169139751b082504d50", "type": "eql", "version": 9 - }, - "8.13": { - "max_allowable_version": 206, - "rule_name": "Execution via Windows Subsystem for Linux", - "sha256": "a02c1d8fea25864162d20fe9d56a7b95c9cb558593d39dd4b0dbe5718022ac55", - "type": "eql", - "version": 109 } }, "rule_name": "Execution via Windows Subsystem for Linux", @@ -13306,32 +11192,12 @@ "version": 104 }, "dc0b7782-0df0-47ff-8337-db0d678bdb66": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 104, - "rule_name": "Suspicious Content Extracted or Decompressed via Funzip", - "sha256": "d4648bbfa3d971cafd0c2664cbb8da0fc57af62582278b2246e279b1c7dcaa2e", - "type": "eql", - "version": 6 - } - }, "rule_name": "Suspicious Content Extracted or Decompressed via Funzip", "sha256": "8690b4f17180de2e5b04b89a6a896c3a137fe7ebdd13e6982bfeee9fb2b135b8", "type": "eql", "version": 107 }, "dc61f382-dc0c-4cc0-a845-069f2a071704": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 101, - "rule_name": "Git Hook Command Execution", - "sha256": "dd6719030d3fe2a0ee69963aabd0b10598548861f0ca6a7ce968eb283b8a96f0", - "type": "eql", - "version": 3 - } - }, "rule_name": "Git Hook Command Execution", "sha256": "3ad68272adbc2c5c4f5b945a065b67154c91b826cef8f120af822a44d62724e1", "type": "eql", @@ -13344,23 +11210,12 @@ "version": 100 }, "dc71c186-9fe4-4437-a4d0-85ebb32b8204": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 108, - "rule_name": "Potential Hidden Process via Mount Hidepid", - "sha256": "e16de17547f45513cc6097ae2c1fafc3fb841a3d7cd4876355dfdce3bd42d171", - "type": "eql", - "version": 10 - } - }, "rule_name": "Potential Hidden Process via Mount Hidepid", "sha256": "99b4b4a9e64fa970794d90bd46d37e2ad1f23280ede41d8a8de1841b6caf8622", "type": "eql", "version": 111 }, "dc765fb2-0c99-4e57-8c11-dafdf1992b66": { - "min_stack_version": "8.13", "rule_name": "Dracut Module Creation", "sha256": "af7a3f72ed7f24e50bc14f940937bc9cf2bc1f6872e1d672d463b5165d85d1dc", "type": "eql", @@ -13369,19 +11224,12 @@ "dc9c1f74-dac3-48e3-b47f-eb79db358f57": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Volume Shadow Copy Deletion via WMIC", "sha256": "976ac05caaa7708302cfafccd5edd0af529b333c3550b12e398506b43b82e625", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Volume Shadow Copy Deletion via WMIC", - "sha256": "11d89db06537fb1ca446cbef23180ba0070a9636b860a6494c0c9fb2bb8dcbab", - "type": "eql", - "version": 213 } }, "rule_name": "Volume Shadow Copy Deletion via WMIC", @@ -13398,19 +11246,12 @@ "dca6b4b0-ae70-44eb-bb7a-ce6db502ee78": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Suspicious Execution from INET Cache", "sha256": "40d55e7663cb9633996f2dd6c03729438145e69e0239b0e638f5ee1a40d4281d", "type": "eql", "version": 5 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Suspicious Execution from INET Cache", - "sha256": "35fcbc09ebaeca1f271a2a19eea3012efb1af8eae8ba0f4a9c6736dcfbe5d7e4", - "type": "eql", - "version": 105 } }, "rule_name": "Suspicious Execution from INET Cache", @@ -13421,19 +11262,12 @@ "dd34b062-b9e3-4a6b-8c0c-6c8ca6dd450e": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Attempt to Install Kali Linux via WSL", "sha256": "26b7b9e5fd76bd0fa239139c7322893447787d8462f784bd120a62794e64b358", "type": "eql", "version": 10 - }, - "8.13": { - "max_allowable_version": 207, - "rule_name": "Attempt to Install Kali Linux via WSL", - "sha256": "0d40357f250d05884f10feb5097cb69fa88c7a4549156688aa38a58a2e133b86", - "type": "eql", - "version": 110 } }, "rule_name": "Attempt to Install Kali Linux via WSL", @@ -13454,7 +11288,6 @@ "version": 6 }, "dd983e79-22e8-44d1-9173-d57dba514cac": { - "min_stack_version": "8.13", "rule_name": "Docker Socket Enumeration", "sha256": "542d6fce1df6a18b8cd0f22e854d01e313ac186fa85f51d79f48e57ab1fb5682", "type": "eql", @@ -13463,19 +11296,12 @@ "ddab1f5f-7089-44f5-9fda-de5b11322e77": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "NullSessionPipe Registry Modification", "sha256": "84f5b0cc9b45784f5f3268b1f1cd252e3e460a30225570b04bd90ed819e7cd75", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "NullSessionPipe Registry Modification", - "sha256": "c53af1114c332c599481a0ff4eede6a5a9b7a2b80284a201c3c7c5c3ba9dae11", - "type": "eql", - "version": 211 } }, "rule_name": "NullSessionPipe Registry Modification", @@ -13484,7 +11310,6 @@ "version": 311 }, "dde13d58-bc39-4aa0-87fd-b4bdbf4591da": { - "min_stack_version": "8.13", "rule_name": "AWS IAM AdministratorAccess Policy Attached to Role", "sha256": "c129a707d58db25a4c45591577570e807c1cda2be7e4167c44a922ada89b2939", "type": "esql", @@ -13493,19 +11318,12 @@ "de9bd7e0-49e9-4e92-a64d-53ade2e66af1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Unusual Child Process from a System Virtual Process", "sha256": "d8c2c36ac62b1821bf4164411d30ffcb97ae6b3ec8b2736dffe412305fa71633", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Unusual Child Process from a System Virtual Process", - "sha256": "f9398ff0b3917ee5a9e279f22d4c8ac753ec5cc7c514744cf5c102a23ce5e265", - "type": "eql", - "version": 214 } }, "rule_name": "Unusual Child Process from a System Virtual Process", @@ -13514,16 +11332,6 @@ "version": 314 }, "debff20a-46bc-4a4d-bae5-5cdd14222795": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Base16 or Base32 Encoding/Decoding Activity", - "sha256": "2110c27e62d99781d5a1189a8ed1fe2d6a400568585a8e6573fb473f783f9761", - "type": "eql", - "version": 111 - } - }, "rule_name": "Base16 or Base32 Encoding/Decoding Activity", "sha256": "d096dd61e0fdd262df14f29f04e3818f84e1a5f4057cade79110ad3a929aac3c", "type": "eql", @@ -13544,7 +11352,7 @@ "df197323-72a8-46a9-a08e-3f5b04a4a97a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Unusual Windows User Calling the Metadata Service", "sha256": "92bb89bd0e84c9232dcf024b09b211d04bf914a34e8ebcfcc2700c0f9f4154f6", @@ -13564,16 +11372,6 @@ "version": 103 }, "df6f62d9-caab-4b88-affa-044f4395a1e0": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 208, - "rule_name": "Dynamic Linker Copy", - "sha256": "c129b0c687239213e54f4f95219e0ba6f09ce259ad97d16efe4789c56b4c1205", - "type": "eql", - "version": 110 - } - }, "rule_name": "Dynamic Linker Copy", "sha256": "f1a290ca66fac0299d00bfdb6b2303033c974c4a184dd32b9ae3e34b3b7ddc78", "type": "eql", @@ -13586,7 +11384,6 @@ "version": 205 }, "df919b5e-a0f6-4fd8-8598-e3ce79299e3b": { - "min_stack_version": "8.13", "rule_name": "AWS IAM AdministratorAccess Policy Attached to Group", "sha256": "f33b42f628062aaf94789a5880e98522fa684c465bdf6da024d16c74a4f02efc", "type": "esql", @@ -13601,19 +11398,12 @@ "dffbd37c-d4c5-46f8-9181-5afdd9172b4c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 102, "rule_name": "Potential privilege escalation via CVE-2022-38028", "sha256": "f14455fd6ea9bdc73123f4c69cb12843cfcbe7747b51b622198eb087bb953f08", "type": "eql", "version": 4 - }, - "8.13": { - "max_allowable_version": 202, - "rule_name": "Potential privilege escalation via CVE-2022-38028", - "sha256": "f7fcd4ec131f7e648b7fe8bb86887bfb768bd7bf3a006340a5e9fca5467205bd", - "type": "eql", - "version": 104 } }, "rule_name": "Potential privilege escalation via CVE-2022-38028", @@ -13636,7 +11426,7 @@ "e052c845-48d0-4f46-8a13-7d0aba05df82": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "KRBTGT Delegation Backdoor", "sha256": "be3e036bd85d0139f9025316971ebdafff2b115de3d7e46ecf4a12fc2b17fb34", @@ -13652,7 +11442,7 @@ "e0881d20-54ac-457f-8733-fe0bc5d44c55": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "System Service Discovery through built-in Windows Utilities", "sha256": "71df05db291794ae655d563c9f6cc812bb3c8ebd1f3b076fb3103cc1a9af152b", @@ -13668,7 +11458,7 @@ "e08ccd49-0380-4b2b-8d71-8000377d6e49": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "Attempts to Brute Force an Okta User Account", "sha256": "9b77e22fb6460cbdb3e85d6b43d58ba16119cf9ce64692958b30fc4ed9657bc5", @@ -13689,16 +11479,6 @@ "version": 413 }, "e0cc3807-e108-483c-bf66-5a4fbe0d7e89": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 104, - "rule_name": "Potentially Suspicious Process Started via tmux or screen", - "sha256": "6147022642131c87ac6702fa482fbae2afa75394591d2a12545a08d85336f5f2", - "type": "eql", - "version": 6 - } - }, "rule_name": "Potentially Suspicious Process Started via tmux or screen", "sha256": "afd239148a789428e9afc33cc2ed4df601459622d6b114f719be62ef217f425a", "type": "eql", @@ -13729,16 +11509,6 @@ "version": 207 }, "e19e64ee-130e-4c07-961f-8a339f0b8362": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 206, - "rule_name": "Connection to External Network via Telnet", - "sha256": "28c7ce83de51514d2b297b6590e71038a20120a59fd3f1b8f1693e98dc5c1d7d", - "type": "eql", - "version": 108 - } - }, "rule_name": "Connection to External Network via Telnet", "sha256": "9c4cb74b1de6b291bdd95cef6e4dc1db2fc043af96969f7a09811263b9866c96", "type": "eql", @@ -13751,16 +11521,6 @@ "version": 5 }, "e2258f48-ba75-4248-951b-7c885edf18c2": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 105, - "rule_name": "Suspicious Mining Process Creation Event", - "sha256": "2e1ea018087510cd48cb9978f295dfc7ae3df5e33ae6087605fe0c171ee6f7af", - "type": "eql", - "version": 7 - } - }, "rule_name": "Suspicious Mining Process Creation Event", "sha256": "b5f28770a0cb6cc57839bec21e0d78f890b72c023a9f2a1f56329aa86d0bdcf6", "type": "eql", @@ -13775,7 +11535,7 @@ "e26f042e-c590-4e82-8e05-41e81bd822ad": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Suspicious .NET Reflection via PowerShell", "sha256": "aceeffb1d2d30da61a5c975b4c978c1a8dd0687ddac7214c80ae21c9067eadfc", @@ -13815,19 +11575,12 @@ "e2e0537d-7d8f-4910-a11d-559bcf61295a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Windows Subsystem for Linux Enabled via Dism Utility", "sha256": "59e0f66055f6ca2de75fc83f80895d38b0544cb232a27c17b5ad274d18842db7", "type": "eql", "version": 10 - }, - "8.13": { - "max_allowable_version": 207, - "rule_name": "Windows Subsystem for Linux Enabled via Dism Utility", - "sha256": "d5de70a49caf18d246524ba6fa7ffeb2b6243da158fd0f838868f41a72f368d0", - "type": "eql", - "version": 110 } }, "rule_name": "Windows Subsystem for Linux Enabled via Dism Utility", @@ -13838,7 +11591,7 @@ "e2f9fdf5-8076-45ad-9427-41e0e03dc9c2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Suspicious Process Execution via Renamed PsExec Executable", "sha256": "a78175d51ef889c2e09cfd59e2c1dd26ee7b7467cde848968753b8be8402a5ff", @@ -13858,16 +11611,6 @@ "version": 105 }, "e302e6c3-448c-4243-8d9b-d41da70db582": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Potential Data Splitting Detected", - "sha256": "7b1c198e74d0e4f3d7b01f471cbcaf92ef595343883d73f4bcca641970102396", - "type": "eql", - "version": 2 - } - }, "rule_name": "Potential Data Splitting Detected", "sha256": "4cbc9c690c480e6a0c5458a4e2e93bcf347ef61202570333fb7b66342ba93b58", "type": "eql", @@ -13876,19 +11619,12 @@ "e3343ab9-4245-4715-b344-e11c56b0a47f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Process Activity via Compiled HTML File", "sha256": "820ccc16d8a4a8f7fc46cc17069ec359a736b3d3803d156ed511f05a771b7416", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Process Activity via Compiled HTML File", - "sha256": "a8cf4ae254ee226a844438801018251c0ed156dc36375ea7377e33b67efc830d", - "type": "eql", - "version": 213 } }, "rule_name": "Process Activity via Compiled HTML File", @@ -13911,7 +11647,7 @@ "e3cf38fa-d5b8-46cc-87f9-4a7513e4281d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Connection to Commonly Abused Free SSL Certificate Providers", "sha256": "15425280f466c2729b02c0af122c6c595b30165cd51c4f683fee546070d396a0", @@ -13925,16 +11661,6 @@ "version": 208 }, "e3e904b3-0a8e-4e68-86a8-977a163e21d3": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 213, - "rule_name": "Persistence via KDE AutoStart Script or Desktop File Modification", - "sha256": "3d6b19ea3b397ac9a3e1d4779f0bfbbbe891a2b9352cc8331b3d1b21b3492f86", - "type": "eql", - "version": 115 - } - }, "rule_name": "Persistence via KDE AutoStart Script or Desktop File Modification", "sha256": "465ac78f6958f74fff4f46a3ff16e69a49b534ccb7b037fa26cd2f352bd13690", "type": "eql", @@ -13943,7 +11669,7 @@ "e468f3f6-7c4c-45bb-846a-053738b3fe5d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "First Time Seen NewCredentials Logon Process", "sha256": "9041b77e8259e34d407916d77afca09bc12083780a68fa76b3ab0f545ec0a85b", @@ -13959,7 +11685,7 @@ "e48236ca-b67a-4b4e-840c-fdc7782bc0c3": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Modify an Okta Network Zone", "sha256": "e088d4ca612ade27d31a69dd5614c2f742ce616cc3e7fa7dd0f87acfabc6968b", @@ -13982,7 +11708,7 @@ "e4e31051-ee01-4307-a6ee-b21b186958f4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Service Creation via Local Kerberos Authentication", "sha256": "5c7d57bc4534a2a0e0954dc8aac857d465f5fe162da03efd1c900a9ac9680bcf", @@ -13998,7 +11724,7 @@ "e514d8cd-ed15-4011-84e2-d15147e059f1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Kerberos Pre-authentication Disabled for User", "sha256": "e4f8a8d92eb2a30728e395c24a0e1fefe6b75222d110fcf1b87cd80b2dccc30a", @@ -14038,7 +11764,7 @@ "e6e3ecff-03dd-48ec-acbd-54a04de10c68": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Possible Okta DoS Attack", "sha256": "555778fe474de3773a42ba94313153209ce4209e51a196813715a3ddfa835ff8", @@ -14079,7 +11805,7 @@ "e7125cea-9fe1-42a5-9a05-b0792cf86f5a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 206, "rule_name": "Execution of Persistent Suspicious Program", "sha256": "8e916c6e5e28236cf4e78bb6c9a7cb8991800d108c6dce8a147b6196ae27b89c", @@ -14095,7 +11821,7 @@ "e72f87d0-a70e-4f8d-8443-a6407bc34643": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Suspicious WMI Event Subscription Created", "sha256": "0eb9b50416c959551b3b273ef5326ae8b96145ec4ea717bee0033ea99d133af6", @@ -14130,19 +11856,12 @@ "e760c72b-bb1f-44f0-9f0d-37d51744ee75": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Unusual Execution via Microsoft Common Console File", "sha256": "0bea98ee6e9ce10eac166784de0d4aeceb2b4e690051357201bb91cffc7e5edb", "type": "eql", "version": 2 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Unusual Execution via Microsoft Common Console File", - "sha256": "5ff7838c257d23a22ac81dc996fa1bba6e80734971669cbf6c8f5bdfa6314f5f", - "type": "eql", - "version": 102 } }, "rule_name": "Unusual Execution via Microsoft Common Console File", @@ -14151,16 +11870,6 @@ "version": 202 }, "e7cb3cfd-aaa3-4d7b-af18-23b89955062c": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 107, - "rule_name": "Potential Linux Credential Dumping via Unshadow", - "sha256": "ecaad70591f430b71f38353b51514e955299f312f6299c043edbe78296d96c47", - "type": "eql", - "version": 9 - } - }, "rule_name": "Potential Linux Credential Dumping via Unshadow", "sha256": "962391b35148784c37d51d9d75f577a0ae8c9c855443ec35d2e4dfb3c247e942", "type": "eql", @@ -14181,7 +11890,7 @@ "e8571d5f-bea1-46c2-9f56-998de2d3ed95": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Service Control Spawned via Script Interpreter", "sha256": "e9a897b3d6e54d43b0c0b67f4ddcda48e4a01a450374c5953fbfc9e6a13c0568", @@ -14197,19 +11906,12 @@ "e86da94d-e54b-4fb5-b96c-cecff87e8787": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Installation of Security Support Provider", "sha256": "b539da6b7c1b1227bdb42936daceee9540ba7d0f3605ee4daa85bd0c836ac05a", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Installation of Security Support Provider", - "sha256": "4921dd59a49f0857c4a5a11360976efc71f083994125f28706e6071dc19c7473", - "type": "eql", - "version": 210 } }, "rule_name": "Installation of Security Support Provider", @@ -14220,7 +11922,7 @@ "e88d1fe9-b2f4-48d4-bace-a026dc745d4b": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Host Files System Changes via Windows Subsystem for Linux", "sha256": "e8fd6440c6d6d88986539c259693d1ee14c53bbebd9bce21eab23ced642d5c02", @@ -14248,7 +11950,7 @@ "e90ee3af-45fc-432e-a850-4a58cf14a457": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 310, "rule_name": "High Number of Okta User Password Reset or Unlock Attempts", "sha256": "11687f3cbf71206899bfb40ed8a027202830df829f70f0e59b649de19c51b3a4", @@ -14283,19 +11985,12 @@ "e94262f2-c1e9-4d3f-a907-aeab16712e1a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Unusual Executable File Creation by a System Critical Process", "sha256": "6ef104d85ec9575226338908f304d5def68a7412883399913f6bb68378d6decb", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Unusual Executable File Creation by a System Critical Process", - "sha256": "5f4f414a3ae8185a194ee698b33f60372d7733ed66e23b8ef56fe4c06edb3dbc", - "type": "eql", - "version": 212 } }, "rule_name": "Unusual Executable File Creation by a System Critical Process", @@ -14336,7 +12031,7 @@ "ea09ff26-3902-4c53-bb8e-24b7a5d029dd": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Unusual Process Spawned by a Parent Process", "sha256": "9305b82ec96b801a1ce3d03306069610691b62051ca30252e654c38b624f7c55", @@ -14376,7 +12071,7 @@ "eb44611f-62a8-4036-a5ef-587098be6c43": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 105, "rule_name": "PowerShell Script with Webcam Video Capture Capabilities", "sha256": "0df8fef46aadb6e55f99fcb160c20a7c50b5b97687a0ae824409284676656051", @@ -14392,7 +12087,7 @@ "eb610e70-f9e6-4949-82b9-f1c5bcd37c39": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "PowerShell Kerberos Ticket Request", "sha256": "1eca5c1ab4882b5bcf2dd344dafbd75a680f7fd7cb7bceb1c7c448fe80765bbb", @@ -14419,16 +12114,6 @@ "version": 3 }, "eb9eb8ba-a983-41d9-9c93-a1c05112ca5e": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Potential Disabling of SELinux", - "sha256": "68bbdb25d3a0f0d088bd7072fdefec01a701b6549176297cee71b31463d90ffe", - "type": "eql", - "version": 111 - } - }, "rule_name": "Potential Disabling of SELinux", "sha256": "e7211f890d92f3a7d930cfd4bc9d80fb4376b20adbbb602dd24721075ee45090", "type": "eql", @@ -14437,19 +12122,12 @@ "ebb200e8-adf0-43f8-a0bb-4ee5b5d852c6": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Mimikatz Memssp Log File Detected", "sha256": "91956d073fa6d286f31807a9450036536a930c0aaa7838a91e4ce882353f6140", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 411, - "rule_name": "Mimikatz Memssp Log File Detected", - "sha256": "68b70fb7a0759edb5d4057074ce39e0a9d16c36f7e65d6fdcdfb8e6872bfbbc7", - "type": "eql", - "version": 312 } }, "rule_name": "Mimikatz Memssp Log File Detected", @@ -14460,19 +12138,12 @@ "ebf1adea-ccf2-4943-8b96-7ab11ca173a5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "IIS HTTP Logging Disabled", "sha256": "3195012ac10b6acb9ebb4755275fdac561d8f506d8cef35b17fd47c2ab509787", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "IIS HTTP Logging Disabled", - "sha256": "ab59351227fd6484a4b159f3a14973dda7045b27ac198fe102586b190e574639", - "type": "eql", - "version": 212 } }, "rule_name": "IIS HTTP Logging Disabled", @@ -14483,19 +12154,12 @@ "ebfe1448-7fac-4d59-acea-181bd89b1f7f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Process Execution from an Unusual Directory", "sha256": "076b7a80f89f6a6f1a3081a38ce953a5acf2175da6922f04cbe0f6d6a55b0356", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Process Execution from an Unusual Directory", - "sha256": "86c59576f4ae4cad721a7fd636edf4192fd6dac90a899e71bc8c3d9ebb79154b", - "type": "eql", - "version": 215 } }, "rule_name": "Process Execution from an Unusual Directory", @@ -14548,19 +12212,12 @@ "eda499b8-a073-4e35-9733-22ec71f57f3a": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "AdFind Command Activity", "sha256": "d60af1f28f9f81685a9aa0c7a36a0cb1c35ba51859da6d4ebddbc8bb02ac9907", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "AdFind Command Activity", - "sha256": "48f50e30ab0904b32f28ab124297e93c7d20c9f3b7601a91abe9ee1f4e5fcb08", - "type": "eql", - "version": 214 } }, "rule_name": "AdFind Command Activity", @@ -14571,7 +12228,7 @@ "edb91186-1c7e-4db8-b53e-bfa33a1a0a8a": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 308, "rule_name": "Attempt to Deactivate an Okta Application", "sha256": "16079a140012eb657c5c76c259629f9baab9f15ea6434d1329b8a947a2622c94", @@ -14594,19 +12251,12 @@ "edf8ee23-5ea7-4123-ba19-56b41e424ae3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "ImageLoad via Windows Update Auto Update Client", "sha256": "58dd0e1e34abe8443249ad67198996b183471f4fc2f883d57058fd29a584325c", "type": "eql", "version": 115 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "ImageLoad via Windows Update Auto Update Client", - "sha256": "8cd9d18fd66c29f88fb14bbae4dfefffb29f97c2bf89c097c6f6cf10e24125b0", - "type": "eql", - "version": 215 } }, "rule_name": "ImageLoad via Windows Update Auto Update Client", @@ -14623,7 +12273,7 @@ "ee39a9f7-5a79-4b0a-9815-d36b3cf28d3e": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 205, "rule_name": "Okta FastPass Phishing Detection", "sha256": "3a4e694a70d98f4075ad70e8cbc4c5820745c5ea03ab7103f18015a3cc68dc24", @@ -14646,7 +12296,7 @@ "ee5300a7-7e31-4a72-a258-250abb8b3aa1": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Unusual Print Spooler Child Process", "sha256": "5bc2e722e6fb7b61ce923befd4ce4b3a3d8fdacf1290dba7ec5ea911760c53e8", @@ -14678,32 +12328,12 @@ "version": 109 }, "ef04a476-07ec-48fc-8f3d-5e1742de76d3": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 207, - "rule_name": "BPF filter applied using TC", - "sha256": "446f19bb2ea5d80c1e18160601ba2b38ea8e81328974575d0c5369662901dfac", - "type": "eql", - "version": 109 - } - }, "rule_name": "BPF filter applied using TC", "sha256": "7ada39c6d2903cc362c1ded034828a6b929954050f650fa4d3d166b93f3ec78c", "type": "eql", "version": 211 }, "ef100a2e-ecd4-4f72-9d1e-2f779ff3c311": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Potential Linux Credential Dumping via Proc Filesystem", - "sha256": "f4ee5791bd579b8b6592dbca0af0c3eae7553a3f4d087397f873f3621c85d929", - "type": "eql", - "version": 8 - } - }, "rule_name": "Potential Linux Credential Dumping via Proc Filesystem", "sha256": "5270c503b5846ad6b35fd79100b8270b2b26c8f6968c90d112b8f672cfe55507", "type": "eql", @@ -14718,7 +12348,7 @@ "ef862985-3f13-4262-a686-5f357bbb9bc2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Whoami Process Activity", "sha256": "b020b8f8487dff043ed4f8e013dc6aee3af6d55ecfbd53cb47b9537f140e9427", @@ -14740,7 +12370,7 @@ "f036953a-4615-4707-a1ca-dc53bf69dcd5": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Unusual Child Processes of RunDLL32", "sha256": "23beebafef0bf295f6aaf5f99044dc15f8db23dfc7a6f68d46c1cb7a9416c43b", @@ -14762,7 +12392,7 @@ "f06414a6-f2a4-466d-8eba-10f85e8abf71": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Administrator Role Assigned to an Okta User", "sha256": "27066b5e84a225f2e379be5ede390f38f9c8187a9c43da195fe70a2e028f5ba6", @@ -14801,32 +12431,12 @@ "version": 107 }, "f16fca20-4d6c-43f9-aec1-20b6de3b0aeb": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Potential Remote Code Execution via Web Server", - "sha256": "c678c2e4d480d9276b6bc7967e6eb21e4cac673058c59d4b70b8be8b00bbf699", - "type": "eql", - "version": 8 - } - }, "rule_name": "Potential Remote Code Execution via Web Server", "sha256": "3e3a90a47139a3dc0d1c763351373920dee8e161a176b916ccca2e6be16dfed7", "type": "eql", "version": 109 }, "f18a474c-3632-427f-bcf5-363c994309ee": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 100, - "rule_name": "Process Capability Set via setcap Utility", - "sha256": "8104467acd6f82c9b69239d6bebc8750dcce6da3f4f4efbad4a57197063174ba", - "type": "eql", - "version": 2 - } - }, "rule_name": "Process Capability Set via setcap Utility", "sha256": "c7c1780ea2c3381899f8df2aca24d636619832fa7d0cc4a7637a1b519513a2b5", "type": "eql", @@ -14847,7 +12457,7 @@ "f243fe39-83a4-46f3-a3b6-707557a102df": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 104, "rule_name": "Service Path Modification", "sha256": "06058f2cf2dfe450db263b15625ad4168b83e231f35bec57b51213ffbd1be599", @@ -14867,16 +12477,6 @@ "version": 110 }, "f28e2be4-6eca-4349-bdd9-381573730c22": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 209, - "rule_name": "Potential OpenSSH Backdoor Logging Activity", - "sha256": "d34b536f30334984723914ab4d44bef45a48785b1ce33846ea6fa8169f40a9bf", - "type": "eql", - "version": 111 - } - }, "rule_name": "Potential OpenSSH Backdoor Logging Activity", "sha256": "6779913c9f6aa81caa57d89b94072b01b0638454d4faaa9433f37e902cd65b5a", "type": "eql", @@ -14890,7 +12490,6 @@ "version": 3 }, "f2c653b7-7daf-4774-86f2-34cdbd1fc528": { - "min_stack_version": "8.13", "rule_name": "AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session", "sha256": "42cba0422e9398684922e14a9f8bcb52726504673ccd9369a94911561994ab23", "type": "esql", @@ -14899,19 +12498,12 @@ "f2c7b914-eda3-40c2-96ac-d23ef91776ca": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "SIP Provider Modification", "sha256": "3171aedb786a6c4346ca2d6e875c736ea14d23e12331aeea3c994e5dca963238", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "SIP Provider Modification", - "sha256": "29662765828508b5d2ddf5905237089fde83513f4c34bd44c93f0e27849d77c3", - "type": "eql", - "version": 211 } }, "rule_name": "SIP Provider Modification", @@ -14922,19 +12514,12 @@ "f2f46686-6f3c-4724-bd7d-24e31c70f98f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "LSASS Memory Dump Creation", "sha256": "f8cbd6a379d828f24d80c53ac9f923bccfcf5f6db7532cf8567c55c09446dae2", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "LSASS Memory Dump Creation", - "sha256": "c0268c1e96cb8a7dfec0cb7f803ec42df015cf80a71719b1a544cc4285ed0087", - "type": "eql", - "version": 212 } }, "rule_name": "LSASS Memory Dump Creation", @@ -14963,7 +12548,7 @@ "f3475224-b179-4f78-8877-c2bd64c26b88": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "WMI Incoming Lateral Movement", "sha256": "bf322fd08b8f2bfd47228ee56470b9301a500aa181f75f9594d50ed79033e3a5", @@ -15016,19 +12601,12 @@ "f44fa4b6-524c-4e87-8d9e-a32599e4fb7c": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Persistence via Microsoft Office AddIns", "sha256": "d8fa297a02bd05755728ee6202070fef2ebc8f2f5ae3d46617d78034d80e24bd", "type": "eql", "version": 109 - }, - "8.13": { - "max_allowable_version": 307, - "rule_name": "Persistence via Microsoft Office AddIns", - "sha256": "111139bb2a9a56c179012f91b0e217c614e1527fc3eb2a4b713943763e5a7a40", - "type": "eql", - "version": 209 } }, "rule_name": "Persistence via Microsoft Office AddIns", @@ -15045,7 +12623,7 @@ "f494c678-3c33-43aa-b169-bb3d5198c41d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 212, "rule_name": "Sensitive Privilege SeEnableDelegationPrivilege assigned to a User", "sha256": "9c9490d04847aa87bb7ecf37a56631b96d3e56c1a3fb00b8c6b2fc5739161f46", @@ -15059,14 +12637,12 @@ "version": 215 }, "f4b857b3-faef-430d-b420-90be48647f00": { - "min_stack_version": "8.13", "rule_name": "OpenSSL Password Hash Generation", "sha256": "04b4c9ecf43e0acf3fa6b298371accc63a200e07eb118a4d5edc9430aaca263a", "type": "eql", "version": 2 }, "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c": { - "min_stack_version": "8.13", "rule_name": "AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request", "sha256": "67cfc341651734d5dc809fca49d66ce14a80f2ba8535da9515f18242adfca0cc", "type": "esql", @@ -15093,19 +12669,12 @@ "f545ff26-3c94-4fd0-bd33-3c7f95a3a0fc": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Windows Script Executing PowerShell", "sha256": "f655edd21d9ffc790dddeea99c917b3ff512004a2bce04fff2d18e285cb7554c", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Windows Script Executing PowerShell", - "sha256": "7d014986e6735e5f5b90c0790e404e69d4e5d64634f6935fb10a34ec72877e05", - "type": "eql", - "version": 212 } }, "rule_name": "Windows Script Executing PowerShell", @@ -15122,19 +12691,12 @@ "f580bf0a-2d23-43bb-b8e1-17548bb947ec": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 107, "rule_name": "Rare SMB Connection to the Internet", "sha256": "1a52a9efcabc5597110829afe735c6831cc9b2e64ed6169e8e81459e8669c83c", "type": "new_terms", "version": 9 - }, - "8.13": { - "max_allowable_version": 207, - "rule_name": "Rare SMB Connection to the Internet", - "sha256": "0002a051fa57648d20e54eaded6c44a1f3bf1c307e7e8ec68200ff562fd22790", - "type": "new_terms", - "version": 109 } }, "rule_name": "Rare SMB Connection to the Internet", @@ -15145,7 +12707,7 @@ "f5861570-e39a-4b8a-9259-abd39f84cb97": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "WRITEDAC Access on Active Directory Object", "sha256": "7985f5aefba2ea64d65352cb9a8eafeb6764e30498ccb6d629242be6c5b979ab", @@ -15161,7 +12723,7 @@ "f59668de-caa0-4b84-94c1-3a1549e1e798": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "WMIC Remote Command", "sha256": "03ff2581fa827afb289f1ed2f6e5aaa30032940c26bdf3b8d440b729539d3e53", @@ -15175,16 +12737,6 @@ "version": 108 }, "f5c005d3-4e17-48b0-9cd7-444d48857f97": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 105, - "rule_name": "Setcap setuid/setgid Capability Set", - "sha256": "3ae5e32591f980bca7b3064fb9a680b9329a75f4ddc4dc888391659a4c1f654f", - "type": "eql", - "version": 7 - } - }, "rule_name": "Setcap setuid/setgid Capability Set", "sha256": "e41e3069e64db02d6742f75d9126315cfeee13e18851f97d1260e4fd6b35d76f", "type": "eql", @@ -15193,7 +12745,7 @@ "f5d9d36d-7c30-4cdb-a856-9f653c13d4e0": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Suspicious Windows Process Cluster Spawned by a Parent Process", "sha256": "a3bc6cca188a55aa33021f1b9c7d396bdde78a3350f1c4fabb974a4fcffa5ca4", @@ -15221,19 +12773,12 @@ "f63c8e3c-d396-404f-b2ea-0379d3942d73": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Windows Firewall Disabled via PowerShell", "sha256": "b677759be5d31d2da13e1a1902fc4d9047723a793205cdaf229d6fe6c9ac5088", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Windows Firewall Disabled via PowerShell", - "sha256": "62eb84c5f2680cf2953c3a642bb4371ea70e676be5e9e9ac2dcf237f4040cb81", - "type": "eql", - "version": 211 } }, "rule_name": "Windows Firewall Disabled via PowerShell", @@ -15250,19 +12795,12 @@ "f675872f-6d85-40a3-b502-c0d2ef101e92": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Delete Volume USN Journal with Fsutil", "sha256": "4b55ce8144feb04c19f2449fa5a4c724ce26861e85a8ff9d63ba91fc24c90ae9", "type": "eql", "version": 111 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Delete Volume USN Journal with Fsutil", - "sha256": "37d393c66c6a0a664ed5d4ec5f5497345d8fdbec26f4247d4528d04510eaac3e", - "type": "eql", - "version": 211 } }, "rule_name": "Delete Volume USN Journal with Fsutil", @@ -15315,19 +12853,12 @@ "f7c4dc5a-a58d-491d-9f14-9b66507121c0": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Persistent Scripts in the Startup Directory", "sha256": "3bb11d5684b0514f8d1a5326d1645b8787ea37ae7731db6df5e7d94945f6ef1c", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Persistent Scripts in the Startup Directory", - "sha256": "4cbd3242743b94fc54ec1eff6658bdf2a9009dad93fccbc3354272cc5c10196e", - "type": "eql", - "version": 213 } }, "rule_name": "Persistent Scripts in the Startup Directory", @@ -15344,19 +12875,12 @@ "f81ee52c-297e-46d9-9205-07e66931df26": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "Microsoft Exchange Worker Spawning Suspicious Processes", "sha256": "e36c1fdb2b34568b5431017b6d35a86a116bc34c7b9af52fbfeaf4548233dac3", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "Microsoft Exchange Worker Spawning Suspicious Processes", - "sha256": "a577211254c57b0fba47713de661ab81bc197366995a8d14d939f8667dde3ffa", - "type": "eql", - "version": 210 } }, "rule_name": "Microsoft Exchange Worker Spawning Suspicious Processes", @@ -15379,19 +12903,12 @@ "f874315d-5188-4b4a-8521-d1c73093a7e4": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 211, "rule_name": "Modification of AmsiEnable Registry Key", "sha256": "ed1762609d805dc2007ca323d72bbe93b721d54a113d04206e0fda5abb3ce0fd", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 311, - "rule_name": "Modification of AmsiEnable Registry Key", - "sha256": "f2423851bfbeefbfcda2a745c74dc1370032a6f7cfe9efbc981454ee74130559", - "type": "eql", - "version": 212 } }, "rule_name": "Modification of AmsiEnable Registry Key", @@ -15409,7 +12926,7 @@ "f8822053-a5d2-46db-8c96-d460b12c36ac": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 103, "rule_name": "Potential Active Directory Replication Account Backdoor", "sha256": "29c2ae7b2d50ee5ef2f2bcf97f7765c9e3fd3285a0a90abc25a099698c75201d", @@ -15425,7 +12942,7 @@ "f909075d-afc7-42d7-b399-600b94352fd9": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Untrusted DLL Loaded by Azure AD Sync Service", "sha256": "e26f15abdf56aa1b61415ba7dc51da814455d36335a30451a9089c7e28074d99", @@ -15439,16 +12956,6 @@ "version": 103 }, "f94e898e-94f1-4545-8923-03e4b2866211": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of Personal Access Token (PAT) Use For a GitHub User", - "sha256": "3e68a069ea98921ba60e3b258f21b0a94dc7d42b38ee50c7332daad964e6b5d0", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of Personal Access Token (PAT) Use For a GitHub User", "sha256": "165212d6d0e75e131667eef40c52817e2d905ecd2fcb315d1a8d243d1f439737", "type": "new_terms", @@ -15469,19 +12976,12 @@ "f97504ac-1053-498f-aeaa-c6d01e76b379": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 101, "rule_name": "Browser Extension Install", "sha256": "13264d82b596b30f4a39bca88800139df7d59f7e5714ac3294aecb8adb693f2b", "type": "eql", "version": 3 - }, - "8.13": { - "max_allowable_version": 201, - "rule_name": "Browser Extension Install", - "sha256": "2813c84680c133570b552af8010cab5df5b2cf9ce045b7cb05716d286729bcdf", - "type": "eql", - "version": 103 } }, "rule_name": "Browser Extension Install", @@ -15492,7 +12992,7 @@ "f9790abf-bd0c-45f9-8b5f-d0b74015e029": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 109, "rule_name": "Privileged Account Brute Force", "sha256": "47b50b29f44c12811728607a941a9e0e41788b4bf9a46e739700c9b40261cd5f", @@ -15508,7 +13008,7 @@ "f994964f-6fce-4d75-8e79-e16ccc412588": { "min_stack_version": "8.15", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 307, "rule_name": "Suspicious Activity Reported by Okta User", "sha256": "fa7f7c30177462dd01a22cc1653006645eec2ec9550c0e05cf9b058786f7fe47", @@ -15531,19 +13031,12 @@ "fa01341d-6662-426b-9d0c-6d81e33c8a9d": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Remote File Copy to a Hidden Share", "sha256": "51e2f2e64af9db1e8aff099e445cf685c9af9929b2a4dc5c5e041d2cd8d6caa9", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Remote File Copy to a Hidden Share", - "sha256": "3d4b0d2242c7cd5acdcd0a38384b7f696c1f8811eee13cbbad561ce3c97eb99d", - "type": "eql", - "version": 213 } }, "rule_name": "Remote File Copy to a Hidden Share", @@ -15566,19 +13059,12 @@ "fa488440-04cc-41d7-9279-539387bf2a17": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 108, "rule_name": "Suspicious Antimalware Scan Interface DLL", "sha256": "e416bd900c26017a9a2e60990ee7ae09ced3df13618bbbc45b29fb2340de74d1", "type": "eql", "version": 11 - }, - "8.13": { - "max_allowable_version": 312, - "rule_name": "Suspicious Antimalware Scan Interface DLL", - "sha256": "34eeb28ee7412555964397a4969d1d55098b05a4107dd4330ea8ac5dd242d54e", - "type": "eql", - "version": 214 } }, "rule_name": "Suspicious Antimalware Scan Interface DLL", @@ -15587,16 +13073,6 @@ "version": 315 }, "fac52c69-2646-4e79-89c0-fd7653461010": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 106, - "rule_name": "Potential Disabling of AppArmor", - "sha256": "dcc5486dac299e23f474eb39e2b40231213ec061f4460cc66cbd25bc8ea1b927", - "type": "eql", - "version": 8 - } - }, "rule_name": "Potential Disabling of AppArmor", "sha256": "a7096f2d6c73fe27e1f80b1da2c040a60eb8eb8d159f2eb8af2f6bbb2cb3dcc2", "type": "eql", @@ -15611,7 +13087,7 @@ "fb02b8d3-71ee-4af1-bacd-215d23f17efa": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "Network Connection via Registration Utility", "sha256": "b4eed2ddeb40f2bbedc702c4789e5748c0f303fb263208a2bdcd2974c12346b5", @@ -15625,23 +13101,12 @@ "version": 209 }, "fb0afac5-bbd6-49b0-b4f8-44e5381e1587": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "High Number of Cloned GitHub Repos From PAT", - "sha256": "1b149111089ed10df74c8975a4801b321f429cbc00bddf77eebd2f154d5355e0", - "type": "threshold", - "version": 105 - } - }, "rule_name": "High Number of Cloned GitHub Repos From PAT", "sha256": "babeac41d262653f7ef7c8bddf78a7573fb7894ae7b8c2c9b3f48fc07ef6452c", "type": "threshold", "version": 205 }, "fb16f9ef-cb03-4234-adc2-44641f3b71ee": { - "min_stack_version": "8.13", "rule_name": "Azure OpenAI Insecure Output Handling", "sha256": "5c688822ac431693ee2b4997dcf5f420f610ce923f4235bde962d0b0b5df90d7", "type": "esql", @@ -15668,19 +13133,12 @@ "fc7c0fa4-8f03-4b3e-8336-c5feab0be022": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 208, "rule_name": "UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer", "sha256": "59543020be10655d8e81766d6a80fb95792cda6820556f739905cb54943ddbce", "type": "eql", "version": 110 - }, - "8.13": { - "max_allowable_version": 308, - "rule_name": "UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer", - "sha256": "80e05f76dd4e8c2e94bdbd3924f85a5877d9ff5a47c410d308b96f7a1d390525", - "type": "eql", - "version": 210 } }, "rule_name": "UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer", @@ -15689,16 +13147,6 @@ "version": 310 }, "fc909baa-fb34-4c46-9691-be276ef4234c": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "First Occurrence of IP Address For GitHub Personal Access Token (PAT)", - "sha256": "b8f1378c21d3e35e4db3d9cde9f1583494304e86dc8dbb9a39468206794f91bf", - "type": "new_terms", - "version": 104 - } - }, "rule_name": "First Occurrence of IP Address For GitHub Personal Access Token (PAT)", "sha256": "88ee00977794183d05cd85d41e19dab9c8d4b4a87b094f87b878f06f3dc6f010", "type": "new_terms", @@ -15711,16 +13159,6 @@ "version": 4 }, "fd01b949-81be-46d5-bcf8-284395d5f56d": { - "min_stack_version": "8.13", - "previous": { - "8.12": { - "max_allowable_version": 203, - "rule_name": "GitHub App Deleted", - "sha256": "c0689f3c0e7636572f0800557c0480309dbcf71e0107dc51b0ed362728a0c927", - "type": "eql", - "version": 105 - } - }, "rule_name": "GitHub App Deleted", "sha256": "77d5e70dceb83e72c91dec0a125b56e67e4f66b20ca31374060260c91887c03d", "type": "eql", @@ -15741,19 +13179,12 @@ "fd4a992d-6130-4802-9ff8-829b89ae801f": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 210, "rule_name": "Potential Application Shimming via Sdbinst", "sha256": "1ddee753094159e636e994613c0a04ccd3e560927f3709a93fe7d8eff775b79e", "type": "eql", "version": 113 - }, - "8.13": { - "max_allowable_version": 310, - "rule_name": "Potential Application Shimming via Sdbinst", - "sha256": "09749f912d0f05abcfbd2cfc5517db716e29e39627f25bcfe727de8cf2455d62", - "type": "eql", - "version": 213 } }, "rule_name": "Potential Application Shimming via Sdbinst", @@ -15764,19 +13195,12 @@ "fd70c98a-c410-42dc-a2e3-761c71848acf": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 209, "rule_name": "Suspicious CertUtil Commands", "sha256": "379008bb580fbcb724bd44937e0f2111250767511073c4d6fe5bf58915e22fa7", "type": "eql", "version": 112 - }, - "8.13": { - "max_allowable_version": 309, - "rule_name": "Suspicious CertUtil Commands", - "sha256": "0d6fb82afcda861a6b2d317f524c33af9bdc4bef870304c2dbb53d186692501c", - "type": "eql", - "version": 212 } }, "rule_name": "Suspicious CertUtil Commands", @@ -15787,19 +13211,12 @@ "fd7a6052-58fa-4397-93c3-4795249ccfa2": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 317, "rule_name": "Svchost spawning Cmd", "sha256": "a61a30ecc9514cb3b5eb1f9d31f97e104e4a51cffd65cbe67fad341835938bfe", "type": "new_terms", "version": 220 - }, - "8.13": { - "max_allowable_version": 417, - "rule_name": "Svchost spawning Cmd", - "sha256": "8b25fa755b63d74097491bf3d52c9edec8d0b5234cfdd6cb62e4f5ac32198bc4", - "type": "new_terms", - "version": 320 } }, "rule_name": "Svchost spawning Cmd", @@ -15822,7 +13239,7 @@ "fddff193-48a3-484d-8d35-90bb3d323a56": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "PowerShell Kerberos Ticket Dump", "sha256": "87b8915f4df4e07283d519a5459b89600a2e9018c07136f10a454968ecec7522", @@ -15838,7 +13255,7 @@ "fe25d5bc-01fa-494a-95ff-535c29cc4c96": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "PowerShell Script with Password Policy Discovery Capabilities", "sha256": "549dac6c269368c82ba41a9b89a211dab398c0448459487fd6c8c7d2b19c4cf9", @@ -15854,19 +13271,12 @@ "fe794edd-487f-4a90-b285-3ee54f2af2d3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 213, "rule_name": "Microsoft Windows Defender Tampering", "sha256": "1f2195434989e3990924d92909511eadf813d2f24724f6cb94b7aab7d20bfada", "type": "eql", "version": 114 - }, - "8.13": { - "max_allowable_version": 313, - "rule_name": "Microsoft Windows Defender Tampering", - "sha256": "7574ee875c1c9a825dfefa55b0b3b243f5cc25a3f4c7b2a4db8e22dd0cd9b2c5", - "type": "eql", - "version": 214 } }, "rule_name": "Microsoft Windows Defender Tampering", @@ -15895,19 +13305,12 @@ "feeed87c-5e95-4339-aef1-47fd79bcfbe3": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 207, "rule_name": "MS Office Macro Security Registry Modifications", "sha256": "d89feb920d5a0d3e030a96c263df8d04776b80b8b6ba19c208082ea006e19329", "type": "eql", "version": 108 - }, - "8.13": { - "max_allowable_version": 307, - "rule_name": "MS Office Macro Security Registry Modifications", - "sha256": "02f53b9ca7444dd33ade4085a8403f9f14298ad57e5cad93a2ba6bb6c64fd758", - "type": "eql", - "version": 208 } }, "rule_name": "MS Office Macro Security Registry Modifications", @@ -15960,19 +13363,12 @@ "ff6cf8b9-b76c-4cc1-ac1b-4935164d1029": { "min_stack_version": "8.14", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 100, "rule_name": "Alternate Data Stream Creation/Execution at Volume Root Directory", "sha256": "142aa8456d0c3151257b8d40bb29b00d7880561940ea1366b6c850725a7fa90b", "type": "eql", "version": 2 - }, - "8.13": { - "max_allowable_version": 200, - "rule_name": "Alternate Data Stream Creation/Execution at Volume Root Directory", - "sha256": "593b01d8d7d60109ab9ad569f65be57c3c9e8efb4590d58f871e61d7ba6a8cfa", - "type": "eql", - "version": 102 } }, "rule_name": "Alternate Data Stream Creation/Execution at Volume Root Directory", @@ -15989,7 +13385,7 @@ "ff9bc8b9-f03b-4283-be58-ee0a16f5a11b": { "min_stack_version": "8.16", "previous": { - "8.12": { + "8.13": { "max_allowable_version": 106, "rule_name": "Potential Sudo Token Manipulation via Process Injection", "sha256": "b3468a2a0f4b606f04c16270c18b6b7d2a77491078aa852a13f671f64b328173", diff --git a/detection_rules/schemas/__init__.py b/detection_rules/schemas/__init__.py index 2b988cce600..d7b8cdf64b2 100644 --- a/detection_rules/schemas/__init__.py +++ b/detection_rules/schemas/__init__.py @@ -303,6 +303,12 @@ def migrate_to_8_17(version: Version, api_contents: dict) -> dict: return strip_additional_properties(version, api_contents) +@migrate("8.18") +def migrate_to_8_18(version: Version, api_contents: dict) -> dict: + """Default migration for 8.18.""" + return strip_additional_properties(version, api_contents) + + def downgrade(api_contents: dict, target_version: str, current_version: Optional[str] = None) -> dict: """Downgrade a rule to a target stack version.""" from ..packaging import current_stack_version diff --git a/pyproject.toml b/pyproject.toml index 70d18547558..f8138a1b978 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "detection_rules" -version = "0.4.24" +version = "0.4.25" 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/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml index 74210517ab1..f7ca76e64fa 100644 --- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml +++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml @@ -1,44 +1,18 @@ [metadata] creation_date = "2024/05/08" maturity = "production" -updated_date = "2025/01/15" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this -to prioritize triage and response, as this can potentially indicate a widespread malware infection. +This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to +prioritize triage and response, as this can potentially indicate a widespread malware infection. """ from = "now-9m" language = "esql" license = "Elastic License v2" name = "Potential Widespread Malware Infection Across Multiple Hosts" -references = [ - "https://github.com/elastic/protections-artifacts/tree/main/yara/rules" -] -risk_score = 73 -rule_id = "28371aa1-14ed-46cf-ab5b-2fc7d1942278" -severity = "high" -tags = [ - "Domain: Endpoint", - "Data Source: Elastic Defend", - "Use Case: Threat Detection", - "Tactic: Execution", - "Rule Type: Higher-Order Rule", - "Resources: Investigation Guide" -] -timestamp_override = "event.ingested" -type = "esql" - -query = ''' -from logs-endpoint.alerts-* -| where event.code in ("malicious_file", "memory_signature", "shellcode_thread") and rule.name is not null -| keep host.id, rule.name, event.code -| stats hosts = count_distinct(host.id) by rule.name, event.code -| where hosts >= 3 -''' note = """## Triage and analysis > **Disclaimer**: @@ -74,6 +48,28 @@ Endpoint security technologies monitor and analyze activities on devices to dete - Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning. - Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds. - Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response.""" +references = ["https://github.com/elastic/protections-artifacts/tree/main/yara/rules"] +risk_score = 73 +rule_id = "28371aa1-14ed-46cf-ab5b-2fc7d1942278" +severity = "high" +tags = [ + "Domain: Endpoint", + "Data Source: Elastic Defend", + "Use Case: Threat Detection", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-endpoint.alerts-* +| where event.code in ("malicious_file", "memory_signature", "shellcode_thread") and rule.name is not null +| keep host.id, rule.name, event.code +| stats hosts = count_distinct(host.id) by rule.name, event.code +| where hosts >= 3 +''' [[rule.threat]] @@ -93,3 +89,4 @@ reference = "https://attack.mitre.org/techniques/T1204/002/" id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml index 7635518faaa..f4588bc7f12 100644 --- a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml +++ b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["aws"] maturity = "production" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully" -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -134,12 +132,6 @@ from logs-aws.cloudtrail* | sort unique_api_count desc ''' -[rule.investigation_fields] -field_names = [ - "time_window", - "aws.cloudtrail.user_identity.arn", - "unique_api_count" -] [[rule.threat]] framework = "MITRE ATT&CK" @@ -154,3 +146,6 @@ id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" +[rule.investigation_fields] +field_names = ["time_window", "aws.cloudtrail.user_identity.arn", "unique_api_count"] + diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml index dc0a3ffc95b..54a349d5a62 100644 --- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml +++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml @@ -2,16 +2,14 @@ creation_date = "2024/04/16" integration = ["aws"] maturity = "production" -min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0" -min_stack_version = "8.13.0" -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, -which can then be shared with an external AWS account or made public. Adversaries may attempt this in order to copy the -snapshot into an environment they control, to access the data. +Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied +into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in +order to copy the snapshot into an environment they control, to access the data. """ false_positives = [ """ @@ -23,7 +21,6 @@ language = "esql" license = "Elastic License v2" name = "AWS EC2 EBS Snapshot Shared or Made Public" note = """ - ## Triage and analysis ### Investigating AWS EC2 EBS Snapshot Shared or Made Public @@ -64,7 +61,7 @@ references = [ "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html", "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html", "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump", - "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/" + "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/", ] risk_score = 21 rule_id = "4182e486-fc61-11ee-a05d-f661ea17fbce" diff --git a/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml b/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml index 37d950ef7f6..45a051a8d72 100644 --- a/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml +++ b/rules/integrations/aws/impact_aws_s3_bucket_enumeration_or_brute_force.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2024/05/01" maturity = "production" -updated_date = "2024/11/07" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -69,7 +67,7 @@ Attackers may attempt to enumerate names until a valid bucket is discovered and """ references = [ "https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1", - "https://docs.aws.amazon.com/cli/latest/reference/s3api/" + "https://docs.aws.amazon.com/cli/latest/reference/s3api/", ] risk_score = 21 rule_id = "5f0234fd-7f21-42af-8391-511d5fd11d5c" @@ -81,7 +79,7 @@ tags = [ "Data Source: AWS S3", "Resources: Investigation Guide", "Use Case: Log Auditing", - "Tactic: Impact" + "Tactic: Impact", ] timestamp_override = "event.ingested" type = "esql" @@ -97,51 +95,44 @@ from logs-aws.cloudtrail* | where failed_requests > 40 ''' -[rule.investigation_fields] -field_names = [ - "source.address", - "tls.client.server_name", - "cloud.account.id", - "failed_requests" -] [[rule.threat]] framework = "MITRE ATT&CK" - - [rule.threat.tactic] - id = "TA0040" - name = "Impact" - reference = "https://attack.mitre.org/tactics/TA0040/" - - [[rule.threat.technique]] - id = "T1657" - name = "Financial Theft" - reference = "https://attack.mitre.org/techniques/T1657/" +[[rule.threat.technique]] +id = "T1657" +name = "Financial Theft" +reference = "https://attack.mitre.org/techniques/T1657/" +[rule.threat.tactic] +id = "TA0040" +name = "Impact" +reference = "https://attack.mitre.org/tactics/TA0040/" [[rule.threat]] framework = "MITRE ATT&CK" - - [rule.threat.tactic] - id = "TA0007" - name = "Discovery" - reference = "https://attack.mitre.org/tactics/TA0007/" - - [[rule.threat.technique]] - id = "T1580" - name = "Cloud Infrastructure Discovery" - reference = "https://attack.mitre.org/techniques/T1580/" +[[rule.threat.technique]] +id = "T1580" +name = "Cloud Infrastructure Discovery" +reference = "https://attack.mitre.org/techniques/T1580/" +[rule.threat.tactic] +id = "TA0007" +name = "Discovery" +reference = "https://attack.mitre.org/tactics/TA0007/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1530" +name = "Data from Cloud Storage" +reference = "https://attack.mitre.org/techniques/T1530/" + - [rule.threat.tactic] - id = "TA0009" - name = "Collection" - reference = "https://attack.mitre.org/tactics/TA0009/" +[rule.threat.tactic] +id = "TA0009" +name = "Collection" +reference = "https://attack.mitre.org/tactics/TA0009/" + +[rule.investigation_fields] +field_names = ["source.address", "tls.client.server_name", "cloud.account.id", "failed_requests"] - [[rule.threat.technique]] - id = "T1530" - name = "Data from Cloud Storage" - reference = "https://attack.mitre.org/techniques/T1530/" diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml index 7ccae3829bd..c1ceaf67808 100644 --- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml +++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml @@ -2,16 +2,14 @@ creation_date = "2024/04/17" integration = ["aws"] maturity = "production" -min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0" -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the `PutObject` S3 API call -with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to -a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. +with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured +S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. """ false_positives = [ """ @@ -24,7 +22,6 @@ language = "esql" license = "Elastic License v2" name = "Potential AWS S3 Bucket Ransomware Note Uploaded" note = """ - ## Triage and analysis ### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml index 00f5310dde8..ba1f3bf40a3 100644 --- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml +++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml @@ -2,18 +2,20 @@ creation_date = "2024/07/02" integration = ["aws"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/02/03" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data. +Identifies `CopyObject` events within an S3 bucket using an AWS KMS key from an external account for encryption. +Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS +key to deny their victims access to their own data. """ false_positives = [ """ - Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before taking action. + Administrators within an AWS Organization structure may legitimately encrypt bucket objects with a key from an + account different from the target bucket. Ensure that this behavior is not part of a legitimate operation before + taking action. """, ] from = "now-9m" @@ -21,7 +23,6 @@ language = "esql" license = "Elastic License v2" name = "AWS S3 Object Encryption Using External KMS Key" note = """ - ## Triage and analysis ### Investigating AWS S3 Object Encryption Using External KMS Key @@ -101,6 +102,7 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index | keep @timestamp, aws.cloudtrail.user_identity.arn, cloud.account.id, event.action, target.bucketName, key.account.id, keyId, target.objectName ''' + [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml index 40b20fe314e..946da73f024 100644 --- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml +++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml @@ -1,10 +1,8 @@ [metadata] creation_date = "2024/08/19" -integration = ['aws'] +integration = ["aws"] maturity = "production" -updated_date = "2025/01/15" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,35 +16,6 @@ from = "now-9m" language = "esql" license = "Elastic License v2" name = "AWS Signin Single Factor Console Login with Federated User" -references = [ - "https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/" -] -risk_score = 47 -rule_id = "1f45720e-5ea8-11ef-90d2-f661ea17fbce" -severity = "medium" -tags = [ - "Domain: Cloud", - "Data Source: Amazon Web Services", - "Data Source: AWS", - "Data Source: AWS Sign-In", - "Use Case: Threat Detection", - "Tactic: Initial Access", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "esql" - -query = ''' -from logs-aws.cloudtrail-* metadata _id, _version, _index -| where - event.provider == "signin.amazonaws.com" - and event.action == "GetSigninToken" - and aws.cloudtrail.event_type == "AwsConsoleSignIn" - and aws.cloudtrail.user_identity.type == "FederatedUser" -| dissect aws.cloudtrail.additional_eventdata "{%{?mobile_version_key}=%{mobile_version}, %{?mfa_used_key}=%{mfa_used}}" -| where mfa_used == "No" -| keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type -''' note = """## Triage and analysis > **Disclaimer**: @@ -82,6 +51,34 @@ Federated users in AWS are granted temporary credentials to access resources, of - Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege. - Escalate the incident to the incident response team if any malicious activities are detected, and initiate a full security investigation to assess the impact and scope of the breach. - Monitor AWS CloudTrail and other relevant logs closely for any further unauthorized access attempts or anomalies related to federated user accounts.""" +references = ["https://hackingthe.cloud/aws/post_exploitation/create_a_console_session_from_iam_credentials/"] +risk_score = 47 +rule_id = "1f45720e-5ea8-11ef-90d2-f661ea17fbce" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: Amazon Web Services", + "Data Source: AWS", + "Data Source: AWS Sign-In", + "Use Case: Threat Detection", + "Tactic: Initial Access", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "esql" + +query = ''' +from logs-aws.cloudtrail-* metadata _id, _version, _index +| where + event.provider == "signin.amazonaws.com" + and event.action == "GetSigninToken" + and aws.cloudtrail.event_type == "AwsConsoleSignIn" + and aws.cloudtrail.user_identity.type == "FederatedUser" +| dissect aws.cloudtrail.additional_eventdata "{%{?mobile_version_key}=%{mobile_version}, %{?mfa_used_key}=%{mfa_used}}" +| where mfa_used == "No" +| keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type +''' + [[rule.threat]] framework = "MITRE ATT&CK" @@ -95,7 +92,9 @@ name = "Cloud Accounts" reference = "https://attack.mitre.org/techniques/T1078/004/" + [rule.threat.tactic] id = "TA0001" name = "Initial Access" reference = "https://attack.mitre.org/tactics/TA0001/" + diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml index bb9ebe52ce5..a7d7733a8b6 100644 --- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml +++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml @@ -2,9 +2,7 @@ creation_date = "2024/12/02" integration = ["aws"] maturity = "production" -min_stack_comments = "ES|QL available in technical preview." -min_stack_version = "8.13.0" -updated_date = "2025/01/10" +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml b/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml index 765abe1d9ee..9743dfd868f 100644 --- a/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml +++ b/rules/integrations/aws/persistence_iam_user_created_access_keys_for_another_user.toml @@ -2,21 +2,19 @@ creation_date = "2024/06/13" integration = ["aws"] maturity = "production" -updated_date = "2025/02/03" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by -creating a new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation -to create new programmatic access keys for another IAM user. +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a +new set of credentials for an existing user. This rule looks for use of the IAM `CreateAccessKey` API operation to +create new programmatic access keys for another IAM user. """ false_positives = [ """ - While this can be normal behavior, it should be investigated to ensure validity. - Verify whether the user identity should be using the IAM `CreateAccessKey` for the targeted user. + While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity + should be using the IAM `CreateAccessKey` for the targeted user. """, ] from = "now-6m" @@ -120,23 +118,6 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index aws.cloudtrail.user_identity.type ''' -[rule.investigation_fields] -field_names = [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "aws.cloudtrail.user_identity.type", - "user_agent.original", - "user.target.name", - "event.action", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters", - "aws.cloudtrail.response_elements", -] - [[rule.threat]] framework = "MITRE ATT&CK" @@ -149,11 +130,12 @@ id = "T1098.001" name = "Additional Cloud Credentials" reference = "https://attack.mitre.org/techniques/T1098/001/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] @@ -165,8 +147,27 @@ id = "T1098.001" name = "Additional Cloud Credentials" reference = "https://attack.mitre.org/techniques/T1098/001/" + + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.address", + "aws.cloudtrail.user_identity.arn", + "aws.cloudtrail.user_identity.type", + "user_agent.original", + "user.target.name", + "event.action", + "event.outcome", + "cloud.region", + "event.provider", + "aws.cloudtrail.request_parameters", + "aws.cloudtrail.response_elements", +] + diff --git a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml index 360cee3a135..2af357fbb81 100644 --- a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml +++ b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_group.toml @@ -2,23 +2,21 @@ creation_date = "2024/05/31" integration = ["aws"] maturity = "production" -updated_date = "2025/02/03" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13." -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by -attaching additional permissions to user groups the compromised user account belongs to. This rule looks for use of -the IAM `AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy -to an existing IAM user group. +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching +additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM +`AttachGroupPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an +existing IAM user group. """ false_positives = [ """ - While this can be normal behavior, it should be investigated to ensure validity. - Verify whether the user identity should be using the IAM `AttachGroupPolicy` API operation - to attach the `AdministratorAccess` policy to the user group. + While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity + should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user + group. """, ] from = "now-6m" @@ -119,11 +117,12 @@ id = "T1098.003" name = "Additional Cloud Roles" reference = "https://attack.mitre.org/techniques/T1098/003/" + + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" - [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] @@ -135,6 +134,8 @@ id = "T1098.003" name = "Additional Cloud Roles" reference = "https://attack.mitre.org/techniques/T1098/003/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" diff --git a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml index 81f228df112..3c8939f17d1 100644 --- a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml +++ b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_role.toml @@ -2,22 +2,20 @@ creation_date = "2024/05/31" integration = ["aws"] maturity = "production" -updated_date = "2025/02/03" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13." -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by -attaching additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation -to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role. +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching +additional permissions to compromised IAM roles. This rule looks for use of the IAM `AttachRolePolicy` API operation to +attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM role. """ false_positives = [ """ - While this can be normal behavior, it should be investigated to ensure validity. - Verify whether the user identity should be using the IAM `AttachRolePolicy` API operation - to attach the `AdministratorAccess` policy to the target role. + While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity + should be using the IAM `AttachRolePolicy` API operation to attach the `AdministratorAccess` policy to the target + role. """, ] from = "now-6m" @@ -118,11 +116,12 @@ id = "T1098.003" name = "Additional Cloud Roles" reference = "https://attack.mitre.org/techniques/T1098/003/" + + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" - [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] @@ -134,6 +133,8 @@ id = "T1098.003" name = "Additional Cloud Roles" reference = "https://attack.mitre.org/techniques/T1098/003/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" diff --git a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml index 32cc9331aca..3f6e64b95b6 100644 --- a/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml +++ b/rules/integrations/aws/privilege_escalation_iam_administratoraccess_policy_attached_to_user.toml @@ -2,22 +2,20 @@ creation_date = "2024/05/30" integration = ["aws"] maturity = "production" -updated_date = "2025/02/03" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13." -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by -attaching additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation +An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching +additional permissions to compromised user accounts. This rule looks for use of the IAM `AttachUserPolicy` API operation to attach the highly permissive `AdministratorAccess` AWS managed policy to an existing IAM user. """ false_positives = [ """ - While this can be normal behavior, it should be investigated to ensure validity. - Verify whether the user identity should be using the IAM `AttachUserPolicy` API operation - to attach the `AdministratorAccess` policy to the target user. + While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity + should be using the IAM `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target + user. """, ] from = "now-6m" @@ -119,22 +117,6 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index source.address ''' -[rule.investigation_fields] -field_names = [ - "@timestamp", - "user.name", - "source.address", - "aws.cloudtrail.user_identity.arn", - "user_agent.original", - "target.userName", - "event.action", - "policyName", - "event.outcome", - "cloud.region", - "event.provider", - "aws.cloudtrail.request_parameters" -] - [[rule.threat]] framework = "MITRE ATT&CK" @@ -147,11 +129,12 @@ id = "T1098.003" name = "Additional Cloud Roles" reference = "https://attack.mitre.org/techniques/T1098/003/" + + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" - [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] @@ -163,8 +146,26 @@ id = "T1098.003" name = "Additional Cloud Roles" reference = "https://attack.mitre.org/techniques/T1098/003/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" +[rule.investigation_fields] +field_names = [ + "@timestamp", + "user.name", + "source.address", + "aws.cloudtrail.user_identity.arn", + "user_agent.original", + "target.userName", + "event.action", + "policyName", + "event.outcome", + "cloud.region", + "event.provider", + "aws.cloudtrail.request_parameters", +] + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml b/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml index 97d37e0f96e..ea726f44005 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_execution_without_guardrails.toml @@ -1,31 +1,24 @@ [metadata] creation_date = "2024/11/25" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple -consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration -in order to access sensitive information, or possibly exploit a vulnerability in the system. +Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same +account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass +security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive +information, or possibly exploit a vulnerability in the system. """ -false_positives = ["Users testing new model deployments or updated compliance policies without Amazon Bedrock guardrails."] +false_positives = [ + "Users testing new model deployments or updated compliance policies without Amazon Bedrock guardrails.", +] from = "now-60m" interval = "10m" language = "esql" license = "Elastic License v2" name = "AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 47 -rule_id = "f2c653b7-7daf-4774-86f2-34cdbd1fc528" note = """## Triage and analysis ### Investigating AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session @@ -58,6 +51,14 @@ Guardrails help manage risks associated with AI usage and ensure the output alig - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "f2c653b7-7daf-4774-86f2-34cdbd1fc528" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -87,3 +88,4 @@ from logs-aws_bedrock.invocation-* | where model_invocation_without_guardrails > 5 | sort model_invocation_without_guardrails desc ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml index e740725fd7a..11dcb4124e3 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_by_single_user.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2024/05/02" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,14 +16,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 47 -rule_id = "0cd2f3e6-41da-40e6-b28b-466f688f00a6" note = """## Triage and analysis ### Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session @@ -62,6 +52,14 @@ and they can establish thresholds for harmful content categories, including hate - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "0cd2f3e6-41da-40e6-b28b-466f688f00a6" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -89,3 +87,4 @@ from logs-aws_bedrock.invocation-* | where violations > 1 | sort violations desc ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml index 76b8d2869cb..9d28ad526c5 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_guardrails_multiple_violations_in_single_request.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2024/05/02" maturity = "production" -updated_date = "2027/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,14 +16,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 21 -rule_id = "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c" note = """## Triage and analysis ### Investigating AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request @@ -62,6 +52,14 @@ and they can establish thresholds for harmful content categories, including hate - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 21 +rule_id = "f4c2515a-18bb-47ce-a768-1dc4e7b0fe6c" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -90,3 +88,4 @@ from logs-aws_bedrock.invocation-* | stats total_unique_request_violations = count(*) by policy_violations, user.id, gen_ai.request.model.id, cloud.account.id | sort total_unique_request_violations desc ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml index 4d4d1e69729..c3cfe44e0e3 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_high_confidence_misconduct_blocks_detected.toml @@ -1,15 +1,14 @@ [metadata] creation_date = "2024/05/05" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes such as 'MISCONDUCT', -'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts to probe the model's ethical boundaries. +Detects repeated high-confidence 'BLOCKED' actions coupled with specific 'Content Filter' policy violation having codes +such as 'MISCONDUCT', 'HATE', 'SEXUAL', INSULTS', 'PROMPT_ATTACK', 'VIOLENCE' indicating persistent misuse or attempts +to probe the model's ethical boundaries. """ false_positives = ["New model deployments.", "Testing updates to compliance policies."] from = "now-60m" @@ -17,14 +16,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Unusual High Confidence Content Filter Blocks Detected" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 47 -rule_id = "4f855297-c8e0-4097-9d97-d653f7e471c4" note = """## Triage and analysis ### Investigating Unusual High Confidence Content Filter Blocks Detected @@ -60,6 +51,14 @@ to prevent the model from generating content on specific, undesired subjects, an - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "4f855297-c8e0-4097-9d97-d653f7e471c4" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -93,3 +92,4 @@ from logs-aws_bedrock.invocation-* | WHERE violation_count > 5 | SORT violation_count DESC ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml b/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml index 16f8a74bde9..e2d5e0deda7 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_high_resource_consumption_detection.toml @@ -1,16 +1,15 @@ [metadata] creation_date = "2024/05/04" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high input token counts, submit numerous requests, and receive -large responses. This behavior could indicate an attempt to overload the system or extract an unusually large amount of data, possibly revealing sensitive information or -causing service disruptions. +Detects potential resource exhaustion or data breach attempts by monitoring for users who consistently generate high +input token counts, submit numerous requests, and receive large responses. This behavior could indicate an attempt to +overload the system or extract an unusually large amount of data, possibly revealing sensitive information or causing +service disruptions. """ false_positives = ["Authorized heavy usage of the system that is business justified and monitored."] from = "now-60m" @@ -18,13 +17,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Potential Abuse of Resources by High Token Count and Large Response Sizes" -references = [ - "https://atlas.mitre.org/techniques/AML.T0051", - "https://owasp.org/www-project-top-10-for-large-language-model-applications/", - "https://www.elastic.co/security-labs/elastic-advances-llm-security", -] -risk_score = 47 -rule_id = "b1773d05-f349-45fb-9850-287b8f92f02d" note = """## Triage and analysis ### Investigating Potential Abuse of Resources by High Token Count and Large Response Sizes @@ -59,6 +51,13 @@ Bedrock offers a variety of pretrained models from Amazon (such as the Titan ser - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://atlas.mitre.org/techniques/AML.T0051", + "https://owasp.org/www-project-top-10-for-large-language-model-applications/", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "b1773d05-f349-45fb-9850-287b8f92f02d" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -74,7 +73,7 @@ tags = [ "Use Case: Potential Overload", "Use Case: Resource Exhaustion", "Mitre Atlas: LLM04", - "Resources: Investigation Guide" + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "esql" @@ -92,3 +91,4 @@ from logs-aws_bedrock.invocation-* | where risk_factor > 10 | sort risk_factor desc ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml index 56da20720ea..631b76a1e44 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_attempts_to_use_denied_models_by_user.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2024/05/02" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,14 +16,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0015", - "https://atlas.mitre.org/techniques/AML.T0034", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 73 -rule_id = "17261da3-a6d0-463c-aac8-ea1718afcd20" note = """## Triage and analysis ### Investigating AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User @@ -58,6 +48,14 @@ Bedrock offers a variety of pretrained models from Amazon (such as the Titan ser - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0015", + "https://atlas.mitre.org/techniques/AML.T0034", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 73 +rule_id = "17261da3-a6d0-463c-aac8-ea1718afcd20" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -86,10 +84,8 @@ from logs-aws_bedrock.invocation-* | sort total_denials desc ''' + + [rule.investigation_fields] -field_names = [ - "user.id", - "cloud.account.id", - "gen_ai.request.model.id", - "total_denials" -] +field_names = ["user.id", "cloud.account.id", "gen_ai.request.model.id", "total_denials"] + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml index a2d25204e98..8d521be1e61 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_sensitive_information_policy_blocks_detected.toml @@ -1,15 +1,13 @@ [metadata] creation_date = "2024/11/20" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as 'sensitive_information_policy', -indicating persistent misuse or attempts to probe the model's denied topics. +Detects repeated compliance violation 'BLOCKED' actions coupled with specific policy name such as +'sensitive_information_policy', indicating persistent misuse or attempts to probe the model's denied topics. """ false_positives = ["New model deployments.", "Testing updates to compliance policies."] from = "now-60m" @@ -17,14 +15,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Unusual High Denied Sensitive Information Policy Blocks Detected" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 47 -rule_id = "0e1af929-42ed-4262-a846-55a7c54e7c84" note = """## Triage and analysis ### Investigating Unusual High Denied Sensitive Information Policy Blocks Detected @@ -60,6 +50,14 @@ and they can establish thresholds for harmful content categories. - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "0e1af929-42ed-4262-a846-55a7c54e7c84" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -88,3 +86,4 @@ from logs-aws_bedrock.invocation-* | where sensitive_information_block > 5 | sort sensitive_information_block desc ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml index 362f78738d8..e5674aaf888 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_topic_policy_blocks_detected.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2024/11/20" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,14 +15,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Unusual High Denied Topic Blocks Detected" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 47 -rule_id = "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73" note = """## Triage and analysis ### Investigating Unusual High Denied Topic Blocks Detected @@ -60,6 +50,14 @@ and they can establish thresholds for harmful content categories, including hate - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "266bbea8-fcf9-4b0e-ba7b-fc00f6b1dc73" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -88,3 +86,4 @@ from logs-aws_bedrock.invocation-* | where denied_topics > 5 | sort denied_topics desc ''' + diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml index f7d7e436e95..5839ffdcad4 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_validation_exception_errors_by_single_user.toml @@ -2,18 +2,16 @@ creation_date = "2024/09/11" integration = ["aws_bedrock"] maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or -InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. -These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. -This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring -exhorbitant costs. +Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the +InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or +corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't +have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an +impact on the environment by incurring exhorbitant costs. """ false_positives = ["Legitimate misunderstanding by users on accessing the bedrock models."] from = "now-60m" @@ -21,14 +19,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "AWS Bedrock Detected Multiple Validation Exception Errors by a Single User" -references = [ - "https://atlas.mitre.org/techniques/AML.T0015", - "https://atlas.mitre.org/techniques/AML.T0034", - "https://atlas.mitre.org/techniques/AML.T0046", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 73 -rule_id = "725a048a-88c5-4fc7-8677-a44fc0031822" note = """## Triage and analysis ### Investigating AWS Bedrock Detected Multiple Validation Exception Errors by a Single User @@ -62,6 +52,14 @@ Bedrock offers a variety of pretrained models from Amazon (such as the Titan ser - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://atlas.mitre.org/techniques/AML.T0015", + "https://atlas.mitre.org/techniques/AML.T0034", + "https://atlas.mitre.org/techniques/AML.T0046", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 73 +rule_id = "725a048a-88c5-4fc7-8677-a44fc0031822" setup = """## Setup This rule requires that AWS Bedrock Integration be configured. For more information, see the AWS Bedrock integration documentation: @@ -94,11 +92,8 @@ from logs-aws_bedrock.invocation-* | where total_denials > 3 ''' + + [rule.investigation_fields] -field_names = [ - "target_time_window", - "user.id", - "cloud.account.id", - "total_denials" +field_names = ["target_time_window", "user.id", "cloud.account.id", "total_denials"] -] diff --git a/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml b/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml index e0a4457a13d..ad942edf801 100644 --- a/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml +++ b/rules/integrations/aws_bedrock/aws_bedrock_multiple_word_policy_blocks_detected.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2024/11/20" maturity = "production" -updated_date = "2025/01/17" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,14 +15,6 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Unusual High Word Policy Blocks Detected" -references = [ - "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", - "https://atlas.mitre.org/techniques/AML.T0051", - "https://atlas.mitre.org/techniques/AML.T0054", - "https://www.elastic.co/security-labs/elastic-advances-llm-security" -] -risk_score = 47 -rule_id = "3216949c-9300-4c53-b57a-221e364c6457" note = """## Triage and analysis ### Investigating Unusual High Word Policy Blocks Detected @@ -60,6 +50,14 @@ and they can establish thresholds for harmful content categories, including hate - Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). """ +references = [ + "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html", + "https://atlas.mitre.org/techniques/AML.T0051", + "https://atlas.mitre.org/techniques/AML.T0054", + "https://www.elastic.co/security-labs/elastic-advances-llm-security", +] +risk_score = 47 +rule_id = "3216949c-9300-4c53-b57a-221e364c6457" setup = """## Setup This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation: @@ -88,3 +86,4 @@ from logs-aws_bedrock.invocation-* | where profanity_words > 5 | sort profanity_words desc ''' + diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml index 433effe6628..64c8660b6c6 100644 --- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml +++ b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml @@ -2,9 +2,7 @@ creation_date = "2024/12/11" integration = ["azure"] maturity = "production" -min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules/integrations/azure/credential_access_entra_password_spraying_non_interactive_sfa.toml b/rules/integrations/azure/credential_access_entra_password_spraying_non_interactive_sfa.toml index a22123a9d77..492016712a2 100644 --- a/rules/integrations/azure/credential_access_entra_password_spraying_non_interactive_sfa.toml +++ b/rules/integrations/azure/credential_access_entra_password_spraying_non_interactive_sfa.toml @@ -2,9 +2,7 @@ creation_date = "2025/03/07" integration = ["azure"] maturity = "production" -min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." -min_stack_version = "8.13.0" -updated_date = "2025/03/07" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -75,9 +73,7 @@ This rule identifies repeated failed authentication attempts using non-interacti - Regularly audit authentication logs in `azure.signinlogs` to detect abnormal login behavior and ensure early detection of potential attacks. - Regularly rotate client credentials and secrets for applications using non-interactive authentication to reduce the risk of credential theft. """ -references = [ - "https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf" -] +references = ["https://securityscorecard.com/wp-content/uploads/2025/02/MassiveBotnet-Report_022125_03.pdf"] risk_score = 47 rule_id = "cca64114-fb8b-11ef-86e2-f661ea17fbce" severity = "medium" diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml index 7e451f3a75d..dd16980f85b 100644 --- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml +++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml @@ -2,9 +2,7 @@ creation_date = "2024/09/06" integration = ["azure"] maturity = "production" -min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -21,8 +19,8 @@ false_positives = [ """, ] from = "now-60m" -language = "esql" interval = "10m" +language = "esql" license = "Elastic License v2" name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts" note = """## Triage and analysis @@ -64,7 +62,7 @@ Azure Entra ID, integral to Microsoft 365, manages user identities and access. A This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.""" references = [ "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" + "https://github.com/0xZDH/o365spray", ] risk_score = 47 rule_id = "35ab3cfa-6c67-11ef-ab4d-f661ea17fbcc" diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml index 1f6c63cef5c..ea4e11128c2 100644 --- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml +++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml @@ -2,17 +2,15 @@ creation_date = "2024/09/06" integration = ["azure"] maturity = "production" -min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed -interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to brute force user -accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, SharePoint, or -Teams. +interactive or non-interactive login attempts within a 30-minute window from a single source. Attackers may attempt to +brute force user accounts to gain unauthorized access to Microsoft 365 services via different services such as Exchange, +SharePoint, or Teams. """ false_positives = [ """ @@ -21,8 +19,8 @@ false_positives = [ """, ] from = "now-30m" -language = "esql" interval = "10m" +language = "esql" license = "Elastic License v2" name = "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source" note = """## Triage and analysis @@ -64,7 +62,7 @@ Azure Entra ID, integral to Microsoft 365, manages identity and access, ensuring This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.""" references = [ "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", - "https://github.com/0xZDH/o365spray" + "https://github.com/0xZDH/o365spray", ] risk_score = 47 rule_id = "c6655282-6c79-11ef-bbb5-f661ea17fbcc" diff --git a/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml b/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml index 5e8cc1b19c9..02094bccc60 100644 --- a/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml +++ b/rules/integrations/azure_openai/azure_openai_denial_of_ml_service_detection.toml @@ -1,16 +1,14 @@ [metadata] creation_date = "2025/02/25" maturity = "production" -updated_date = "2025/02/25" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually high volume and frequency -of requests or patterns of requests that are known to cause performance degradation or service disruption, such as -large input sizes or rapid API calls. +Detects patterns indicative of Denial-of-Service (DoS) attacks on machine learning (ML) models, focusing on unusually +high volume and frequency of requests or patterns of requests that are known to cause performance degradation or service +disruption, such as large input sizes or rapid API calls. """ false_positives = ["Unexpected system errors", "Legitimate spikes in usage due to business processes"] from = "now-60m" @@ -20,7 +18,7 @@ license = "Elastic License v2" name = "Potential Denial of Azure OpenAI ML Service" references = [ "https://genai.owasp.org/llmrisk/llm04-model-denial-of-service", - "https://atlas.mitre.org/techniques/AML.T0029" + "https://atlas.mitre.org/techniques/AML.T0029", ] risk_score = 47 rule_id = "b0450411-46e5-46d2-9b35-8b5dd9ba763e" @@ -36,7 +34,7 @@ tags = [ "Data Source: Azure OpenAI", "Data Source: Azure Event Hubs", "Use Case: Denial of Service", - "Mitre Atlas: T0029" + "Mitre Atlas: T0029", ] timestamp_override = "event.ingested" type = "esql" @@ -51,3 +49,4 @@ from logs-azure_openai.logs-* | where count >= 10 and avg_request_size >= 5000 | sort count desc ''' + diff --git a/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml b/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml index 85972ad63f7..89bbc35bdd3 100644 --- a/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml +++ b/rules/integrations/azure_openai/azure_openai_insecure_output_handling_detection.toml @@ -1,16 +1,14 @@ [metadata] creation_date = "2025/02/25" maturity = "production" -updated_date = "2025/02/25" -min_stack_comments = "ES|QL rule type is still in experimental as of 8.13, however this rule was tested successfully; integration in experimental" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling -that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails -to handle outputs correctly under certain input conditions. +Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that +might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to +handle outputs correctly under certain input conditions. """ false_positives = ["Queries that are designed to expect empty responses or benign system errors"] from = "now-60m" @@ -18,9 +16,7 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Azure OpenAI Insecure Output Handling" -references = [ - "https://genai.owasp.org/llmrisk/llm02-insecure-output-handling" -] +references = ["https://genai.owasp.org/llmrisk/llm02-insecure-output-handling"] risk_score = 21 rule_id = "fb16f9ef-cb03-4234-adc2-44641f3b71ee" setup = """## Setup @@ -34,7 +30,7 @@ tags = [ "Domain: LLM", "Data Source: Azure OpenAI", "Data Source: Azure Event Hubs", - "Use Case: Insecure Output Handling" + "Use Case: Insecure Output Handling", ] timestamp_override = "event.ingested" type = "esql" @@ -47,3 +43,4 @@ from logs-azure_openai.logs-* | where count >= 10 | sort count desc ''' + diff --git a/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml b/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml index c32f409c601..64877dfd53d 100644 --- a/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml +++ b/rules/integrations/azure_openai/azure_openai_model_theft_detection.toml @@ -1,15 +1,14 @@ [metadata] creation_date = "2025/02/25" maturity = "production" -updated_date = "2025/02/25" -min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully; integration in tech preview" -min_stack_version = "8.13.0" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, such as -unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model interactions. +Monitors for suspicious activities that may indicate theft or unauthorized duplication of machine learning (ML) models, +such as unauthorized API calls, atypical access patterns, or large data transfers that are unusual during model +interactions. """ false_positives = ["Authorized model training", "Legitimate high volume data exchanges during scheduled updates"] from = "now-60m" @@ -17,10 +16,7 @@ interval = "10m" language = "esql" license = "Elastic License v2" name = "Potential Azure OpenAI Model Theft" -references = [ - "https://genai.owasp.org/llmrisk/llm10-model-theft", - "https://atlas.mitre.org/techniques/AML.T0044" -] +references = ["https://genai.owasp.org/llmrisk/llm10-model-theft", "https://atlas.mitre.org/techniques/AML.T0044"] risk_score = 47 rule_id = "4021e78d-5293-48d3-adee-a70fa4c18fab" setup = """## Setup @@ -36,7 +32,7 @@ tags = [ "Data Source: Azure OpenAI", "Data Source: Azure Event Hubs", "Use Case: Model Theft", - "Mitre Atlas: T0044" + "Mitre Atlas: T0044", ] timestamp_override = "event.ingested" type = "esql" @@ -49,3 +45,4 @@ from logs-azure_openai.logs-* | where count >= 100 or max_data_transferred >= 1000000 | sort count desc ''' + diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml index e0fe44c9c19..2ccf3d1f1e5 100644 --- a/rules/integrations/endpoint/elastic_endpoint_security.toml +++ b/rules/integrations/endpoint/elastic_endpoint_security.toml @@ -2,16 +2,14 @@ creation_date = "2020/07/08" integration = ["endpoint"] maturity = "production" -min_stack_comments = "New fields added: required_fields, related_integrations, setup" -min_stack_version = "8.3.0" promotion = true -updated_date = "2025/02/06" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Generates a detection alert each time an Elastic Defend alert is received. Enabling this rule allows you to -immediately begin investigating your Endpoint alerts. +Generates a detection alert each time an Elastic Defend alert is received. Enabling this rule allows you to immediately +begin investigating your Endpoint alerts. """ enabled = true from = "now-2m" @@ -21,12 +19,45 @@ language = "kuery" license = "Elastic License v2" max_signals = 10000 name = "Endpoint Security (Elastic Defend)" +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 Endpoint Security (Elastic Defend) + +Elastic Defend is a robust endpoint security solution that monitors and protects systems by analyzing events and generating alerts for suspicious activities. Adversaries may exploit endpoints by executing unauthorized code or manipulating system processes. The detection rule leverages event data to identify alerts from Elastic Defend, focusing on potential threats while excluding non-relevant modules, thus enabling timely investigation of endpoint anomalies. + +### Possible investigation steps +- Review the alert details to understand the specific event.kind:alert and event.module: endpoint that triggered the alert, ensuring it is not related to the excluded endgame module. +- Examine the timeline of events leading up to the alert to identify any unusual or unauthorized activities, such as unexpected process executions or system changes. +- Correlate the alert with other security events or logs from the same endpoint to gather additional context and determine if there is a pattern of suspicious behavior. +- Investigate the source and destination of any network connections associated with the alert to identify potential command and control activity or data exfiltration attempts. +- Check for any recent changes or updates to the endpoint's software or configuration that could explain the alert, ensuring they are legitimate and authorized. +- Assess the risk score and severity of the alert in conjunction with other alerts from the same endpoint to prioritize the investigation and response efforts. + +### False positive analysis + +- Alerts triggered by routine software updates can be false positives. Users can create exceptions for known update processes to prevent unnecessary alerts. +- System maintenance activities, such as scheduled scans or backups, may generate alerts. Exclude these activities by identifying their specific event signatures and adding them to the exception list. +- Legitimate administrative actions, like remote desktop sessions or script executions by IT staff, might be flagged. Define exceptions for these actions by correlating them with authorized user accounts or IP addresses. +- Frequent alerts from non-malicious applications that interact with system processes can be excluded by whitelisting these applications based on their hash or path. +- Network monitoring tools that simulate attack patterns for testing purposes may trigger alerts. Exclude these tools by specifying their known behaviors and IP ranges in the exception settings. + +### Response and remediation + +- Isolate the affected endpoint immediately to prevent further unauthorized access or lateral movement within the network. +- Analyze the alert details to identify the specific unauthorized code or process manipulation involved, and terminate any malicious processes identified. +- Remove any unauthorized code or files from the affected endpoint, ensuring that all traces of the threat are eradicated. +- Conduct a thorough review of system logs and event data to identify any additional indicators of compromise or related suspicious activities. +- Update endpoint security configurations and signatures to prevent similar threats from exploiting the same vulnerabilities in the future. +- Restore the affected endpoint from a known good backup if necessary, ensuring that the system is free from any residual threats. +- Escalate the incident to the security operations center (SOC) or relevant team for further analysis and to determine if additional systems may be affected.""" risk_score = 47 rule_id = "9a1a2dae-0b5f-4c3d-8305-a268d404c306" rule_name_override = "message" -setup = """ -## Setup +setup = """## Setup ### Elastic Defend Alerts If this rule is disabled, you will not receive alerts for Elastic Defend alerts. This rule is designed to capture all alerts generated by Elastic Defend. For more granular alerting, consider using additional prebuilt-rules that capture specific Elastic Defend alerts. @@ -60,41 +91,6 @@ type = "query" query = ''' event.kind:alert and event.module:(endpoint and not endgame) ''' -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 Endpoint Security (Elastic Defend) - -Elastic Defend is a robust endpoint security solution that monitors and protects systems by analyzing events and generating alerts for suspicious activities. Adversaries may exploit endpoints by executing unauthorized code or manipulating system processes. The detection rule leverages event data to identify alerts from Elastic Defend, focusing on potential threats while excluding non-relevant modules, thus enabling timely investigation of endpoint anomalies. - -### Possible investigation steps - -- Review the alert details to understand the specific event.kind:alert and event.module: endpoint that triggered the alert, ensuring it is not related to the excluded endgame module. -- Examine the timeline of events leading up to the alert to identify any unusual or unauthorized activities, such as unexpected process executions or system changes. -- Correlate the alert with other security events or logs from the same endpoint to gather additional context and determine if there is a pattern of suspicious behavior. -- Investigate the source and destination of any network connections associated with the alert to identify potential command and control activity or data exfiltration attempts. -- Check for any recent changes or updates to the endpoint's software or configuration that could explain the alert, ensuring they are legitimate and authorized. -- Assess the risk score and severity of the alert in conjunction with other alerts from the same endpoint to prioritize the investigation and response efforts. - -### False positive analysis - -- Alerts triggered by routine software updates can be false positives. Users can create exceptions for known update processes to prevent unnecessary alerts. -- System maintenance activities, such as scheduled scans or backups, may generate alerts. Exclude these activities by identifying their specific event signatures and adding them to the exception list. -- Legitimate administrative actions, like remote desktop sessions or script executions by IT staff, might be flagged. Define exceptions for these actions by correlating them with authorized user accounts or IP addresses. -- Frequent alerts from non-malicious applications that interact with system processes can be excluded by whitelisting these applications based on their hash or path. -- Network monitoring tools that simulate attack patterns for testing purposes may trigger alerts. Exclude these tools by specifying their known behaviors and IP ranges in the exception settings. - -### Response and remediation - -- Isolate the affected endpoint immediately to prevent further unauthorized access or lateral movement within the network. -- Analyze the alert details to identify the specific unauthorized code or process manipulation involved, and terminate any malicious processes identified. -- Remove any unauthorized code or files from the affected endpoint, ensuring that all traces of the threat are eradicated. -- Conduct a thorough review of system logs and event data to identify any additional indicators of compromise or related suspicious activities. -- Update endpoint security configurations and signatures to prevent similar threats from exploiting the same vulnerabilities in the future. -- Restore the affected endpoint from a known good backup if necessary, ensuring that the system is free from any residual threats. -- Escalate the incident to the security operations center (SOC) or relevant team for further analysis and to determine if additional systems may be affected.""" [[rule.exceptions_list]] diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml index f2b2ded39ab..505b0df6390 100644 --- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml +++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/29" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,17 +17,6 @@ index = ["logs-github.audit-*"] language = "eql" license = "Elastic License v2" name = "GitHub Protected Branch Settings Changed" -risk_score = 47 -rule_id = "07639887-da3a-4fbf-9532-8ce748ff8c50" -severity = "medium" -tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Defense Evasion", "Data Source: Github", "Resources: Investigation Guide"] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -configuration where event.dataset == "github.audit" - and github.category == "protected_branch" and event.type == "change" -''' note = """## Triage and analysis > **Disclaimer**: @@ -64,6 +51,23 @@ GitHub's protected branch settings are crucial for maintaining code integrity by - Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities. - Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings. - Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans.""" +risk_score = 47 +rule_id = "07639887-da3a-4fbf-9532-8ce748ff8c50" +severity = "medium" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +configuration where event.dataset == "github.audit" + and github.category == "protected_branch" and event.type == "change" +''' [[rule.threat]] diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml index 7df27b1522f..5bf9ba190ef 100644 --- a/rules/integrations/github/execution_github_app_deleted.toml +++ b/rules/integrations/github/execution_github_app_deleted.toml @@ -2,9 +2,7 @@ creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,16 +12,6 @@ index = ["logs-github.audit-*"] language = "eql" license = "Elastic License v2" name = "GitHub App Deleted" -risk_score = 21 -rule_id = "fd01b949-81be-46d5-bcf8-284395d5f56d" -severity = "low" -tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github", "Resources: Investigation Guide"] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion" -''' note = """## Triage and analysis > **Disclaimer**: @@ -59,6 +47,22 @@ GitHub Apps are integrations that extend GitHub's functionality, often used to a - Implement additional monitoring on the affected repositories or organization to detect any further suspicious activities or attempts to delete apps. - Review and tighten permissions for GitHub apps to ensure only authorized personnel have the ability to delete or modify app installations. - Escalate the incident to higher-level security management if there is evidence of a broader compromise or if the deletion is part of a larger attack campaign.""" +risk_score = 21 +rule_id = "fd01b949-81be-46d5-bcf8-284395d5f56d" +severity = "low" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion" +''' [[rule.threat]] diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml index e2a6531a045..723fabe54ae 100644 --- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml +++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml @@ -2,9 +2,7 @@ creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,25 +15,6 @@ index = ["logs-github.audit-*"] language = "kuery" license = "Elastic License v2" name = "High Number of Cloned GitHub Repos From PAT" -risk_score = 21 -rule_id = "fb0afac5-bbd6-49b0-b4f8-44e5381e1587" -severity = "low" -tags = [ - "Domain: Cloud", - "Use Case: Threat Detection", - "Use Case: UEBA", - "Tactic: Execution", - "Data Source: Github", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "threshold" - -query = ''' -event.dataset:"github.audit" and event.category:"configuration" and event.action:"git.clone" and -github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and -github.repository_public:false -''' note = """## Triage and analysis > **Disclaimer**: @@ -70,6 +49,25 @@ Personal Access Tokens (PATs) facilitate automated access to GitHub repositories - Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials. - Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised. - Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future.""" +risk_score = 21 +rule_id = "fb0afac5-bbd6-49b0-b4f8-44e5381e1587" +severity = "low" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Use Case: UEBA", + "Tactic: Execution", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "threshold" + +query = ''' +event.dataset:"github.audit" and event.category:"configuration" and event.action:"git.clone" and +github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and +github.repository_public:false +''' [[rule.threat]] diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml index f6a63c75a1b..1bd5931c41a 100644 --- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml +++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml @@ -1,9 +1,7 @@ [metadata] creation_date = "2023/12/14" maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,24 +15,6 @@ index = [".alerts-security.*"] language = "kuery" license = "Elastic License v2" name = "GitHub UEBA - Multiple Alerts from a GitHub Account" -risk_score = 47 -rule_id = "929223b4-fba3-4a1c-a943-ec4716ad23ec" -severity = "medium" -tags = [ - "Domain: Cloud", - "Use Case: Threat Detection", - "Use Case: UEBA", - "Tactic: Execution", - "Rule Type: Higher-Order Rule", - "Data Source: Github", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "threshold" - -query = ''' -signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open" -''' note = """## Triage and analysis > **Disclaimer**: @@ -70,6 +50,24 @@ User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify - Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional accounts or systems are affected. - Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. - Update and refine access controls and permissions for the affected account to minimize the risk of future unauthorized actions.""" +risk_score = 47 +rule_id = "929223b4-fba3-4a1c-a943-ec4716ad23ec" +severity = "medium" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Use Case: UEBA", + "Tactic: Execution", + "Rule Type: Higher-Order Rule", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "threshold" + +query = ''' +signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open" +''' [[rule.threat]] diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml index 3fae7bd4642..d7a9a7fb68d 100644 --- a/rules/integrations/github/execution_new_github_app_installed.toml +++ b/rules/integrations/github/execution_new_github_app_installed.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/29" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -20,16 +18,6 @@ index = ["logs-github.audit-*"] language = "eql" license = "Elastic License v2" name = "New GitHub App Installed" -risk_score = 47 -rule_id = "1ca62f14-4787-4913-b7af-df11745a49da" -severity = "medium" -tags = ["Domain: Cloud", "Use Case: Threat Detection", "Tactic: Execution", "Data Source: Github", "Resources: Investigation Guide"] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -configuration where event.dataset == "github.audit" and event.action == "integration_installation.create" -''' note = """## Triage and analysis > **Disclaimer**: @@ -64,6 +52,22 @@ GitHub Apps enhance functionality by integrating with repositories and organizat - Escalate the incident to higher-level security management if the app installation is linked to a broader security breach or if sensitive data has been compromised. - Implement stricter access controls and approval processes for future GitHub App installations to prevent unauthorized installations. - Update detection mechanisms to include additional indicators of compromise related to GitHub App installations, enhancing future threat detection capabilities.""" +risk_score = 47 +rule_id = "1ca62f14-4787-4913-b7af-df11745a49da" +severity = "medium" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +configuration where event.dataset == "github.audit" and event.action == "integration_installation.create" +''' [[rule.threat]] diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml index 663e5d4326e..19dff9fd749 100644 --- a/rules/integrations/github/impact_github_repository_deleted.toml +++ b/rules/integrations/github/impact_github_repository_deleted.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/29" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,23 +17,6 @@ index = ["logs-github.audit-*"] language = "eql" license = "Elastic License v2" name = "GitHub Repository Deleted" -risk_score = 47 -rule_id = "345889c4-23a8-4bc0-b7ca-756bd17ce83b" -severity = "medium" -tags = [ - "Domain: Cloud", - "Use Case: Threat Detection", - "Use Case: UEBA", - "Tactic: Impact", - "Data Source: Github", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy" -''' note = """## Triage and analysis > **Disclaimer**: @@ -69,6 +50,23 @@ GitHub repositories are essential for managing code and collaboration within org - Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future. - Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected. - Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors.""" +risk_score = 47 +rule_id = "345889c4-23a8-4bc0-b7ca-756bd17ce83b" +severity = "medium" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Use Case: UEBA", + "Tactic: Impact", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy" +''' [[rule.threat]] diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml index 6caa8361a05..6ebccba2979 100644 --- a/rules/integrations/github/persistence_github_org_owner_added.toml +++ b/rules/integrations/github/persistence_github_org_owner_added.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/11" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,23 +16,6 @@ index = ["logs-github.audit-*"] language = "eql" license = "Elastic License v2" name = "New GitHub Owner Added" -risk_score = 47 -rule_id = "24401eca-ad0b-4ff9-9431-487a8e183af9" -severity = "medium" -tags = [ - "Domain: Cloud", - "Use Case: Threat Detection", - "Use Case: UEBA", - "Tactic: Persistence", - "Data Source: Github", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin" -''' note = """## Triage and analysis > **Disclaimer**: @@ -70,6 +51,23 @@ GitHub organizations allow collaborative management of repositories, where the ' - Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel. - Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly. - If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach.""" +risk_score = 47 +rule_id = "24401eca-ad0b-4ff9-9431-487a8e183af9" +severity = "medium" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Use Case: UEBA", + "Tactic: Persistence", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin" +''' [[rule.threat]] diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml index dec4ab5c005..c8b2b1f0fc5 100644 --- a/rules/integrations/github/persistence_organization_owner_role_granted.toml +++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/11" integration = ["github"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,23 +16,6 @@ index = ["logs-github.audit-*"] language = "eql" license = "Elastic License v2" name = "GitHub Owner Role Granted To User" -risk_score = 47 -rule_id = "9b343b62-d173-4cfd-bd8b-e6379f964ca4" -severity = "medium" -tags = [ - "Domain: Cloud", - "Use Case: Threat Detection", - "Use Case: UEBA", - "Tactic: Persistence", - "Data Source: Github", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin" -''' note = """## Triage and analysis > **Disclaimer**: @@ -68,6 +49,23 @@ In GitHub organizations, the owner role grants comprehensive administrative priv - Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process. - Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited. - Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future.""" +risk_score = 47 +rule_id = "9b343b62-d173-4cfd-bd8b-e6379f964ca4" +severity = "medium" +tags = [ + "Domain: Cloud", + "Use Case: Threat Detection", + "Use Case: UEBA", + "Tactic: Persistence", + "Data Source: Github", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin" +''' [[rule.threat]] diff --git a/rules/integrations/o365/collection_onedrive_excessive_file_downloads.toml b/rules/integrations/o365/collection_onedrive_excessive_file_downloads.toml index b4a44b5ae46..1703382559e 100644 --- a/rules/integrations/o365/collection_onedrive_excessive_file_downloads.toml +++ b/rules/integrations/o365/collection_onedrive_excessive_file_downloads.toml @@ -2,9 +2,7 @@ creation_date = "2025/02/19" integration = ["o365"] maturity = "production" -min_stack_comments = "ES|QL in technical preview" -min_stack_version = "8.13.0" -updated_date = "2025/02/19" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -118,7 +116,6 @@ reference = "https://attack.mitre.org/techniques/T1530/" id = "TA0009" name = "Collection" reference = "https://attack.mitre.org/tactics/TA0009/" - [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml index af9ae71f8f1..51ed12cd1af 100644 --- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml +++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml @@ -2,14 +2,14 @@ creation_date = "2020/11/30" integration = ["o365"] maturity = "production" -min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic", "Willem D'Haese", "Austin Songer"] description = """ -Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed login attempts or login sources within a 30-minute window. Attackers may attempt to brute force user accounts to gain unauthorized access to Microsoft 365 services. +Identifies potential brute-force attempts against Microsoft 365 user accounts by detecting a high number of failed login +attempts or login sources within a 30-minute window. Attackers may attempt to brute force user accounts to gain +unauthorized access to Microsoft 365 services. """ false_positives = [ """ @@ -21,6 +21,41 @@ from = "now-9m" language = "esql" license = "Elastic License v2" name = "Attempts to Brute Force a Microsoft 365 User Account" +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 Attempts to Brute Force a Microsoft 365 User Account + +Microsoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity. + +### Possible investigation steps + +- Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses. +- Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources. +- Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts. +- Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity. +- Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents. +- Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat. + +### False positive analysis + +- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities. +- Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses. +- Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses. +- Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity. +- Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts. +- Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation. +- Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies. +- Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources. +- Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices. +- Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected.""" references = [ "https://blueteamblog.com/7-ways-to-monitor-your-office-365-logs-using-siem", "https://learn.microsoft.com/en-us/purview/audit-log-detailed-properties", @@ -87,41 +122,6 @@ from logs-o365.audit-* // filter for users with more than 20 login sources or failed login attempts | where (login_source_count >= 20 or failed_login_count >= 20) ''' -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 Attempts to Brute Force a Microsoft 365 User Account - -Microsoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity. - -### Possible investigation steps - -- Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses. -- Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources. -- Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts. -- Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity. -- Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents. -- Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat. - -### False positive analysis - -- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities. -- Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses. -- Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses. -- Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity. -- Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts. - -### Response and remediation - -- Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts. -- Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation. -- Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies. -- Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources. -- Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices. -- Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected.""" [[rule.threat]] diff --git a/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml b/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml index 4f92c9ea1a6..0b4b378375e 100644 --- a/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml +++ b/rules/linux/command_and_control_frequent_egress_netcon_from_sus_executable.toml @@ -2,17 +2,15 @@ creation_date = "2025/02/20" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/02/20" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects a high number of egress network connections from an unusual executable on a Linux system. -This could indicate a command and control (C2) communication attempt, a brute force attack via a malware -infection, or other malicious activity. ES|QL rules have limited fields available in its alert documents. -Make sure to review the original documents to aid in the investigation of this alert. +This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could +indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other +malicious activity. ES|QL rules have limited fields available in its alert documents. Make sure to review the original +documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -56,6 +54,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.network-* | keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, destination.ip, agent.id @@ -85,15 +84,17 @@ from logs-endpoint.events.network-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" + [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" + diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml index 329a6d1d1d2..34d8b13e7ff 100644 --- a/rules/linux/command_and_control_ip_forwarding_activity.toml +++ b/rules/linux/command_and_control_ip_forwarding_activity.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,35 +16,6 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "IPv4/IPv6 Forwarding Activity" -risk_score = 21 -rule_id = "5a138e2e-aec3-4240-9843-56825d0bc569" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Command and Control", - "Data Source: Elastic Defend", - "Data Source: SentinelOne", - "Data Source: Elastic Endgame", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and -process.parent.executable != null and process.command_line like ( - "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*", - "*/proc/sys/net/ipv6/conf/all/forwarding*" -) and ( - (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or - ( - process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and - process.command_line like "*echo *" - ) -) and -not process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap") -''' note = """## Triage and analysis > **Disclaimer**: @@ -82,16 +51,48 @@ IPv4/IPv6 forwarding allows a Linux system to route traffic between network inte - Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. - Implement network segmentation to limit the ability of attackers to pivot between networks in the future. - Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse.""" +risk_score = 21 +rule_id = "5a138e2e-aec3-4240-9843-56825d0bc569" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Command and Control", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and +process.parent.executable != null and process.command_line like ( + "*net.ipv4.ip_forward*", "*/proc/sys/net/ipv4/ip_forward*", "*net.ipv6.conf.all.forwarding*", + "*/proc/sys/net/ipv6/conf/all/forwarding*" +) and ( + (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or + ( + process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and + process.command_line like "*echo *" + ) +) and +not process.parent.name like~ ("privsep-helper", "platform-python*", "init.ipv6-global", "wsl-bootstrap") +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1572" name = "Protocol Tunneling" reference = "https://attack.mitre.org/techniques/T1572/" + [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" + diff --git a/rules/linux/command_and_control_linux_proxychains_activity.toml b/rules/linux/command_and_control_linux_proxychains_activity.toml index 46cd848e64f..f71f59a1770 100644 --- a/rules/linux/command_and_control_linux_proxychains_activity.toml +++ b/rules/linux/command_and_control_linux_proxychains_activity.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -41,7 +39,14 @@ resources. Attackers can exploit the ProxyChains utility to hide their true sour perform malicious activities through a chain of proxy servers, potentially masking their identity and intentions. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "ProxyChains Activity" diff --git a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml index 4cc5b788c70..b4d383c26e2 100644 --- a/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml +++ b/rules/linux/command_and_control_linux_ssh_x11_forwarding.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -41,7 +39,12 @@ can abuse X11 forwarding for tunneling their GUI-based tools, pivot through comp communication channels, enabling lateral movement and facilitating remote control of systems within a network. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Linux SSH X11 Forwarding" @@ -121,21 +124,24 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name in ("ssh", "sshd") and process.args in ("-X", "-Y") and process.args_count >= 3 and process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1572" name = "Protocol Tunneling" reference = "https://attack.mitre.org/techniques/T1572/" + [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" + diff --git a/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml b/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml index baf53ccab50..b200f9576d9 100644 --- a/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml +++ b/rules/linux/command_and_control_linux_suspicious_proxychains_activity.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -42,7 +40,14 @@ detection, and perform malicious activities through a chain of proxy servers, po intentions. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Suspicious Utility Launched via ProxyChains" diff --git a/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml b/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml index 68be50722be..2a193201c40 100644 --- a/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml +++ b/rules/linux/command_and_control_linux_tunneling_and_port_forwarding.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -41,7 +39,12 @@ and gain unauthorized access to internal resources, facilitating data exfiltrati control. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Linux Tunneling and/or Port Forwarding" diff --git a/rules/linux/command_and_control_tunneling_via_earthworm.toml b/rules/linux/command_and_control_tunneling_via_earthworm.toml index b5f92960e13..67530824eca 100644 --- a/rules/linux/command_and_control_tunneling_via_earthworm.toml +++ b/rules/linux/command_and_control_tunneling_via_earthworm.toml @@ -2,9 +2,7 @@ creation_date = "2021/04/12" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -40,7 +38,13 @@ system within a separate protocol to avoid detection and network filtering, or t systems. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Protocol Tunneling via EarthWorm" diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml index 1ffa0927ca8..fdbfae8b553 100644 --- a/rules/linux/credential_access_credential_dumping.toml +++ b/rules/linux/credential_access_credential_dumping.toml @@ -2,9 +2,7 @@ creation_date = "2023/02/27" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -16,10 +14,49 @@ password-cracking utilities or prepare themselves for future operations by gathe victim. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Linux Credential Dumping via Unshadow" +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 Linux Credential Dumping via Unshadow + +Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more. +- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access. +- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified. +- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents. + +### False positive analysis + +- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows. +- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. +- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives. +- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities. +- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access. +- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials. +- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for similar activities across the network to detect and respond to future credential dumping attempts promptly.""" references = ["https://www.cyberciti.biz/faq/unix-linux-password-cracking-john-the-ripper/"] risk_score = 47 rule_id = "e7cb3cfd-aaa3-4d7b-af18-23b89955062c" @@ -67,40 +104,6 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "unshadow" and process.args_count >= 3 ''' -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 Linux Credential Dumping via Unshadow - -Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more. -- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access. -- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified. -- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution. -- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. -- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents. - -### False positive analysis - -- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows. -- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. -- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives. -- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities. -- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access. -- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials. -- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Implement enhanced monitoring and logging for similar activities across the network to detect and respond to future credential dumping attempts promptly.""" [[rule.threat]] diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml index 267ef6a5683..8108fc8429d 100644 --- a/rules/linux/credential_access_gdb_init_process_hooking.toml +++ b/rules/linux/credential_access_gdb_init_process_hooking.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/30" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,49 @@ dumping techniques to attempt secret extraction from privileged processes. Tools "truffleproc" and "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Linux init (PID 1) Secret Dump via GDB" +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 init (PID 1) Secret Dump via GDB + +In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1". +- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system. +- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script. +- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack. +- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections. +- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated. + +### False positive analysis + +- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions. +- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe. +- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources. +- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities. +- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts. +- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required. +- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future.""" references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"] risk_score = 47 rule_id = "d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f" @@ -65,40 +102,6 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1" ''' -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 init (PID 1) Secret Dump via GDB - -In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation. - -### Possible investigation steps - -- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1". -- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system. -- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script. -- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack. -- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections. -- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated. - -### False positive analysis - -- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions. -- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe. -- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources. -- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity. -- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities. -- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts. -- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems. -- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required. -- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future.""" [[rule.threat]] diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml index d668a5a7a2d..af461be6f71 100644 --- a/rules/linux/credential_access_gdb_process_hooking.toml +++ b/rules/linux/credential_access_gdb_process_hooking.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/30" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,35 +12,17 @@ secret extraction from privileged processes. Tools that display this behavior in "bash-memory-dump". This behavior should not happen by default, and should be investigated thoroughly. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Linux Process Hooking via GDB" -references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"] -risk_score = 21 -rule_id = "66c058f3-99f4-4d18-952b-43348f2577a0" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Credential Access", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Auditd Manager", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") - and process.name == "gdb" and process.args in ("--pid", "-p") and -/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */ -process.args != "1" -''' note = """## Triage and analysis > **Disclaimer**: @@ -78,6 +58,31 @@ GDB, the GNU Debugger, is a powerful tool used for debugging applications by ins - Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use. - Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" +references = ["https://github.com/controlplaneio/truffleproc", "https://github.com/hajzer/bash-memory-dump"] +risk_score = 21 +rule_id = "66c058f3-99f4-4d18-952b-43348f2577a0" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") + and process.name == "gdb" and process.args in ("--pid", "-p") and +/* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */ +process.args != "1" +''' [[rule.threat]] diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml index bdae2eaf8e1..f3874305266 100644 --- a/rules/linux/credential_access_proc_credential_dumping.toml +++ b/rules/linux/credential_access_proc_credential_dumping.toml @@ -2,9 +2,7 @@ creation_date = "2023/04/26" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,42 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Potential Linux Credential Dumping via Proc Filesystem" +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 Linux Credential Dumping via Proc Filesystem + +The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved. +- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query. +- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'. +- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks. +- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity. +- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections. +- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident. + +### False positive analysis + +- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands. +- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths. +- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts. +- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods. +- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments. +- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts. +- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse. +- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" references = [ "https://github.com/huntergregal/mimipenguin", "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20781", @@ -71,42 +105,6 @@ sequence by host.id, process.parent.name with maxspan=1m [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event") and process.args : "/tmp/*"] ''' -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 Linux Credential Dumping via Proc Filesystem - -The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem. - -### Possible investigation steps - -- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved. -- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query. -- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'. -- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks. -- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity. -- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections. -- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident. - -### False positive analysis - -- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands. -- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths. -- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts. -- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods. -- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments. -- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts. -- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse. -- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation. -- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml index 802a66e3ede..8e81a161cfe 100644 --- a/rules/linux/credential_access_ssh_backdoor_log.toml +++ b/rules/linux/credential_access_ssh_backdoor_log.toml @@ -2,9 +2,7 @@ creation_date = "2020/12/21" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/01/29" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,41 @@ index = ["auditbeat-*", "logs-endpoint.events.file-*", "endgame-*", "logs-sentin language = "eql" license = "Elastic License v2" name = "Potential OpenSSH Backdoor Logging Activity" +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 OpenSSH Backdoor Logging Activity + +OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches. + +### Possible investigation steps + +- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth". +- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions. +- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised. +- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting. +- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity. +- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services. + +### False positive analysis + +- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts. +- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious. +- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations. +- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise. +- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity. +- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes. +- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications. +- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials. +- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat.""" references = [ "https://github.com/eset/malware-ioc/tree/master/sshdoor", "https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf", @@ -112,41 +145,6 @@ file where host.os.type == "linux" and event.type == "change" and process.execut ) ) ''' -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 OpenSSH Backdoor Logging Activity - -OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches. - -### Possible investigation steps - -- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth". -- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions. -- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised. -- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting. -- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity. -- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services. - -### False positive analysis - -- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts. -- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious. -- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations. -- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise. -- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity. -- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes. -- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications. -- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials. -- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml index 5d28c2abd93..8ca35ddc450 100644 --- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml +++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml @@ -2,48 +2,23 @@ creation_date = "2024/08/23" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] -description = """ -This rule detects Linux Access Control List (ACL) modification via the setfacl command. -""" +description = "This rule detects Linux Access Control List (ACL) modification via the setfacl command.\n" from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Access Control List Modification via setfacl" -references = ["https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts"] -risk_score = 21 -rule_id = "999565a2-fc52-4d72-91e4-ba6712c0377e" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Auditd Manager", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -process where host.os.type == "linux" and event.type == "start" and -event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and -process.name == "setfacl" and not ( - process.command_line == "/bin/setfacl --restore=-" or - process.args == "/var/log/journal/" or - process.parent.name in ("stats.pl", "perl", "find") or - process.parent.command_line like~ "/bin/sh -c *ansible*" -) -''' note = """## Triage and analysis > **Disclaimer**: @@ -77,21 +52,54 @@ Access Control Lists (ACLs) in Linux enhance file permission management by allow - Update and patch the system to address any vulnerabilities that may have been exploited to gain access. - Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future. - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" +references = [ + "https://www.uptycs.com/blog/threat-research-report-team/evasive-techniques-used-by-malicious-linux-shell-scripts", +] +risk_score = 21 +rule_id = "999565a2-fc52-4d72-91e4-ba6712c0377e" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "setfacl" and not ( + process.command_line == "/bin/setfacl --restore=-" or + process.args == "/var/log/journal/" or + process.parent.name in ("stats.pl", "perl", "find") or + process.parent.command_line like~ "/bin/sh -c *ansible*" +) +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1222" name = "File and Directory Permissions Modification" reference = "https://attack.mitre.org/techniques/T1222/" - [[rule.threat.technique.subtechnique]] id = "T1222.002" name = "Linux and Mac File and Directory Permissions Modification" reference = "https://attack.mitre.org/techniques/T1222/002/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml index ae6348cef81..c3587dda471 100644 --- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml +++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml @@ -2,22 +2,58 @@ creation_date = "2024/08/28" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/24" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that -provides system auditing and logging. Disabling the Auditd service can prevent the system from logging important -security events, which can be used to detect malicious activity. +Adversaries may attempt to disable the Auditd service to evade detection. Auditd is a Linux service that provides system +auditing and logging. Disabling the Auditd service can prevent the system from logging important security events, which +can be used to detect malicious activity. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "logs-endpoint.events.process*", + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Attempt to Disable Auditd Service" +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 Attempt to Disable Auditd Service + +Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics. + +### Possible investigation steps + +- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args. +- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts. +- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed. +- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured. +- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns. + +### False positive analysis + +- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts. +- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment. +- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions. +- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities. +- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert. +- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services.""" risk_score = 21 rule_id = "6a058ed6-4e9f-49f3-8f8e-f32165ae7ebf" setup = """## Setup @@ -59,6 +95,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( (process.name == "service" and process.args == "stop") or @@ -68,54 +105,23 @@ process where host.os.type == "linux" and event.type == "start" and event.action process.args in ("auditd", "auditd.service") and not process.parent.name == "auditd.prerm" ''' -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 Attempt to Disable Auditd Service - -Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics. - -### Possible investigation steps - -- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args. -- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts. -- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed. -- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured. -- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns. - -### False positive analysis - -- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts. -- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts. -- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment. -- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. -- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions. -- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities. -- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert. -- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. -- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1562" name = "Impair Defenses" reference = "https://attack.mitre.org/techniques/T1562/" - [[rule.threat.technique.subtechnique]] id = "T1562.001" name = "Disable or Modify Tools" reference = "https://attack.mitre.org/techniques/T1562/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml index 024008d82c8..330d65b308c 100644 --- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml +++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml @@ -2,9 +2,7 @@ creation_date = "2023/02/22" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,41 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Attempt to Disable IPTables or Firewall" +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 Attempt to Disable IPTables or Firewall + +Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics. + +### Possible investigation steps + +- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services. +- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop". +- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised. +- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event". +- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped. +- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts. + +### False positive analysis + +- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions. +- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities. +- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives. +- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows. +- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities. +- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked. +- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert. +- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly. +- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future.""" references = ["https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security"] risk_score = 21 rule_id = "83e9c2b3-24ef-4c1d-a8cd-5ebafb5dfa2f" @@ -78,41 +111,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) ) ''' -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 Attempt to Disable IPTables or Firewall - -Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics. - -### Possible investigation steps - -- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services. -- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop". -- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised. -- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event". -- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped. -- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts. - -### False positive analysis - -- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions. -- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities. -- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives. -- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows. -- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary. -- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities. -- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked. -- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert. -- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. -- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly. -- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml index b8eb9f0e226..aadb19c4e63 100644 --- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml +++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/27" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,50 @@ Adversaries may attempt to disable the syslog service in an attempt to an attemp detection by security controls. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Attempt to Disable Syslog Service" +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 Attempt to Disable Syslog Service + +Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses. + +### Possible investigation steps + +- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious. +- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted. +- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script. +- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack. +- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack. + +### False positive analysis + +- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks. +- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts. +- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes. +- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening. +- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality. +- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`. +- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents.""" references = ["https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security"] risk_score = 47 rule_id = "2f8a1226-5720-437d-9c20-e0029deb6194" @@ -80,40 +118,6 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event", ) and process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service") and not process.parent.name == "rsyslog-rotate" ''' -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 Attempt to Disable Syslog Service - -Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses. - -### Possible investigation steps - -- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious. -- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted. -- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script. -- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack. -- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack. - -### False positive analysis - -- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks. -- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts. -- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes. -- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening. -- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. -- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality. -- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`. -- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled. -- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected. -- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms. -- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml index 613f65a3b6d..53fe306644f 100644 --- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml +++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/17" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -16,10 +14,52 @@ false_positives = [ """, ] from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Base16 or Base32 Encoding/Decoding Activity" +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 Base16 or Base32 Encoding/Decoding Activity + +Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks. + +### Possible investigation steps + +- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks. +- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program. +- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns. +- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains. +- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths. +- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems. +- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts. +- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments. +- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes. +- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity. +- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" risk_score = 21 rule_id = "debff20a-46bc-4a4d-bae5-5cdd14222795" setup = """## Setup @@ -81,41 +121,6 @@ process where host.os.type == "linux" and event.type == "start" and process.name in ("base16", "base32", "base32plain", "base32hex") and not process.args in ("--help", "--version") ''' -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 Base16 or Base32 Encoding/Decoding Activity - -Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks. - -### Possible investigation steps - -- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks. -- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. -- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program. -- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns. -- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains. -- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts. - -### False positive analysis - -- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. -- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths. -- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems. -- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts. -- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives. - -### Response and remediation - -- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. -- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments. -- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes. -- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity. -- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy. -- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary. -- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_base64_decoding_activity.toml b/rules/linux/defense_evasion_base64_decoding_activity.toml index 68feb42e0ef..9ea9cdedf0f 100644 --- a/rules/linux/defense_evasion_base64_decoding_activity.toml +++ b/rules/linux/defense_evasion_base64_decoding_activity.toml @@ -2,17 +2,15 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/02/21" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule leverages ES|QL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may -use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade -detection by host- or network-based security controls. ES|QL rules have limited fields available in its alert -documents. Make sure to review the original documents to aid in the investigation of this alert. +This rule leverages ES|QL to detect unusual base64 encoding/decoding activity on Linux systems. Attackers may use base64 +encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or +network-based security controls. ES|QL rules have limited fields available in its alert documents. Make sure to review +the original documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -57,6 +55,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.process-* | keep @timestamp, host.os.type, event.type, event.action, process.name, process.args, process.command_line, agent.id @@ -77,48 +76,49 @@ from logs-endpoint.events.process-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1027" +name = "Obfuscated Files or Information" +reference = "https://attack.mitre.org/techniques/T1027/" - [rule.threat.tactic] - name = "Defense Evasion" - id = "TA0005" - reference = "https://attack.mitre.org/tactics/TA0005/" +[[rule.threat.technique]] +id = "T1140" +name = "Deobfuscate/Decode Files or Information" +reference = "https://attack.mitre.org/techniques/T1140/" - [[rule.threat.technique]] - name = "Obfuscated Files or Information" - id = "T1027" - reference = "https://attack.mitre.org/techniques/T1027/" - - [[rule.threat.technique]] - name = "Deobfuscate/Decode Files or Information" - id = "T1140" - reference = "https://attack.mitre.org/techniques/T1140/" +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" + + +[[rule.threat.technique]] +id = "T1204" +name = "User Execution" +reference = "https://attack.mitre.org/techniques/T1204/" +[[rule.threat.technique.subtechnique]] +id = "T1204.002" +name = "Malicious File" +reference = "https://attack.mitre.org/techniques/T1204/002/" + + + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" - - [[rule.threat.technique]] - id = "T1059" - name = "Command and Scripting Interpreter" - reference = "https://attack.mitre.org/techniques/T1059/" - - [[rule.threat.technique.subtechnique]] - name = "Unix Shell" - id = "T1059.004" - reference = "https://attack.mitre.org/techniques/T1059/004/" - - [[rule.threat.technique]] - name = "User Execution" - id = "T1204" - reference = "https://attack.mitre.org/techniques/T1204/" - - [[rule.threat.technique.subtechnique]] - name = "Malicious File" - id = "T1204.002" - reference = "https://attack.mitre.org/techniques/T1204/002/" diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml index 405cf25b306..acae70f730b 100644 --- a/rules/linux/defense_evasion_chattr_immutable_file.toml +++ b/rules/linux/defense_evasion_chattr_immutable_file.toml @@ -2,9 +2,7 @@ creation_date = "2022/07/22" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -20,6 +18,40 @@ language = "eql" license = "Elastic License v2" max_signals = 33 name = "File made Immutable by Chattr" +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 File made Immutable by Chattr + +The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args. +- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd. +- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious. +- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access. +- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files. +- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors. + +### False positive analysis + +- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule. +- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule. +- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts. +- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications. +- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only.""" risk_score = 47 rule_id = "968ccab9-da51-4a87-9ce2-d3c9782fd759" setup = """## Setup @@ -75,6 +107,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and process.parent.executable != null and process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and not ( @@ -85,55 +118,23 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n ) ) ''' -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 File made Immutable by Chattr - -The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse. - -### Possible investigation steps - -- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args. -- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd. -- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious. -- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access. -- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files. -- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors. - -### False positive analysis - -- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule. -- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule. -- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts. -- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names. - -### Response and remediation - -- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. -- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications. -- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed. -- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. -- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. -- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1222" name = "File and Directory Permissions Modification" reference = "https://attack.mitre.org/techniques/T1222/" - [[rule.threat.technique.subtechnique]] id = "T1222.002" name = "Linux and Mac File and Directory Permissions Modification" reference = "https://attack.mitre.org/techniques/T1222/002/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml index 9e4dc7450cc..35ce6af280c 100644 --- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml +++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml @@ -2,9 +2,7 @@ creation_date = "2023/10/24" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,50 @@ Monitors for the deletion of the kernel ring buffer events through dmesg. Attack to evade detection after installing a Linux kernel module (LKM). """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Attempt to Clear Kernel Ring Buffer" +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 Attempt to Clear Kernel Ring Buffer + +The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid. +- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised. +- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt. +- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise. +- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent. + +### False positive analysis + +- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command. +- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts. +- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts. +- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found. +- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. +- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`. +- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence.""" risk_score = 21 rule_id = "2724808c-ba5d-48b2-86d2-0002103df753" setup = """## Setup @@ -64,64 +102,33 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "dmesg" and process.args in ("-c", "--clear") ''' -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 Attempt to Clear Kernel Ring Buffer - -The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid. -- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised. -- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt. -- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise. -- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent. - -### False positive analysis - -- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command. -- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts. -- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts. -- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. -- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found. -- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. -- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`. -- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1070" name = "Indicator Removal" reference = "https://attack.mitre.org/techniques/T1070/" - [[rule.threat.technique.subtechnique]] id = "T1070.002" name = "Clear Linux or Mac System Logs" reference = "https://attack.mitre.org/techniques/T1070/002/" + [[rule.threat.technique]] id = "T1562" name = "Impair Defenses" reference = "https://attack.mitre.org/techniques/T1562/" - [[rule.threat.technique.subtechnique]] id = "T1562.001" name = "Disable or Modify Tools" reference = "https://attack.mitre.org/techniques/T1562/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml index 5e4687c75a5..874a3f33738 100644 --- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml +++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,30 +11,16 @@ Identify activity related where adversaries can add the 'hidden' flag to files t to evade detection. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.file*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Hidden Files and Directories via Hidden Flag" -risk_score = 21 -rule_id = "5124e65f-df97-4471-8dcb-8e3953b3ea97" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "OS: macOS", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Auditd Manager", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags" -''' note = """## Triage and analysis > **Disclaimer**: @@ -72,21 +56,44 @@ In Unix-like systems, the 'hidden' flag can be set on files to conceal them from - Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden flag, on critical systems. - Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. - Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.""" +risk_score = 21 +rule_id = "5124e65f-df97-4471-8dcb-8e3953b3ea97" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "OS: macOS", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags" +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1564" name = "Hide Artifacts" reference = "https://attack.mitre.org/techniques/T1564/" - [[rule.threat.technique.subtechnique]] id = "T1564.001" name = "Hidden Files and Directories" reference = "https://attack.mitre.org/techniques/T1564/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml index 819542e63f5..dda9951a020 100644 --- a/rules/linux/defense_evasion_directory_creation_in_bin.toml +++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/01" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,49 @@ files that are required for the system to function properly. The creation of dir attempt to hide malicious files or executables, as these /bin directories usually just contain binaries. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Directory Creation in /bin directory" +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 Directory Creation in /bin directory + +The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin. +- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one. +- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack. +- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level. +- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise. + +### False positive analysis + +- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm. +- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule. +- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts. +- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity. +- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts. +- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality. +- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture.""" risk_score = 21 rule_id = "3302835b-0049-4004-a325-660b1fba1f67" setup = """## Setup @@ -60,65 +97,32 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2", "exec_event") and process.name == "mkdir" and process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir") ''' -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 Directory Creation in /bin directory - -The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation. - -### Possible investigation steps - -- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin. -- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one. -- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior. -- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack. -- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level. -- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise. - -### False positive analysis - -- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm. -- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule. -- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts. -- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. -- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity. -- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts. -- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality. -- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time. -- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. -- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1564" name = "Hide Artifacts" reference = "https://attack.mitre.org/techniques/T1564/" - [[rule.threat.technique.subtechnique]] id = "T1564.001" name = "Hidden Files and Directories" reference = "https://attack.mitre.org/techniques/T1564/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -126,3 +130,4 @@ framework = "MITRE ATT&CK" id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml index 4ac7da81c95..3e5779689bb 100644 --- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml +++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/28" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,52 @@ fine-grained access control policies to restrict the actions and resources that access. Adversaries may disable security tools to avoid possible detection of their tools and activities. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Disabling of AppArmor" +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 Disabling of AppArmor + +AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses. + +### Possible investigation steps + +- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor. +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered. +- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security. +- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign. +- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways. + +### False positive analysis + +- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts. +- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts. +- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities. +- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. +- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls. +- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents.""" risk_score = 21 rule_id = "fac52c69-2646-4e79-89c0-fd7653461010" setup = """## Setup @@ -60,6 +100,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and @@ -70,56 +111,23 @@ process where host.os.type == "linux" and event.type == "start" and (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/") ) ''' -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 Disabling of AppArmor - -AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses. - -### Possible investigation steps - -- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor. -- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. -- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered. -- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security. -- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign. -- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways. - -### False positive analysis - -- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts. -- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts. -- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts. -- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities. -- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities. -- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. -- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. -- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls. -- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1562" name = "Impair Defenses" reference = "https://attack.mitre.org/techniques/T1562/" - [[rule.threat.technique.subtechnique]] id = "T1562.001" name = "Disable or Modify Tools" reference = "https://attack.mitre.org/techniques/T1562/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml index 3b3e6dd8c01..4baa2aed772 100644 --- a/rules/linux/defense_evasion_disable_selinux_attempt.toml +++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/22" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,51 @@ support access control policies. Adversaries may disable security tools to avoid activities. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Disabling of SELinux" +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 Disabling of SELinux + +SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'. +- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account. +- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes. +- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations. +- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators. +- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode. + +### False positive analysis + +- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts. +- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts. +- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode. +- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled. +- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence.""" risk_score = 47 rule_id = "eb9eb8ba-a983-41d9-9c93-a1c05112ca5e" setup = """## Setup @@ -78,40 +117,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "setenforce" and process.args == "0" ''' -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 Disabling of SELinux - -SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'. -- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account. -- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes. -- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations. -- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators. -- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode. - -### False positive analysis - -- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts. -- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts. -- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts. -- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode. -- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced. -- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled. -- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. -- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml index 49e13f752fe..b0adf07fbd7 100644 --- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml +++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml @@ -2,22 +2,54 @@ creation_date = "2024/08/28" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the creation or rename of the Doas configuration file on a Linux system. Adversaries may create -or modify the Doas configuration file to elevate privileges and execute commands as other users while attempting to -evade detection. +This rule detects the creation or rename of the Doas configuration file on a Linux system. Adversaries may create or +modify the Doas configuration file to elevate privileges and execute commands as other users while attempting to evade +detection. """ from = "now-9m" index = ["logs-endpoint.events.file*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Potential Defense Evasion via Doas" +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 Defense Evasion via Doas + +Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses. + +### Possible investigation steps + +- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query. +- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities. +- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions. +- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user. +- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts. +- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack. + +### False positive analysis + +- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates. +- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts. +- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list. +- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state. +- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations. +- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future.""" references = ["https://wiki.archlinux.org/title/Doas"] risk_score = 21 rule_id = "26a726d7-126e-4267-b43d-e9a70bfdee1e" @@ -59,58 +91,27 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf" ''' -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 Defense Evasion via Doas - -Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses. - -### Possible investigation steps - -- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query. -- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities. -- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions. -- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user. -- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts. -- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack. - -### False positive analysis - -- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates. -- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts. -- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list. -- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state. -- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations. -- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. -- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. -- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1548" name = "Abuse Elevation Control Mechanism" reference = "https://attack.mitre.org/techniques/T1548/" - [[rule.threat.technique.subtechnique]] id = "T1548.003" name = "Sudo and Sudo Caching" reference = "https://attack.mitre.org/techniques/T1548/003/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml index b7b54978b9c..17cba5afd88 100644 --- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml +++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml @@ -2,9 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -16,10 +14,52 @@ their presence in the touch command arguments may indicate that a threat actor i of VM-related files and configurations on the system. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "ESXI Timestomping using Touch Command" +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 ESXI Timestomping using Touch Command + +VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. +- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities. +- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor. + +### False positive analysis + +- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows. +- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives. +- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities. +- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations. +- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot. +- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited. +- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" references = [ "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/", ] @@ -71,41 +111,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") ''' -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 ESXI Timestomping using Touch Command - -VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". -- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. -- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities. -- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies. -- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise. -- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor. - -### False positive analysis - -- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. -- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. -- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows. -- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives. -- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files. -- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities. -- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations. -- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot. -- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited. -- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml index d7de9703aa8..7d4cbe31205 100644 --- a/rules/linux/defense_evasion_file_deletion_via_shred.toml +++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/27" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,49 @@ a network and how. Adversaries may remove these files over the course of an intr remove them at the end as part of the post-intrusion cleanup process. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "File Deletion via Shred" +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 File Deletion via Shred + +The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero". +- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user. +- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious. +- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications. +- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise. +- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security. + +### False positive analysis + +- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts. +- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts. +- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management. +- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration. +- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion. +- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary. +- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools. +- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users.""" risk_score = 21 rule_id = "a1329140-8de3-4445-9f87-908fb6d824f4" setup = """## Setup @@ -65,40 +102,6 @@ process where host.os.type == "linux" and event.type == "start" and process.name "-u", "--remove", "-z", "--zero" ) and not process.parent.name == "logrotate" ''' -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 File Deletion via Shred - -The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts. - -### Possible investigation steps - -- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero". -- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user. -- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious. -- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications. -- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise. -- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security. - -### False positive analysis - -- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts. -- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts. -- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management. -- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration. -- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion. -- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary. -- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools. -- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml index 13cf5d56690..e6d8181d9e1 100644 --- a/rules/linux/defense_evasion_hex_payload_execution.toml +++ b/rules/linux/defense_evasion_hex_payload_execution.toml @@ -2,21 +2,59 @@ creation_date = "2024/11/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate payloads -and evade detection mechanisms. +This rule detects potential hex payload execution on Linux systems. Adversaries may use hex encoding to obfuscate +payloads and evade detection mechanisms. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] +index = [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", + "endgame-*", +] language = "eql" license = "Elastic License v2" name = "Potential Hex Payload Execution" +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 Hex Payload Execution + +Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats. + +### Possible investigation steps + +- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities. +- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow. +- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised. +- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses. +- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further. +- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity. + +### False positive analysis + +- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule. +- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts. +- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious. +- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule. +- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potentially malicious payloads. +- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants. +- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" risk_score = 21 rule_id = "0c1e8fda-4f09-451e-bc77-a192b6cbfc32" setup = """## Setup @@ -59,6 +97,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -71,84 +110,50 @@ process where host.os.type == "linux" and event.type == "start" and (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*") ) ''' -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 Hex Payload Execution - -Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats. - -### Possible investigation steps -- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities. -- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow. -- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised. -- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses. -- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further. -- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity. - -### False positive analysis -- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule. -- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts. -- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious. -- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule. -- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded. +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1027" +name = "Obfuscated Files or Information" +reference = "https://attack.mitre.org/techniques/T1027/" -### Response and remediation +[[rule.threat.technique]] +id = "T1140" +name = "Deobfuscate/Decode Files or Information" +reference = "https://attack.mitre.org/techniques/T1140/" -- Isolate the affected system from the network to prevent further spread of potentially malicious payloads. -- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions. -- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants. -- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems. -- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. -- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" - [rule.threat.tactic] - name = "Defense Evasion" - id = "TA0005" - reference = "https://attack.mitre.org/tactics/TA0005/" - [[rule.threat.technique]] - name = "Obfuscated Files or Information" - id = "T1027" - reference = "https://attack.mitre.org/techniques/T1027/" +[[rule.threat.technique]] +id = "T1204" +name = "User Execution" +reference = "https://attack.mitre.org/techniques/T1204/" +[[rule.threat.technique.subtechnique]] +id = "T1204.002" +name = "Malicious File" +reference = "https://attack.mitre.org/techniques/T1204/002/" - [[rule.threat.technique]] - name = "Deobfuscate/Decode Files or Information" - id = "T1140" - reference = "https://attack.mitre.org/techniques/T1140/" -[[rule.threat]] -framework = "MITRE ATT&CK" - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" - - [[rule.threat.technique]] - id = "T1059" - name = "Command and Scripting Interpreter" - reference = "https://attack.mitre.org/techniques/T1059/" - - [[rule.threat.technique.subtechnique]] - name = "Unix Shell" - id = "T1059.004" - reference = "https://attack.mitre.org/techniques/T1059/004/" - - [[rule.threat.technique]] - name = "User Execution" - id = "T1204" - reference = "https://attack.mitre.org/techniques/T1204/" - - [[rule.threat.technique.subtechnique]] - name = "Malicious File" - id = "T1204.002" - reference = "https://attack.mitre.org/techniques/T1204/002/" +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml index 76312a85791..3af9e90529f 100644 --- a/rules/linux/defense_evasion_hidden_directory_creation.toml +++ b/rules/linux/defense_evasion_hidden_directory_creation.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/01" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,8 +13,8 @@ tools. """ false_positives = [ """ - Certain tools may create hidden temporary directories upon installation or as part of their normal - behavior. These events can be filtered by the process arguments, username, or process name values. + Certain tools may create hidden temporary directories upon installation or as part of their normal behavior. These + events can be filtered by the process arguments, username, or process name values. """, ] from = "now-9m" @@ -24,6 +22,41 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Hidden Directory Creation via Unusual Parent" +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 Hidden Directory Creation via Unusual Parent + +In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns. + +### Possible investigation steps + +- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location. +- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent. +- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection. +- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. +- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors. + +### False positive analysis + +- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise. +- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts. +- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities. +- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent. +- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations. +- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools. +- Restore any affected files or configurations from a known good backup to ensure system integrity. +- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.""" risk_score = 21 rule_id = "b15a15f2-becf-475d-aa69-45c9e0ff1c49" setup = """## Setup @@ -65,6 +98,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "exec_event") and process.name == "mkdir" and process.parent.executable like ( @@ -78,60 +112,25 @@ process.name == "mkdir" and process.parent.executable like ( ) ) ''' -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 Hidden Directory Creation via Unusual Parent - -In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns. - -### Possible investigation steps - -- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location. -- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent. -- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection. -- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp. -- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. -- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors. - -### False positive analysis - -- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise. -- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts. -- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities. -- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent. -- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively. -### Response and remediation - -- Isolate the affected system from the network to prevent further malicious activity and lateral movement. -- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations. -- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools. -- Restore any affected files or configurations from a known good backup to ensure system integrity. -- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. -- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1564" name = "Hide Artifacts" reference = "https://attack.mitre.org/techniques/T1564/" - [[rule.threat.technique.subtechnique]] id = "T1564.001" name = "Hidden Files and Directories" reference = "https://attack.mitre.org/techniques/T1564/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -139,3 +138,4 @@ framework = "MITRE ATT&CK" id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml index 82d386bd667..5bcb15995f5 100644 --- a/rules/linux/defense_evasion_hidden_shared_object.toml +++ b/rules/linux/defense_evasion_hidden_shared_object.toml @@ -2,9 +2,7 @@ creation_date = "2022/07/20" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,40 @@ language = "eql" license = "Elastic License v2" max_signals = 33 name = "Creation of Hidden Shared Object File" +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 Creation of Hidden Shared Object File + +Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename. +- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious. +- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation. +- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise. +- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities. +- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism. + +### False positive analysis + +- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows. +- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts. +- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening. +- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker. +- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts. +- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents.""" risk_score = 47 rule_id = "766d3f91-3f12-448c-b65f-20123e9e9e8c" setup = """## Setup @@ -79,40 +111,6 @@ query = ''' file where host.os.type == "linux" and event.type == "creation" and file.extension == "so" and file.name : ".*.so" and not process.name in ("dockerd", "azcopy", "podman") ''' -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 Creation of Hidden Shared Object File - -Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats. - -### Possible investigation steps - -- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename. -- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious. -- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation. -- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise. -- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities. -- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism. - -### False positive analysis - -- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows. -- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts. -- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening. -- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts. - -### Response and remediation - -- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. -- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker. -- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery. -- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts. -- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Implement enhanced monitoring and alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml index 065c84ee7ef..2e6368d9fc4 100644 --- a/rules/linux/defense_evasion_kernel_module_removal.toml +++ b/rules/linux/defense_evasion_kernel_module_removal.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/24" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -20,10 +18,50 @@ false_positives = [ """, ] from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Kernel Module Removal" +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 Kernel Module Removal + +Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics. + +### Possible investigation steps + +- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria. +- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics. +- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted. +- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening. +- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise. +- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact. +- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly.""" references = ["http://man7.org/linux/man-pages/man8/modprobe.8.html"] risk_score = 47 rule_id = "cd66a5af-e34b-4bb0-8931-57d0a043f2ef" @@ -66,6 +104,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -75,74 +114,40 @@ process where host.os.type == "linux" and event.type == "start" and ) and process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ''' -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 Kernel Module Removal - -Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics. - -### Possible investigation steps - -- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria. -- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated. -- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. -- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics. -- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted. -- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives. - -### False positive analysis - -- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. -- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. -- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening. -- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise. -- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. -- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments. -- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred. -- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact. -- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. -- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1562" name = "Impair Defenses" reference = "https://attack.mitre.org/techniques/T1562/" - [[rule.threat.technique.subtechnique]] id = "T1562.001" name = "Disable or Modify Tools" reference = "https://attack.mitre.org/techniques/T1562/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1547" name = "Boot or Logon Autostart Execution" reference = "https://attack.mitre.org/techniques/T1547/" - [[rule.threat.technique.subtechnique]] id = "T1547.006" name = "Kernel Modules and Extensions" reference = "https://attack.mitre.org/techniques/T1547/006/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml index 5047db3c552..6d36e1fdca9 100644 --- a/rules/linux/defense_evasion_kthreadd_masquerading.toml +++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml @@ -2,9 +2,7 @@ creation_date = "2024/02/01" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,49 @@ as kthreadd and kworker typically do not have process.executable fields associat hide their malicious programs by masquerading as legitimate kernel processes. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Executable Masquerading as Kernel Process" +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 Executable Masquerading as Kernel Process + +In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities. + +### Possible investigation steps + +- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious. +- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one. +- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service. +- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity. +- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise. +- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path. + +### False positive analysis + +- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified. +- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious. +- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process. +- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion. +- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation. +- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts. +- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" references = ["https://sandflysecurity.com/blog/linux-stealth-rootkit-malware-with-edr-evasion-analyzed/"] risk_score = 21 rule_id = "202829f6-0271-4e88-b882-11a655c590d4" @@ -66,40 +103,6 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name : ("kworker*", "kthread*") and process.executable != null ''' -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 Executable Masquerading as Kernel Process - -In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities. - -### Possible investigation steps - -- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious. -- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one. -- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service. -- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity. -- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise. -- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path. - -### False positive analysis - -- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified. -- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious. -- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process. -- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios. - -### Response and remediation - -- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. -- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert. -- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion. -- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation. -- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts. -- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml index fc677858c05..0614fe7bf30 100644 --- a/rules/linux/defense_evasion_ld_so_creation.toml +++ b/rules/linux/defense_evasion_ld_so_creation.toml @@ -2,9 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,6 +16,42 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg language = "eql" license = "Elastic License v2" name = "Dynamic Linker (ld.so) 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 Dynamic Linker (ld.so) Creation + +The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats. + +### Possible investigation steps + +- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file. +- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman". +- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64". +- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source. +- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities. +- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity. +- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system. + +### False positive analysis + +- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion. +- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives. +- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening. +- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations. +- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository. +- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes. +- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities.""" risk_score = 21 rule_id = "06d555e4-c8ce-4d90-90e1-ec7f66df5a6a" setup = """## Setup @@ -60,93 +94,58 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman") ''' -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 Dynamic Linker (ld.so) Creation - -The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats. - -### Possible investigation steps - -- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file. -- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman". -- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64". -- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source. -- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities. -- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity. -- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system. - -### False positive analysis - -- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion. -- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives. -- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening. -- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations. -- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. -- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository. -- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact. -- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes. -- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. -- Implement additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1218" +name = "System Binary Proxy Execution" +reference = "https://attack.mitre.org/techniques/T1218/" - [rule.threat.tactic] - name = "Defense Evasion" - id = "TA0005" - reference = "https://attack.mitre.org/tactics/TA0005/" - - [[rule.threat.technique]] - id = "T1218" - name = "System Binary Proxy Execution" - reference = "https://attack.mitre.org/techniques/T1218/" +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat.technique]] - id = "T1059" - name = "Command and Scripting Interpreter" - reference = "https://attack.mitre.org/techniques/T1059/" - - [[rule.threat.technique.subtechnique]] - name = "Unix Shell" - id = "T1059.004" - reference = "https://attack.mitre.org/techniques/T1059/004/" +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1574" +name = "Hijack Execution Flow" +reference = "https://attack.mitre.org/techniques/T1574/" +[[rule.threat.technique.subtechnique]] +id = "T1574.006" +name = "Dynamic Linker Hijacking" +reference = "https://attack.mitre.org/techniques/T1574/006/" + - [rule.threat.tactic] - name = "Persistence" - id = "TA0003" - reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat.technique]] - name = "Hijack Execution Flow" - id = "T1574" - reference = "https://attack.mitre.org/techniques/T1574/" +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat.technique.subtechnique]] - name = "Dynamic Linker Hijacking" - id = "T1574.006" - reference = "https://attack.mitre.org/techniques/T1574/006/" diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml index 814aee33818..af7b10504f1 100644 --- a/rules/linux/defense_evasion_log_files_deleted.toml +++ b/rules/linux/defense_evasion_log_files_deleted.toml @@ -2,9 +2,7 @@ creation_date = "2020/11/03" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -min_stack_version = "8.13.0" -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,41 @@ index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.file*", "logs-sentine language = "eql" license = "Elastic License v2" name = "System Log File Deletion" +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 System Log File Deletion + +System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions. + +### Possible investigation steps + +- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert. +- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity. +- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available. +- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised. +- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise. +- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file. + +### False positive analysis + +- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule. +- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening. +- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts. +- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature. +- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity. +- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies. +- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future.""" references = [ "https://www.fireeye.com/blog/threat-research/2020/11/live-off-the-land-an-overview-of-unc1945.html", "https://www.elastic.co/security-labs/detecting-log4j2-with-elastic-security", @@ -96,41 +129,6 @@ file where host.os.type == "linux" and event.type == "deletion" and ) and not process.name in ("gzip", "executor", "dockerd") ''' -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 System Log File Deletion - -System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions. - -### Possible investigation steps - -- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert. -- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity. -- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available. -- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised. -- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise. -- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file. - -### False positive analysis - -- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule. -- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening. -- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts. -- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature. -- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering. -- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. -- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity. -- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities. -- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. -- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies. -- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml index b1b3758bffa..e410da79cdb 100644 --- a/rules/linux/defense_evasion_mount_execution.toml +++ b/rules/linux/defense_evasion_mount_execution.toml @@ -2,9 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,10 +16,51 @@ hidepid option all the user has to do is remount the /proc filesystem with the o detected. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Hidden Process via Mount Hidepid" +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 Hidden Process via Mount Hidepid + +The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'. +- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary. +- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script. +- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert. +- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'. +- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert. + +### False positive analysis + +- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs. +- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist. +- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection. +- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts. +- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes. +- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed. +- Terminate any identified malicious processes and remove any associated files or scripts from the system. +- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response.""" references = ["https://www.cyberciti.biz/faq/linux-hide-processes-from-other-users/"] risk_score = 47 rule_id = "dc71c186-9fe4-4437-a4d0-85ebb32b8204" @@ -64,57 +103,25 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "executed", "process_started") and process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and not process.parent.command_line like "/opt/cloudlinux/*" ''' -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 Hidden Process via Mount Hidepid -The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation. - -### Possible investigation steps - -- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'. -- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary. -- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script. -- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert. -- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'. -- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert. - -### False positive analysis - -- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs. -- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist. -- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection. -- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts. -- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. -- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes. -- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed. -- Terminate any identified malicious processes and remove any associated files or scripts from the system. -- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Implement enhanced monitoring and alerting for future attempts to use the 'hidepid' option, ensuring rapid detection and response.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1564" name = "Hide Artifacts" reference = "https://attack.mitre.org/techniques/T1564/" + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml index 40d530a9378..81f8afa2c99 100644 --- a/rules/linux/defense_evasion_potential_proot_exploits.toml +++ b/rules/linux/defense_evasion_potential_proot_exploits.toml @@ -2,9 +2,7 @@ creation_date = "2023/03/07" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -20,10 +18,48 @@ malicious payload or elevate privileges or perform network scans or orchestrate Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Defense Evasion via PRoot" +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 Defense Evasion via PRoot + +PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent. +- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed. +- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise. +- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent. +- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe. + +### False positive analysis + +- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes. +- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts. +- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope. +- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections. + +### Response and remediation + +- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources. +- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes. +- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot. +- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" references = ["https://proot-me.github.io/"] risk_score = 47 rule_id = "5c9ec990-37fa-4d5c-abfc-8d432f3dedd0" @@ -71,39 +107,6 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name == "proot" ''' -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 Defense Evasion via PRoot - -PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion. - -### Possible investigation steps - -- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent. -- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed. -- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise. -- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent. -- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe. - -### False positive analysis - -- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes. -- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts. -- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope. -- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections. - -### Response and remediation - -- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources. -- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes. -- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot. -- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise. -- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. -- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process. -- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml index cb8237b8ef3..4b24678e171 100644 --- a/rules/linux/defense_evasion_root_certificate_installation.toml +++ b/rules/linux/defense_evasion_root_certificate_installation.toml @@ -2,9 +2,7 @@ creation_date = "2024/08/28" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/24" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -12,14 +10,52 @@ description = """ This rule detects the installation of root certificates on a Linux system. Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to their command and control servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the -system or application will trust certificates in the root's chain of trust that have been signed by the root certificate. +system or application will trust certificates in the root's chain of trust that have been signed by the root +certificate. """ from = "now-9m" index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] language = "eql" license = "Elastic License v2" name = "Root Certificate Installation" -references = ["https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1553.004/T1553.004.md"] +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 Root Certificate Installation + +Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities. + +### Possible investigation steps + +- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event". +- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*". +- Investigate the user account associated with the process to determine if it is a known or expected user for such operations. +- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert. +- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host. +- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic. + +### False positive analysis + +- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list. +- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria. +- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts. +- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations. +- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers. +- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network.""" +references = [ + "https://github.com/redcanaryco/atomic-red-team/blob/f339e7da7d05f6057fdfcdd3742bfcf365fee2a9/atomics/T1553.004/T1553.004.md", +] risk_score = 47 rule_id = "6ded0996-7d4b-40f2-bf4a-6913e7591795" setup = """## Setup @@ -60,6 +96,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and process.name in ("update-ca-trust", "update-ca-certificates") and not ( @@ -71,56 +108,23 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not ( (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e") ) ''' -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 Root Certificate Installation - -Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities. - -### Possible investigation steps - -- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event". -- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*". -- Investigate the user account associated with the process to determine if it is a known or expected user for such operations. -- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert. -- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host. -- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic. - -### False positive analysis - -- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list. -- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria. -- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts. -- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations. -- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations. - -### Response and remediation - -- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers. -- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain. -- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary. -- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated. -- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary. -- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management. -- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1553" name = "Subvert Trust Controls" reference = "https://attack.mitre.org/techniques/T1553/" - [[rule.threat.technique.subtechnique]] id = "T1553.004" name = "Install Root Certificate" reference = "https://attack.mitre.org/techniques/T1553/004/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml index da071c01019..22da9958272 100644 --- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml +++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml @@ -2,9 +2,7 @@ creation_date = "2024/08/28" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,40 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg language = "eql" license = "Elastic License v2" name = "SSL Certificate Deletion" +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 SSL Certificate Deletion +SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt". +- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious. +- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access. +- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise. +- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships. +- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions. + +### False positive analysis + +- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions. +- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts. +- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious. +- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring. +- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or damage. +- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files. +- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls. +- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities. +- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates.""" risk_score = 21 rule_id = "7957f3b9-f590-4062-b9f9-003c32bfc7d6" setup = """## Setup @@ -58,77 +90,45 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "deletion" and file.path : "/etc/ssl/certs/*" and file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman") ''' -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 SSL Certificate Deletion -SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity. - -### Possible investigation steps - -- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt". -- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious. -- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access. -- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise. -- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships. -- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions. - -### False positive analysis - -- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions. -- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts. -- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious. -- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring. -- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure. -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or damage. -- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files. -- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls. -- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities. -- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1070" name = "Indicator Removal" reference = "https://attack.mitre.org/techniques/T1070/" - [[rule.threat.technique.subtechnique]] id = "T1070.004" name = "File Deletion" reference = "https://attack.mitre.org/techniques/T1070/004/" + [[rule.threat.technique]] id = "T1553" name = "Subvert Trust Controls" reference = "https://attack.mitre.org/techniques/T1553/" + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1485" name = "Data Destruction" reference = "https://attack.mitre.org/techniques/T1485/" + [rule.threat.tactic] id = "TA0040" name = "Impact" reference = "https://attack.mitre.org/tactics/TA0040/" + diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml index 244d0e21321..906fb674111 100644 --- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml +++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,34 +12,15 @@ directly, the commands will be executed in the background via its parent process to execute commands while attempting to evade detection. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potentially Suspicious Process Started via tmux or screen" -risk_score = 21 -rule_id = "e0cc3807-e108-483c-bf66-5a4fbe0d7e89" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -process where host.os.type == "linux" and event.type == "start" and - event.action in ("exec", "exec_event", "start", "ProcessRollup2") and - process.parent.name in ("screen", "tmux") and process.name like ( - "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*", - "openssl", "telnet", "wget", "curl", "id" - ) -''' note = """## Triage and analysis > **Disclaimer**: @@ -76,16 +55,43 @@ Tmux and screen are terminal multiplexers that allow users to manage multiple te - Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. - Implement network monitoring to detect any unusual outbound connections or data exfiltration attempts from the affected host. - Update and enhance detection rules to include additional suspicious command patterns or behaviors observed during the investigation.""" +risk_score = 21 +rule_id = "e0cc3807-e108-483c-bf66-5a4fbe0d7e89" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and + process.parent.name in ("screen", "tmux") and process.name like ( + "nmap", "nc", "ncat", "netcat", "socat", "nc.openbsd", "ngrok", "ping", "java", "php*", "perl", "ruby", "lua*", + "openssl", "telnet", "wget", "curl", "id" + ) +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1218" name = "System Binary Proxy Execution" reference = "https://attack.mitre.org/techniques/T1218/" + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/discovery_docker_socket_discovery.toml b/rules/linux/discovery_docker_socket_discovery.toml index afd35769dd8..bf00ef7c0d9 100644 --- a/rules/linux/discovery_docker_socket_discovery.toml +++ b/rules/linux/discovery_docker_socket_discovery.toml @@ -2,21 +2,26 @@ creation_date = "2025/03/04" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/03/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with -the Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to -interact with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing -containers. Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate -privileges, or move laterally within the environment. +This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the +Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact +with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers. +Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or +move laterally within the environment. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Docker Socket Enumeration" @@ -58,10 +63,11 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Auditd Manager", "Data Source: Crowdstrike", - "Data Source: SentinelOne" + "Data Source: SentinelOne", ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and @@ -69,15 +75,17 @@ process.name in ("curl", "socat", "nc", "netcat", "ncat", "nc.traditional") and process.command_line like ("*/var/run/docker.sock*", "*/run/docker.sock*") ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1613" name = "Container and Resource Discovery" reference = "https://attack.mitre.org/techniques/T1613/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml index 5630ad2483e..dc05592fcc1 100644 --- a/rules/linux/discovery_dynamic_linker_via_od.toml +++ b/rules/linux/discovery_dynamic_linker_via_od.toml @@ -2,9 +2,7 @@ creation_date = "2024/02/01" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,50 @@ for examining and debugging binary files or data streams. Attackers can leverage identifying injection points and craft exploits based on the observed behaviors and structures within these files. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Suspicious Dynamic Linker Discovery via od" +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 Dynamic Linker Discovery via od + +The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files. +- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs. +- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign. + +### False positive analysis + +- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities. +- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts. +- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives. +- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files. +- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity. +- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign. +- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files.""" references = ["https://github.com/arget13/DDexec"] risk_score = 21 rule_id = "0369e8a6-0fa7-4e7a-961a-53180a4c966e" @@ -71,39 +109,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2" ) ''' -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 Dynamic Linker Discovery via od - -The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt. - -### Possible investigation steps - -- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query. -- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous. -- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files. -- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs. -- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign. - -### False positive analysis - -- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities. -- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts. -- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives. -- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. -- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts. -- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files. -- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity. -- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign. -- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files.""" [[rule.threat]] diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml index eae69d1e367..aebf5e78d38 100644 --- a/rules/linux/discovery_esxi_software_via_find.toml +++ b/rules/linux/discovery_esxi_software_via_find.toml @@ -2,9 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,50 @@ software, and their presence in the find command arguments may indicate that a t analyze, or manipulate VM-related files and configurations on the system. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "ESXI Discovery via Find" +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 ESXI Discovery via Find + +VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*". +- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process. +- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks. +- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns. +- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system. +- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings. + +### False positive analysis + +- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks. +- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule. +- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts. +- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities. +- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files. +- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity. +- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities. +- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" references = [ "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/", ] @@ -63,56 +101,25 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "executed", "process_started") and process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh" ''' -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 ESXI Discovery via Find - -VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities. - -### Possible investigation steps - -- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*". -- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process. -- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks. -- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns. -- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system. -- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings. - -### False positive analysis -- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks. -- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule. -- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts. -- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities. -- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files. -- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity. -- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities. -- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1518" name = "Software Discovery" reference = "https://attack.mitre.org/techniques/T1518/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml index 063a4e64759..d15c6a2b9f5 100644 --- a/rules/linux/discovery_esxi_software_via_grep.toml +++ b/rules/linux/discovery_esxi_software_via_grep.toml @@ -2,9 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,49 @@ related to virtual machine (VM) files, such as "vmdk", "vmx", "vmxf", "vmsd", "v may indicate that a threat actor is attempting to search for, analyze, or manipulate VM files on the system. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "ESXI Discovery via Grep" +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 ESXI Discovery via Grep + +In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". +- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init". +- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous. +- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host. +- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity. + +### False positive analysis + +- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts. +- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts. +- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities. +- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule. + +### Response and remediation + +- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions. +- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files. +- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity. +- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats.""" references = [ "https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/", ] @@ -63,6 +100,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "executed", "process_started") and @@ -70,49 +108,18 @@ process where host.os.type == "linux" and event.type == "start" and process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init" ''' -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 ESXI Discovery via Grep - -In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns. - -### Possible investigation steps -- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". -- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init". -- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous. -- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host. -- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity. - -### False positive analysis - -- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts. -- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts. -- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities. -- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule. - -### Response and remediation - -- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions. -- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files. -- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity. -- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1518" name = "Software Discovery" reference = "https://attack.mitre.org/techniques/T1518/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml index df98c5ebf3d..13cafc9195f 100644 --- a/rules/linux/discovery_linux_hping_activity.toml +++ b/rules/linux/discovery_linux_hping_activity.toml @@ -2,9 +2,7 @@ creation_date = "2020/02/18" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,10 +17,52 @@ false_positives = [ """, ] from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Hping Process Activity" +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 Hping Process Activity + +Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics. + +### Possible investigation steps + +- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3". +- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user. +- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities. +- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous. +- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization. +- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns. +- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation. + +### False positive analysis + +- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits. +- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule. +- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles. +- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities. +- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping. +- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files. +- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats.""" references = ["https://en.wikipedia.org/wiki/Hping"] risk_score = 47 rule_id = "90169566-2260-4824-b8e4-8615c3b4ed52" @@ -84,41 +124,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name in ("hping", "hping2", "hping3") ''' -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 Hping Process Activity - -Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics. - -### Possible investigation steps - -- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3". -- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user. -- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities. -- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous. -- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization. -- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns. -- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation. - -### False positive analysis - -- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits. -- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule. -- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles. -- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems. - -### Response and remediation - -- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary. -- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities. -- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping. -- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files. -- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats.""" [[rule.threat]] diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml index 760afd3f369..0e020284684 100644 --- a/rules/linux/discovery_linux_nping_activity.toml +++ b/rules/linux/discovery_linux_nping_activity.toml @@ -2,9 +2,7 @@ creation_date = "2020/02/18" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,10 +17,52 @@ false_positives = [ """, ] from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Nping Process Activity" +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 Nping Process Activity + +Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities. + +### Possible investigation steps + +- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping". +- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns. +- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types. +- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns. +- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed. +- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns. + +### False positive analysis + +- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing. +- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes. +- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests. +- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments. +- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks. +- Terminate the Nping process on the affected host to stop any ongoing malicious activity. +- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts. +- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms. +- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only. +- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign. +- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools.""" references = ["https://en.wikipedia.org/wiki/Nmap"] risk_score = 47 rule_id = "0d69150b-96f8-467c-a86d-a67a3378ce77" @@ -84,41 +124,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "nping" ''' -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 Nping Process Activity - -Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities. - -### Possible investigation steps - -- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping". -- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns. -- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types. -- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns. -- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed. -- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns. - -### False positive analysis - -- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing. -- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes. -- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests. -- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments. -- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration. - -### Response and remediation - -- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks. -- Terminate the Nping process on the affected host to stop any ongoing malicious activity. -- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts. -- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms. -- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only. -- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign. -- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools.""" [[rule.threat]] diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml index a14fb277651..694412a51eb 100644 --- a/rules/linux/discovery_pam_version_discovery.toml +++ b/rules/linux/discovery_pam_version_discovery.toml @@ -2,9 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,49 @@ This rule detects PAM version discovery activity on Linux systems. PAM version d attacker attempting to backdoor the authentication process through malicious PAM modules. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Pluggable Authentication Module (PAM) Version Discovery" +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 Pluggable Authentication Module (PAM) Version Discovery + +Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam". +- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior. +- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts. +- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts. +- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context. +- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts. +- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods. +- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM. +- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future.""" references = [ "https://www.group-ib.com/blog/pluggable-authentication-module/", "https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/", @@ -64,6 +101,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name != null and @@ -73,76 +111,42 @@ process where host.os.type == "linux" and event.type == "start" and ) and not process.parent.name in ("dcservice", "inspectorssmplugin") ''' -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 Pluggable Authentication Module (PAM) Version Discovery - -Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats. - -### Possible investigation steps - -- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam". -- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised. -- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior. -- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts. -- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities. - -### False positive analysis -- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts. -- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context. -- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts. -- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods. -- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives. - -### Response and remediation - -- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM. -- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications. -- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process. -- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1556" name = "Modify Authentication Process" reference = "https://attack.mitre.org/techniques/T1556/" + [rule.threat.tactic] id = "TA0006" name = "Credential Access" reference = "https://attack.mitre.org/tactics/TA0006/" + diff --git a/rules/linux/discovery_polkit_version_discovery.toml b/rules/linux/discovery_polkit_version_discovery.toml index 0a2202d69cc..2f24ec30aef 100644 --- a/rules/linux/discovery_polkit_version_discovery.toml +++ b/rules/linux/discovery_polkit_version_discovery.toml @@ -2,21 +2,57 @@ creation_date = "2025/01/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an -indication of an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. +This rule detects Polkit version discovery activity on Linux systems. Polkit version discovery can be an indication of +an attacker attempting to exploit misconfigurations or vulnerabilities in the Polkit service. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Polkit Version Discovery" +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 Polkit Version Discovery + +Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers. + +### Possible investigation steps + +- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target. +- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities. +- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous. + +### False positive analysis + +- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions. +- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments. +- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands. +- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities. +- Apply any available security patches or updates to the Polkit service to address known vulnerabilities. +- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats.""" risk_score = 21 rule_id = "ca3bcacc-9285-4452-a742-5dae77538f61" setup = """## Setup @@ -54,6 +90,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( @@ -63,49 +100,18 @@ event.action in ("exec", "exec_event", "start", "ProcessRollup2") and ( (process.name == "pkaction" and process.args == "--version") ) ''' -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 Polkit Version Discovery - -Polkit, a system service in Linux, manages system-wide privileges, enabling non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by discovering its version to identify vulnerabilities or misconfigurations. The detection rule identifies suspicious activities by monitoring specific command executions related to Polkit version checks, signaling potential reconnaissance efforts by attackers. - -### Possible investigation steps -- Review the process execution details to confirm the command used for Polkit version discovery, focusing on the process name and arguments such as "dnf", "rpm", "apt", or "pkaction". -- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. -- Investigate the host from which the command was executed to assess if it has a history of suspicious activities or if it is a high-value target. -- Correlate the event with other logs or alerts to identify if there are additional indicators of compromise or related reconnaissance activities. -- Evaluate the necessity and frequency of Polkit version checks in the environment to determine if this behavior is expected or anomalous. - -### False positive analysis - -- Routine system updates or package management activities may trigger the rule when administrators use package managers like dnf, rpm, or apt to check for updates or verify installed packages. To mitigate this, create exceptions for known administrative scripts or user accounts that regularly perform these actions. -- Automated system monitoring tools that check software versions for compliance or inventory purposes might also cause false positives. Identify these tools and exclude their processes from triggering the rule. -- Developers or system administrators testing Polkit configurations or updates might execute version checks as part of their workflow. Consider excluding specific user accounts or process paths associated with development and testing environments. -- Security audits or vulnerability assessments conducted by internal teams may involve version checks as part of their procedures. Coordinate with these teams to whitelist their activities during scheduled assessments. - -### Response and remediation - -- Isolate the affected system from the network to prevent potential lateral movement by the attacker. -- Terminate any suspicious processes identified in the alert, such as those involving the execution of Polkit version discovery commands. -- Conduct a thorough review of system logs and command history to identify any unauthorized access or further malicious activities. -- Apply any available security patches or updates to the Polkit service to address known vulnerabilities. -- Implement stricter access controls and monitoring on systems running Polkit to prevent unauthorized version checks and other reconnaissance activities. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Enhance detection capabilities by configuring alerts for similar reconnaissance activities across the network to ensure early detection of potential threats.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml b/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml index 015364f3148..1cad26026a2 100644 --- a/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml +++ b/rules/linux/discovery_port_scanning_activity_from_compromised_host.toml @@ -2,21 +2,17 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/03/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects potential port scanning activity from a compromised host. Port scanning is a -common reconnaissance technique used by attackers to identify open ports and services on a target -system. A compromised host may exhibit port scanning behavior when an attacker is attempting to -map out the network topology, identify vulnerable services, or prepare for further exploitation. -This rule identifies potential port scanning activity by monitoring network connection attempts -from a single host to a large number of ports within a short time frame. ES|QL rules have limited -fields available in its alert documents. Make sure to review the original documents to aid in the -investigation of this alert. +This rule detects potential port scanning activity from a compromised host. Port scanning is a common reconnaissance +technique used by attackers to identify open ports and services on a target system. A compromised host may exhibit port +scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable services, or +prepare for further exploitation. This rule identifies potential port scanning activity by monitoring network connection +attempts from a single host to a large number of ports within a short time frame. ES|QL rules have limited fields +available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -60,6 +56,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.network-* | keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id @@ -71,15 +68,17 @@ from logs-endpoint.events.network-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1046" name = "Network Service Discovery" reference = "https://attack.mitre.org/techniques/T1046/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml index 356264921ae..d9d0f29ef75 100644 --- a/rules/linux/discovery_private_key_password_searching_activity.toml +++ b/rules/linux/discovery_private_key_password_searching_activity.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,49 @@ This rule detects private key searching activity on Linux systems. Searching for attacker attempting to escalate privileges or exfiltrate sensitive information. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Private Key Searching Activity" +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 Private Key Searching Activity + +In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access. + +### Possible investigation steps + +- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/". +- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise. +- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action. +- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation. +- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign. + +### False positive analysis + +- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions. +- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs. +- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits. +- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts. +- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys. +- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts. +- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored. +- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files.""" risk_score = 21 rule_id = "627374ab-7080-4e4d-8316-bef1122444af" setup = """## Setup @@ -46,58 +83,26 @@ For more details on Elastic Defend refer to the [helper guide](https://www.elast """ severity = "low" tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Data Source: Elastic Endgame", - "Resources: Investigation Guide" - ] + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", +] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "find" and process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/") ''' -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 Private Key Searching Activity - -In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access. - -### Possible investigation steps - -- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/". -- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise. -- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action. -- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation. -- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign. - -### False positive analysis -- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions. -- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs. -- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits. -- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts. -- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys. -- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts. -- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored. -- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files.""" [[rule.threat]] framework = "MITRE ATT&CK" @@ -106,3 +111,4 @@ framework = "MITRE ATT&CK" id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml index e345c1f4c8a..b49aec9feda 100644 --- a/rules/linux/discovery_security_file_access_via_common_utility.toml +++ b/rules/linux/discovery_security_file_access_via_common_utility.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,50 @@ This rule detects sensitive security file access via common utilities on Linux s from sensitive files using common utilities to gather information about the system and its security configuration. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Security File Access via Common Utilities" +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 Security File Access via Common Utilities + +In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields. +- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account. +- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity. +- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts. +- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt. +- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation. + +### False positive analysis + +- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations. +- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection. +- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities. +- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered. +- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access. +- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network. +- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents.""" risk_score = 21 rule_id = "7efca3ad-a348-43b2-b544-c93a78a0ef92" setup = """## Setup @@ -46,18 +84,19 @@ For more details on Elastic Defend refer to the [helper guide](https://www.elast """ severity = "low" tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Data Source: Elastic Endgame", - "Resources: Investigation Guide" - ] + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Data Source: Elastic Endgame", + "Resources: Investigation Guide", +] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -71,41 +110,7 @@ process where host.os.type == "linux" and event.type == "start" and ) and not process.parent.name in ("wazuh-modulesd", "lynis") ''' -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 Security File Access via Common Utilities - -In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities. - -### Possible investigation steps -- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields. -- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account. -- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity. -- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts. -- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt. -- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation. - -### False positive analysis - -- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. -- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. -- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations. -- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection. -- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities. -- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered. -- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access. -- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes. -- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network. -- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" @@ -114,3 +119,4 @@ framework = "MITRE ATT&CK" id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml b/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml index 57a551f9534..dc71de29750 100644 --- a/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml +++ b/rules/linux/discovery_subnet_scanning_activity_from_compromised_host.toml @@ -2,21 +2,17 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/03/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is -a common reconnaissance technique used by attackers to identify live hosts within a network range. -A compromised host may exhibit subnet scanning behavior when an attacker is attempting to map out -the network topology, identify vulnerable hosts, or prepare for further exploitation. This rule -identifies potential subnet scanning activity by monitoring network connection attempts from a -single host to a large number of hosts within a short time frame. ES|QL rules have limited fields -available in its alert documents. Make sure to review the original documents to aid in the -investigation of this alert. +This rule detects potential subnet scanning activity from a compromised host. Subnet scanning is a common reconnaissance +technique used by attackers to identify live hosts within a network range. A compromised host may exhibit subnet +scanning behavior when an attacker is attempting to map out the network topology, identify vulnerable hosts, or prepare +for further exploitation. This rule identifies potential subnet scanning activity by monitoring network connection +attempts from a single host to a large number of hosts within a short time frame. ES|QL rules have limited fields +available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -60,6 +56,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.network-* | keep @timestamp, host.os.type, event.type, event.action, process.executable, destination.ip, agent.id @@ -71,15 +68,17 @@ from logs-endpoint.events.network-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1046" name = "Network Service Discovery" reference = "https://attack.mitre.org/techniques/T1046/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml index fe6b11cc968..9c5015f5db1 100644 --- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml +++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/30" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,48 @@ the invoking user. Attackers may execute this command to enumerate commands allo permissions, potentially allowing to escalate privileges to root. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Sudo Command Enumeration Detected" +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 Sudo Command Enumeration Detected + +The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2. +- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish". +- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious. +- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications. +- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts. + +### False positive analysis + +- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use. +- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule. +- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software. +- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state. +- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations. +- Reset the password of the user account involved in the alert to prevent further unauthorized access. +- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities.""" risk_score = 21 rule_id = "28d39238-0c01-420a-b77a-24e5a7378663" setup = """## Setup @@ -59,55 +95,25 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "sudo" and process.args == "-l" and process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not process.args == "dpkg" ''' -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 Sudo Command Enumeration Detected - -The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation. - -### Possible investigation steps -- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2. -- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish". -- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious. -- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications. -- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts. - -### False positive analysis - -- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use. -- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule. -- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software. -- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. -- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state. -- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations. -- Reset the password of the user account involved in the alert to prevent further unauthorized access. -- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. -- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1033" name = "System Owner/User Discovery" reference = "https://attack.mitre.org/techniques/T1033/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml index e9520b48079..b54e11128bc 100644 --- a/rules/linux/discovery_suspicious_memory_grep_activity.toml +++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml @@ -2,9 +2,7 @@ creation_date = "2024/02/05" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,32 +12,15 @@ specific process, detailing the memory segments, permissions, and what files are read a process's memory map to identify memory addresses for code injection or process hijacking. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Suspicious Memory grep Activity" -references = ["https://github.com/arget13/DDexec"] -risk_score = 21 -rule_id = "d74d6506-427a-4790-b170-0c2a6ddac799" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -process where host.os.type == "linux" and event.type == "start" and - event.action in ("exec", "exec_event", "start", "ProcessRollup2") and - process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]") -''' note = """## Triage and analysis > **Disclaimer**: @@ -75,16 +56,41 @@ In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for - Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks. - Implement stricter access controls and monitoring on sensitive files and directories, such as `/proc/*/maps`, to prevent unauthorized access. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" +references = ["https://github.com/arget13/DDexec"] +risk_score = 21 +rule_id = "d74d6506-427a-4790-b170-0c2a6ddac799" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2") and + process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]") +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1057" name = "Process Discovery" reference = "https://attack.mitre.org/techniques/T1057/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml index 92116188fab..732545b5d3b 100644 --- a/rules/linux/discovery_suspicious_which_command_execution.toml +++ b/rules/linux/discovery_suspicious_which_command_execution.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/30" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,35 +16,6 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Suspicious which Enumeration" -risk_score = 21 -rule_id = "5b18eef4-842c-4b47-970f-f08d24004bde" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Discovery", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -process where host.os.type == "linux" and event.type == "start" and - event.action in ("exec", "exec_event", "start") and - process.name == "which" and process.args_count >= 10 and not ( - process.parent.name == "jem" or - process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or - process.args == "--tty-only" - ) - -/* potential tuning if rule would turn out to be noisy -and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and -process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") -*/ -''' note = """## Triage and analysis > **Disclaimer**: @@ -81,16 +50,48 @@ The `which` command in Linux environments is typically used to locate the execut - Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. - Implement enhanced monitoring and logging for the `which` command and similar enumeration tools to detect future misuse. - Review and update access controls and permissions to ensure that only authorized users have the ability to execute potentially sensitive commands and utilities.""" +risk_score = 21 +rule_id = "5b18eef4-842c-4b47-970f-f08d24004bde" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start") and + process.name == "which" and process.args_count >= 10 and not ( + process.parent.name == "jem" or + process.parent.executable like ("/vz/root/*", "/var/lib/docker/*") or + process.args == "--tty-only" + ) + +/* potential tuning if rule would turn out to be noisy +and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g++", "socat") and +process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") +*/ +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1082" name = "System Information Discovery" reference = "https://attack.mitre.org/techniques/T1082/" + [rule.threat.tactic] id = "TA0007" name = "Discovery" reference = "https://attack.mitre.org/tactics/TA0007/" + diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml index d0829ba736a..b43625cf4a5 100644 --- a/rules/linux/discovery_yum_dnf_plugin_detection.toml +++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml @@ -2,9 +2,7 @@ creation_date = "2024/06/25" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,48 @@ to search for YUM/DNF configurations and/or plugins with an enabled state. This attempting to establish persistence in a YUM or DNF plugin. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Yum/DNF Plugin Status Discovery" +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 Yum/DNF Plugin Status Discovery + +Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy. +- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. +- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity. +- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity. + +### False positive analysis + +- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks. +- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits. +- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities. +- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations. +- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`. +- Restore any altered plugin configurations from a known good backup to ensure system integrity. +- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access.""" references = [ "https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb", "https://pwnshift.github.io/2020/10/01/persistence.html", @@ -69,39 +105,6 @@ process where host.os.type == "linux" and event.type == "start" and "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf" ) ''' -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 Yum/DNF Plugin Status Discovery - -Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy. -- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. -- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity. -- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications. -- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity. - -### False positive analysis - -- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks. -- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits. -- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities. -- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. -- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations. -- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`. -- Restore any altered plugin configurations from a known good backup to ensure system integrity. -- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. -- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access.""" [[rule.threat]] diff --git a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml index 75fb1e6c1b5..9378a392cbb 100644 --- a/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml +++ b/rules/linux/execution_cupsd_foomatic_rip_file_creation.toml @@ -2,9 +2,7 @@ creation_date = "2024/09/27" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -110,6 +108,7 @@ tags = [ "Resources: Investigation Guide", ] type = "eql" + query = ''' sequence by host.id with maxspan=10s [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and @@ -119,15 +118,17 @@ sequence by host.id with maxspan=10s not (process.name == "gs" and file.path like "/tmp/gs_*")] by process.parent.entity_id ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1203" name = "Exploitation for Client Execution" reference = "https://attack.mitre.org/techniques/T1203/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml index 2a9e3882054..9a89825b302 100644 --- a/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml +++ b/rules/linux/execution_cupsd_foomatic_rip_shell_execution.toml @@ -2,21 +2,24 @@ creation_date = "2024/09/27" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This detection rule addresses multiple vulnerabilities in the CUPS printing system, including CVE-2024-47176, -CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the foomatic-rip -parent process. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, allowing -remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or network -spoofing. This can result in arbitrary command execution when a print job is initiated. +CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. Specifically, this rule detects shell executions from the +foomatic-rip parent process. These flaws impact components like cups-browsed, libcupsfilters, libppd, and foomatic-rip, +allowing remote unauthenticated attackers to manipulate IPP URLs or inject malicious data through crafted UDP packets or +network spoofing. This can result in arbitrary command execution when a print job is initiated. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Cupsd or Foomatic-rip Shell Execution" @@ -113,6 +116,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name == "foomatic-rip" and @@ -125,15 +129,17 @@ process where host.os.type == "linux" and event.type == "start" and ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1203" name = "Exploitation for Client Execution" reference = "https://attack.mitre.org/techniques/T1203/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml b/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml index baff7f2d5ac..21393246708 100644 --- a/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml +++ b/rules/linux/execution_cupsd_foomatic_rip_suspicious_child_execution.toml @@ -2,9 +2,7 @@ creation_date = "2024/09/27" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,7 +15,12 @@ through crafted UDP packets or network spoofing. This can result in arbitrary co initiated. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Suspicious Execution from Foomatic-rip or Cupsd Parent" @@ -114,6 +117,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like ( @@ -141,15 +145,17 @@ process.parent.name in ("foomatic-rip", "cupsd") and process.command_line like ( ) and not process.args like "gs*" ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1203" name = "Exploitation for Client Execution" reference = "https://attack.mitre.org/techniques/T1203/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml b/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml index 6f29f3951b8..ba6fb226b66 100644 --- a/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml +++ b/rules/linux/execution_file_transfer_or_listener_established_via_netcat.toml @@ -2,9 +2,7 @@ creation_date = "2020/02/18" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -21,7 +19,12 @@ false_positives = [ """, ] from = "now-9m" -index = ["auditbeat-*", "logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "logs-endpoint.events.network*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "File Transfer or Listener Established via Netcat" diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml index 1d9edd02b53..a163537237f 100644 --- a/rules/linux/execution_interpreter_tty_upgrade.toml +++ b/rules/linux/execution_interpreter_tty_upgrade.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/20" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,48 @@ simple reverse shell to a fully interactive tty after obtaining initial access t stable connection. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Upgrade of Non-interactive Shell" +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 Upgrade of Non-interactive Shell + +In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`. +- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries. +- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise. +- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell. +- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell. + +### False positive analysis + +- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows. +- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives. +- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise. +- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell. +- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts. +- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker. +- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" risk_score = 47 rule_id = "84d1f8db-207f-45ab-a578-921d91c23eb2" setup = """## Setup @@ -69,39 +105,6 @@ process where host.os.type == "linux" and event.type == "start" and process.args_count == 4) ) ''' -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 Upgrade of Non-interactive Shell - -In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`. -- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries. -- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise. -- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell. -- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell. - -### False positive analysis - -- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows. -- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives. -- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise. -- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker. -- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell. -- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts. -- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker. -- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml index d30212828a0..821967f8801 100644 --- a/rules/linux/execution_nc_listener_via_rlwrap.toml +++ b/rules/linux/execution_nc_listener_via_rlwrap.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/22" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -21,10 +19,49 @@ false_positives = [ """, ] from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Netcat Listener Established via rlwrap" +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 Netcat Listener Established via rlwrap + +Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields. +- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized. +- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts. +- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised. +- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed. +- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms. + +### False positive analysis + +- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities. +- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks. +- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts. +- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms. +- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident. +- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities. +- Enhance monitoring and logging on the affected host and network to detect similar activities in the future. +- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols.""" risk_score = 21 rule_id = "0f56369f-eb3d-459c-a00b-87c2bf7bdfc5" setup = """## Setup @@ -74,40 +111,6 @@ process where host.os.type == "linux" and event.type == "start" and process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and process.args : "*l*" and process.args_count >= 4 ''' -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 Netcat Listener Established via rlwrap - -Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields. -- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized. -- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts. -- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised. -- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed. -- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms. - -### False positive analysis - -- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities. -- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks. -- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts. -- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection. -- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms. -- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident. -- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities. -- Enhance monitoring and logging on the affected host and network to detect similar activities in the future. -- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols.""" [[rule.threat]] diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml index 639aac82354..c3d550b7b8b 100644 --- a/rules/linux/execution_potential_hack_tool_executed.toml +++ b/rules/linux/execution_potential_hack_tool_executed.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/22" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,52 @@ this rule should be investigated further, as hack tools are commonly used by blu well. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Linux Hack Tool Launched" +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 Linux Hack Tool Launched + +Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts. + +### Possible investigation steps + +- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity. +- Examine the command line arguments used during the process execution to understand the intent and scope of the activity. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities. +- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives. + +### False positive analysis + +- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments. +- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill. +- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior. +- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts. +- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts. +- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed. +- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools. +- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" risk_score = 47 rule_id = "1df1152b-610a-4f48-9d7a-504f6ee5d9da" setup = """## Setup @@ -61,6 +101,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and @@ -82,41 +123,7 @@ process.name in~ ( "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh" ) ''' -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 Linux Hack Tool Launched - -Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts. - -### Possible investigation steps - -- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". -- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. -- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity. -- Examine the command line arguments used during the process execution to understand the intent and scope of the activity. -- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities. -- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives. -### False positive analysis - -- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments. -- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill. -- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior. -- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts. -- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency. - -### Response and remediation - -- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities. -- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts. -- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed. -- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools. -- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" @@ -125,3 +132,4 @@ framework = "MITRE ATT&CK" id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/execution_process_backgrounded_by_unusual_parent.toml b/rules/linux/execution_process_backgrounded_by_unusual_parent.toml index e1a637a857b..f1e7ef3bd9e 100644 --- a/rules/linux/execution_process_backgrounded_by_unusual_parent.toml +++ b/rules/linux/execution_process_backgrounded_by_unusual_parent.toml @@ -2,18 +2,21 @@ creation_date = "2025/01/29" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/29" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule identifies processes that are backgrounded by an unusual parent process. This behavior may indicate -a process attempting to evade detection by hiding its parent process. +This rule identifies processes that are backgrounded by an unusual parent process. This behavior may indicate a process +attempting to evade detection by hiding its parent process. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "logs-endpoint.events.process*", + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", +] language = "kuery" license = "Elastic License v2" name = "Process Backgrounded by Unusual Parent" @@ -105,6 +108,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "new_terms" + query = ''' event.category:process and host.os.type:linux and event.type:start and event.action:(ProcessRollup2 or exec or exec_event or start) and @@ -112,36 +116,37 @@ process.name:(bash or csh or dash or fish or ksh or sh or tcsh or zsh) and process.args:(-c and *&) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" - -[rule.threat.tactic] -name = "Defense Evasion" -id = "TA0005" -reference = "https://attack.mitre.org/tactics/TA0005/" - [[rule.threat.technique]] id = "T1564" name = "Hide Artifacts" reference = "https://attack.mitre.org/techniques/T1564/" + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" + [rule.new_terms] field = "new_terms_fields" value = ["process.parent.name"] - [[rule.new_terms.history_window_start]] field = "history_window_start" value = "now-14d" + + diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml index 840ce3b7edb..959180badda 100644 --- a/rules/linux/execution_python_tty_shell.toml +++ b/rules/linux/execution_python_tty_shell.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/15" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,40 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Interactive Terminal Spawned via Python" +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 Interactive Terminal Spawned via Python + +Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh). +- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal. +- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious. +- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network. +- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events. +- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event. + +### False positive analysis + +- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks. +- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration. +- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships. +- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control. +- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files. +- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" risk_score = 73 rule_id = "d76b02ef-fc95-4001-9297-01cb7412232f" setup = """## Setup @@ -67,40 +99,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1) ) ''' -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 Interactive Terminal Spawned via Python - -Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity. - -### Possible investigation steps - -- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh). -- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal. -- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious. -- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network. -- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events. -- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event. - -### False positive analysis - -- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks. -- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration. -- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships. -- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. -- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control. -- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files. -- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml index a5c56cdcd63..a045f2f860e 100644 --- a/rules/linux/execution_python_webserver_spawned.toml +++ b/rules/linux/execution_python_webserver_spawned.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,50 @@ This rule identifies when a web server is spawned via Python. Attackers may use exfiltrate/infiltrate data or to move laterally within a network. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Web Server Spawned via Python" +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 Web Server Spawned via Python + +Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems. + +### Possible investigation steps + +- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer". +- Investigate the user account associated with the process to determine if it is a known or expected user for running such services. +- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server". +- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration. +- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts. +- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server. + +### False positive analysis + +- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses. +- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule. +- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods. +- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts. +- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. +- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server. +- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector. +- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident. +- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited. +- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken.""" risk_score = 21 rule_id = "99c2b626-de44-4322-b1f9-157ca408c17e" setup = """## Setup @@ -58,6 +96,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -69,69 +108,35 @@ process where host.os.type == "linux" and event.type == "start" and ) ) ''' -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 Web Server Spawned via Python - -Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems. - -### Possible investigation steps - -- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer". -- Investigate the user account associated with the process to determine if it is a known or expected user for running such services. -- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server". -- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration. -- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts. -- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server. - -### False positive analysis - -- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses. -- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule. -- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods. -- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts. -- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. -- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server. -- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector. -- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident. -- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited. -- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.006" name = "Python" reference = "https://attack.mitre.org/techniques/T1059/006/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1570" +name = "Lateral Tool Transfer" +reference = "https://attack.mitre.org/techniques/T1570/" + [rule.threat.tactic] -name = "Lateral Movement" id = "TA0008" +name = "Lateral Movement" reference = "https://attack.mitre.org/tactics/TA0008/" -[[rule.threat.technique]] -id = "T1570" -name = "Lateral Tool Transfer" -reference = "https://attack.mitre.org/techniques/T1570/" diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml index c91ef9fb642..30f4cebcb1e 100644 --- a/rules/linux/execution_shell_openssl_client_or_server.toml +++ b/rules/linux/execution_shell_openssl_client_or_server.toml @@ -2,22 +2,54 @@ creation_date = "2024/07/30" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This rule identifies when the openssl client or server is used to establish a connection. Attackers may use openssl to -establish a secure connection to a remote server or to create a secure server to receive connections. This activity -may be used to exfiltrate data or establish a command and control channel. +establish a secure connection to a remote server or to create a secure server to receive connections. This activity may +be used to exfiltrate data or establish a command and control channel. """ from = "now-9m" index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Openssl Client or Server Activity" +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 Openssl Client or Server Activity + +OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port". +- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert"). +- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious. +- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity. +- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications. + +### False positive analysis + +- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment. +- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes. +- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening. +- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion. +- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities. +- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access. +- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity. +- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" references = ["https://gtfobins.github.io/gtfobins/openssl/"] risk_score = 21 rule_id = "ad5a3757-c872-4719-8c72-12d3f08db655" @@ -55,10 +87,11 @@ tags = [ "Data Source: Elastic Defend", "Data Source: Elastic Endgame", "Data Source: SentinelOne", - "Resources: Investigation Guide" + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and process.name == "openssl" and ( @@ -69,68 +102,35 @@ process where host.os.type == "linux" and event.type == "start" and event.action "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert", "/etc/zabbix/scripts/check_dane_tlsa.sh" ) ''' -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 Openssl Client or Server Activity - -OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port". -- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert"). -- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious. -- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity. -- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications. - -### False positive analysis - -- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment. -- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes. -- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening. -- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion. -- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives. -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities. -- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications. -- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access. -- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity. -- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. -- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1071" name = "Application Layer Protocol" reference = "https://attack.mitre.org/techniques/T1071/" + [rule.threat.tactic] id = "TA0011" name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" + diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml index 057f3fab8e6..7960e23158b 100644 --- a/rules/linux/execution_shell_via_background_process.toml +++ b/rules/linux/execution_shell_via_background_process.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/20" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,50 @@ Monitors for the execution of background processes with process arguments capabl channel. This may indicate the creation of a backdoor reverse connection, and should be investigated further. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Reverse Shell via Background Process" +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 Reverse Shell via Background Process + +In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket. +- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution. +- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account. +- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt. +- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. +- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern. + +### False positive analysis + +- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized. +- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule. +- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise. +- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary. +- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments. +- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement. +- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" risk_score = 47 rule_id = "259be2d8-3b1a-4c2c-a0eb-0c8e77f35e39" setup = """## Setup @@ -65,41 +103,6 @@ process where host.os.type == "linux" and event.type == "start" and process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ''' -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 Reverse Shell via Background Process - -In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation. - -### Possible investigation steps - -- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket. -- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution. -- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account. -- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt. -- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. -- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern. - -### False positive analysis - -- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized. -- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule. -- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise. -- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary. -- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments. -- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement. -- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories. -- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml index 9056e38af37..743df9ba2e4 100644 --- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml +++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml @@ -2,9 +2,7 @@ creation_date = "2023/06/26" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,40 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Suspicious Content Extracted or Decompressed via Funzip" +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 Content Extracted or Decompressed via Funzip + +Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution. +- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut". +- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions. +- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages". +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise. +- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections. + +### False positive analysis + +- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner. +- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern. +- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes. +- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the potential malware. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads. +- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred. +- Restore any compromised files or systems from known good backups to ensure integrity and availability of data. +- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" references = ["https://attack.mitre.org/software/S0482/"] risk_score = 47 rule_id = "dc0b7782-0df0-47ff-8337-db0d678bdb66" @@ -68,40 +100,6 @@ not process.args : "/var/log/messages" and not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*") ''' -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 Content Extracted or Decompressed via Funzip - -Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation. - -### Possible investigation steps - -- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution. -- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut". -- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions. -- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages". -- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise. -- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections. - -### False positive analysis - -- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner. -- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern. -- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes. -- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further spread of the potential malware. -- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence. -- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads. -- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred. -- Restore any compromised files or systems from known good backups to ensure integrity and availability of data. -- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml index 75a52429d9f..dae3affd53a 100644 --- a/rules/linux/execution_suspicious_mining_process_creation_events.toml +++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml @@ -2,9 +2,7 @@ creation_date = "2023/02/08" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,40 @@ index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.file*", "lo language = "eql" license = "Elastic License v2" name = "Suspicious Mining Process Creation Event" +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 Mining Process Creation Event + +Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats. + +### Possible investigation steps + +- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service". +- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began. +- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments. +- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining. +- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files. +- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms. + +### False positive analysis + +- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action. +- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening. +- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe. +- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign. + +### Response and remediation + +- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query. +- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services. +- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" risk_score = 47 rule_id = "e2258f48-ba75-4248-951b-7c885edf18c2" setup = """## Setup @@ -63,40 +95,6 @@ query = ''' file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service") ''' -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 Mining Process Creation Event - -Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats. - -### Possible investigation steps - -- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service". -- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began. -- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments. -- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining. -- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files. -- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms. - -### False positive analysis - -- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action. -- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening. -- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe. -- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign. - -### Response and remediation - -- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary. -- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query. -- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker. -- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. -- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services. -- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml index ddd276f3160..63e0623347c 100644 --- a/rules/linux/execution_tc_bpf_filter.toml +++ b/rules/linux/execution_tc_bpf_filter.toml @@ -2,9 +2,7 @@ creation_date = "2022/07/11" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/07" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,40 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "BPF filter applied using TC" +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 BPF filter applied using TC + +BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive. +- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`. +- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior. +- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity. +- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat. +- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context. + +### False positive analysis + +- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule. +- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities. +- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule. +- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary. +- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application. +- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses. +- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist. +- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters.""" references = [ "https://github.com/h3xduck/TripleCross/blob/master/src/helpers/deployer.sh", "https://man7.org/linux/man-pages/man8/tc.8.html", @@ -70,40 +102,6 @@ process where host.os.type == "linux" and event.type == "start" and process.exec process.args == "filter" and process.args == "add" and process.args == "bpf" and not process.parent.executable == "/usr/sbin/libvirtd" ''' -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 BPF filter applied using TC - -BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive. -- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`. -- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior. -- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity. -- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat. -- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context. - -### False positive analysis - -- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule. -- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities. -- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule. -- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary. -- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application. -- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses. -- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist. -- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas. -- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. -- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters.""" [[rule.threat]] diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml index 848168d4fe8..04f5a0d5c86 100644 --- a/rules/linux/execution_unix_socket_communication.toml +++ b/rules/linux/execution_unix_socket_communication.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/04" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/03/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,42 +13,17 @@ privileges or set up malicious communication channels via Unix sockets for inter evade detection. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Unix Socket Connection" -risk_score = 21 -rule_id = "41284ba3-ed1a-4598-bfba-a97f75d9aba2" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Execution", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Auditd Manager", - "Data Source: Crowdstrike", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" -query = ''' -process where host.os.type == "linux" and event.type == "start" and - event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and - ( - (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and - process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or - (process.name == "socat" and - process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*")) or - (process.name == "curl" and process.args : ("--unix-socket", "--abstract-unix-socket")) -) and -not ( - process.args == "/var/run/libvirt/libvirt-sock" or - process.parent.name in ("bundle", "ruby", "haproxystatus.sh") -) -''' note = """## Triage and analysis > **Disclaimer**: @@ -86,16 +59,51 @@ Unix sockets facilitate efficient inter-process communication (IPC) on the same - Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation. - Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections. - Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" +risk_score = 21 +rule_id = "41284ba3-ed1a-4598-bfba-a97f75d9aba2" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Execution", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Auditd Manager", + "Data Source: Crowdstrike", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +process where host.os.type == "linux" and event.type == "start" and + event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and + ( + (process.name in ("nc", "ncat", "netcat", "nc.openbsd") and + process.args == "-U" and process.args : ("/usr/local/*", "/run/*", "/var/run/*")) or + (process.name == "socat" and + process.args == "-" and process.args : ("UNIX-CLIENT:/usr/local/*", "UNIX-CLIENT:/run/*", "UNIX-CLIENT:/var/run/*")) or + (process.name == "curl" and process.args : ("--unix-socket", "--abstract-unix-socket")) +) and +not ( + process.args == "/var/run/libvirt/libvirt-sock" or + process.parent.name in ("bundle", "ruby", "haproxystatus.sh") +) +''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1559" name = "Inter-Process Communication" reference = "https://attack.mitre.org/techniques/T1559/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/execution_unusual_pkexec_execution.toml b/rules/linux/execution_unusual_pkexec_execution.toml index 9fe32073236..28e05736054 100644 --- a/rules/linux/execution_unusual_pkexec_execution.toml +++ b/rules/linux/execution_unusual_pkexec_execution.toml @@ -2,23 +2,60 @@ creation_date = "2025/01/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/23" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to -execute programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual -executions of `pkexec` are identified, and may indicate an attempt to escalate privileges or perform -unauthorized actions on the system. +This rule detects the execution of the `pkexec` command by a shell process. The `pkexec` command is used to execute +programs as another user, typically as the superuser. Through the `new_terms` rule type, unusual executions of `pkexec` +are identified, and may indicate an attempt to escalate privileges or perform unauthorized actions on the system. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "logs-endpoint.events.process*", + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", +] language = "kuery" license = "Elastic License v2" name = "Unusual Pkexec Execution" +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 Unusual Pkexec Execution + +`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns. + +### Possible investigation steps + +- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations. +- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious. +- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity. +- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines. +- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings. +- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes. + +### False positive analysis + +- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec. +- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts. +- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms. +- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise. +- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts. +- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution. +- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation. +- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities.""" risk_score = 21 rule_id = "3ca81a95-d5af-4b77-b0ad-b02bc746f640" setup = """## Setup @@ -72,68 +109,34 @@ tags = [ ] timestamp_override = "event.ingested" type = "new_terms" + query = ''' event.category:process and host.os.type:linux and event.type:start and event.action:(exec or exec_event or start or ProcessRollup2) and process.name:pkexec and process.args:pkexec and process.parent.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) ''' -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 Unusual Pkexec Execution - -`Pkexec` is a command-line utility in Linux environments that allows users to execute commands as another user, often with elevated privileges. Adversaries may exploit `pkexec` to escalate privileges or execute unauthorized actions by invoking it through shell processes. The detection rule identifies atypical `pkexec` executions initiated by common shell interpreters, flagging potential misuse by monitoring specific process attributes and execution patterns. - -### Possible investigation steps - -- Review the process tree to understand the context of the pkexec execution, focusing on the parent process names such as bash, dash, sh, tcsh, csh, zsh, ksh, or fish, as these are indicative of shell-based invocations. -- Examine the command-line arguments passed to pkexec to determine the intended action and assess whether it aligns with expected administrative tasks or appears suspicious. -- Check the user account associated with the pkexec execution to verify if the account has legitimate reasons to perform such actions, and investigate any anomalies in user behavior or account activity. -- Investigate the timing and frequency of the pkexec executions to identify patterns or correlations with other suspicious activities or known attack timelines. -- Cross-reference the alert with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Crowdstrike, or SentinelOne to gather additional context and corroborate findings. -- Assess the system's current state for signs of compromise, such as unauthorized changes, unexpected network connections, or the presence of known malicious files or processes. - -### False positive analysis - -- Routine administrative tasks: System administrators may use pkexec for legitimate purposes, such as performing maintenance tasks. To handle this, create exceptions for known administrator accounts or specific maintenance scripts that regularly invoke pkexec. -- Automated scripts: Some automated scripts or cron jobs might use pkexec to perform scheduled tasks. Identify these scripts and exclude their specific process names or paths from the rule to prevent false alerts. -- Software updates: Certain software update processes might use pkexec to apply patches or updates. Monitor and document these processes, then configure exceptions for recognized update mechanisms. -- Development environments: Developers might use pkexec during testing or development. Establish a list of development machines or user accounts and exclude them from the rule to reduce noise. -- Custom user applications: Users may have custom applications that require pkexec for legitimate functionality. Review these applications and whitelist their specific execution patterns to avoid unnecessary alerts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious `pkexec` processes identified by the alert to halt unauthorized actions or privilege escalation attempts. -- Review and analyze the parent shell process and its command history to understand the context and origin of the `pkexec` execution. -- Reset credentials and review permissions for the user accounts involved to mitigate any unauthorized access or privilege escalation. -- Conduct a thorough scan of the affected system for additional indicators of compromise or persistence mechanisms that may have been deployed. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Update and enhance monitoring rules to detect similar `pkexec` misuse attempts in the future, ensuring comprehensive coverage of shell processes and privilege escalation activities.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" @@ -142,7 +145,8 @@ reference = "https://attack.mitre.org/tactics/TA0003/" [rule.new_terms] field = "new_terms_fields" value = ["process.parent.command_line"] - [[rule.new_terms.history_window_start]] field = "history_window_start" value = "now-14d" + + diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml index 3b1a1f4a34a..fe0af03f5a4 100644 --- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml +++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,50 @@ for exfiltration on Linux systems. Data splitting is a technique used by adversa avoid detection and exfiltrate data. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Data Splitting Detected" +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 Data Splitting Detected + +Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities. + +### Possible investigation steps + +- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'. +- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule. +- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'. +- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised. +- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections. +- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise. + +### False positive analysis + +- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list. +- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria. +- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns. +- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts. +- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments. +- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts. +- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations. +- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities.""" risk_score = 21 rule_id = "e302e6c3-448c-4243-8d9b-d41da70db582" setup = """## Setup @@ -55,10 +93,11 @@ tags = [ "Data Source: Crowdstrike", "Data Source: SentinelOne", "Data Source: Elastic Endgame", - "Resources: Investigation Guide" + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -80,46 +119,13 @@ process where host.os.type == "linux" and event.type == "start" and ) ) ''' -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 Data Splitting Detected - -Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities. - -### Possible investigation steps - -- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'. -- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule. -- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'. -- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised. -- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections. -- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise. -### False positive analysis - -- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list. -- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria. -- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns. -- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts. -- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions. - -### Response and remediation - -- Immediately isolate the affected Linux system from the network to prevent further data exfiltration. -- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments. -- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts. -- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations. -- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation. -- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. -- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" - [rule.threat.tactic] - name = "Exfiltration" - id = "TA0010" - reference = "https://attack.mitre.org/tactics/TA0010/" +[rule.threat.tactic] +id = "TA0010" +name = "Exfiltration" +reference = "https://attack.mitre.org/tactics/TA0010/" + diff --git a/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml b/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml index 4511e11ce2a..9903a09d815 100644 --- a/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml +++ b/rules/linux/exfiltration_unusual_file_transfer_utility_launched.toml @@ -2,17 +2,14 @@ creation_date = "2025/02/21" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/02/21" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule leverages ES|QL to detect the execution of unusual file transfer utilities on Linux systems. -Attackers may use these utilities to exfiltrate data from a compromised system. ES|QL rules have -limited fields available in its alert documents. Make sure to review the original documents to aid -in the investigation of this alert. +This rule leverages ES|QL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use +these utilities to exfiltrate data from a compromised system. ES|QL rules have limited fields available in its alert +documents. Make sure to review the original documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -58,6 +55,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.process-* | keep @timestamp, host.os.type, event.type, event.action, process.name, process.executable, process.parent.executable, process.command_line, agent.id @@ -70,18 +68,19 @@ from logs-endpoint.events.process-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [rule.threat.tactic] - name = "Exfiltration" - id = "TA0010" - reference = "https://attack.mitre.org/tactics/TA0010/" - +[rule.threat.tactic] +id = "TA0010" +name = "Exfiltration" +reference = "https://attack.mitre.org/tactics/TA0010/" [[rule.threat]] framework = "MITRE ATT&CK" - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml index d39b8f1763d..b0dd5c06c53 100644 --- a/rules/linux/impact_memory_swap_modification.toml +++ b/rules/linux/impact_memory_swap_modification.toml @@ -2,9 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,6 +16,41 @@ index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Memory Swap 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 Memory Swap Modification + +Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process. +- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user. +- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage. +- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig. +- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications. + +### False positive analysis + +- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts. +- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts. +- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts. +- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities. +- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware. +- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness". +- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig. +- Review and restore swap settings to their default or secure configurations to ensure system stability and performance. +- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack. +- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary.""" risk_score = 21 rule_id = "5e4023e7-6357-4061-ae1c-9df33e78c674" setup = """## Setup @@ -61,6 +94,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and process.parent.executable != null and @@ -75,69 +109,35 @@ process.name in ("swapon", "swapoff") or ( ) and not process.parent.name in ("lynis", "systemd", "end-zram-swapping", "SyxsenseResponder", "tuned", "platform-python", "timeout") ''' -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 Memory Swap Modification - -Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation. - -### Possible investigation steps - -- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process. -- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness. -- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user. -- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage. -- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig. -- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications. - -### False positive analysis - -- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts. -- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts. -- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts. -- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities. -- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening. - -### Response and remediation -- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware. -- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness". -- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig. -- Review and restore swap settings to their default or secure configurations to ensure system stability and performance. -- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly. -- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack. -- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary.""" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1496" +name = "Resource Hijacking" +reference = "https://attack.mitre.org/techniques/T1496/" - [rule.threat.tactic] - name = "Impact" - id = "TA0040" - reference = "https://attack.mitre.org/tactics/TA0040/" - - [[rule.threat.technique]] - name = "Resource Hijacking" - id = "T1496" - reference = "https://attack.mitre.org/techniques/T1496/" +[rule.threat.tactic] +id = "TA0040" +name = "Impact" +reference = "https://attack.mitre.org/tactics/TA0040/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" + - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat.technique]] - name = "Command and Scripting Interpreter" - id = "T1059" - reference = "https://attack.mitre.org/techniques/T1059/" +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat.technique.subtechnique]] - name = "Unix Shell" - id = "T1059.004" - reference = "https://attack.mitre.org/techniques/T1059/004/" diff --git a/rules/linux/impact_potential_bruteforce_malware_infection.toml b/rules/linux/impact_potential_bruteforce_malware_infection.toml index 7e881adf9b5..933ee08f0f5 100644 --- a/rules/linux/impact_potential_bruteforce_malware_infection.toml +++ b/rules/linux/impact_potential_bruteforce_malware_infection.toml @@ -2,20 +2,18 @@ creation_date = "2025/02/20" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/02/20" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This detection identifies a Linux host that has potentially been infected with malware and is being used to conduct -brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection -looks for a high volume of outbound connection attempts to non-private IP addresses from a single process. A -compromised host may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access -to remote systems. This behavior is commonly observed in SSH brute-force campaigns where malware hijacks -vulnerable machines to expand its attack surface. ES|QL rules have limited fields available in its alert documents. -Make sure to review the original documents to aid in the investigation of this alert. +brute-force attacks against external systems over SSH (port 22 and common alternative SSH ports). The detection looks +for a high volume of outbound connection attempts to non-private IP addresses from a single process. A compromised host +may be part of a botnet or controlled by an attacker, attempting to gain unauthorized access to remote systems. This +behavior is commonly observed in SSH brute-force campaigns where malware hijacks vulnerable machines to expand its +attack surface. ES|QL rules have limited fields available in its alert documents. Make sure to review the original +documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -61,6 +59,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.network-* | keep @timestamp, host.os.type, event.type, event.action, destination.port, process.executable, destination.ip, agent.id @@ -79,46 +78,46 @@ from logs-endpoint.events.network-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1496" +name = "Resource Hijacking" +reference = "https://attack.mitre.org/techniques/T1496/" - [rule.threat.tactic] - name = "Impact" - id = "TA0040" - reference = "https://attack.mitre.org/tactics/TA0040/" - - [[rule.threat.technique]] - name = "Resource Hijacking" - id = "T1496" - reference = "https://attack.mitre.org/techniques/T1496/" +[rule.threat.tactic] +id = "TA0040" +name = "Impact" +reference = "https://attack.mitre.org/tactics/TA0040/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat.technique]] - name = "Command and Scripting Interpreter" - id = "T1059" - reference = "https://attack.mitre.org/techniques/T1059/" - - [[rule.threat.technique.subtechnique]] - name = "Unix Shell" - id = "T1059.004" - reference = "https://attack.mitre.org/techniques/T1059/004/" +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1071" +name = "Application Layer Protocol" +reference = "https://attack.mitre.org/techniques/T1071/" + - [rule.threat.tactic] - id = "TA0011" - name = "Command and Control" - reference = "https://attack.mitre.org/tactics/TA0011/" +[rule.threat.tactic] +id = "TA0011" +name = "Command and Control" +reference = "https://attack.mitre.org/tactics/TA0011/" - [[rule.threat.technique]] - id = "T1071" - name = "Application Layer Protocol" - reference = "https://attack.mitre.org/techniques/T1071/" diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml index b111e3b5fc0..5faf68cef08 100644 --- a/rules/linux/lateral_movement_ssh_it_worm_download.toml +++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/21" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -13,10 +11,51 @@ Identifies processes that are capable of downloading files with command line arg autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential SSH-IT SSH Worm Downloaded" +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 SSH-IT SSH Worm Downloaded + +SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query. +- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account. +- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement. +- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts. +- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved. +- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat. + +### False positive analysis + +- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators. +- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts. +- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise. +- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm. +- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm. +- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm. +- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA). +- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them.""" references = ["https://www.thc.org/ssh-it/"] risk_score = 47 rule_id = "2ddc468e-b39b-4f5b-9825-f3dcb0e998ea" @@ -70,40 +109,6 @@ process where host.os.type == "linux" and event.type == "start" and "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs" ) ''' -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 SSH-IT SSH Worm Downloaded - -SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats. - -### Possible investigation steps - -- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query. -- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account. -- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement. -- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts. -- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved. -- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat. - -### False positive analysis - -- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators. -- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts. -- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise. -- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm. -- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm. -- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm. -- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA). -- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them.""" [[rule.threat]] diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml index 68dda3bbad7..25ac5222028 100644 --- a/rules/linux/lateral_movement_telnet_network_activity_external.toml +++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/23" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -25,6 +23,40 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs language = "eql" license = "Elastic License v2" name = "Connection to External Network via Telnet" +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 Connection to External Network via Telnet + +Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges. + +### Possible investigation steps + +- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection. +- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services. +- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session. +- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection. +- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts. + +### False positive analysis + +- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts. +- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives. +- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts. +- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts. +- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"] risk_score = 47 rule_id = "e19e64ee-130e-4c07-961f-8a339f0b8362" @@ -89,40 +121,6 @@ sequence by process.entity_id ) ] ''' -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 Connection to External Network via Telnet - -Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges. - -### Possible investigation steps - -- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection. -- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services. -- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session. -- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection. -- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts. - -### False positive analysis - -- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections. -- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts. -- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives. -- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts. -- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices. - -### Response and remediation - -- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. -- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity. -- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts. -- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml index 107c0a38bc3..e01b71b1232 100644 --- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml +++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml @@ -2,9 +2,7 @@ creation_date = "2020/04/23" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -25,6 +23,41 @@ index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs language = "eql" license = "Elastic License v2" name = "Connection to Internal Network via Telnet" +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 Connection to Internal Network via Telnet + +Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet. +- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt. +- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection. +- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt. +- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts. +- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat. + +### False positive analysis + +- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts. +- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives. +- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives. +- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop unauthorized access. +- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed. +- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access. +- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation. +- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.""" references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"] risk_score = 47 rule_id = "1b21abcc-4d9f-4b08-a7f5-316f5f94b973" @@ -89,41 +122,6 @@ sequence by process.entity_id ) ] ''' -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 Connection to Internal Network via Telnet - -Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response. - -### Possible investigation steps - -- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet. -- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt. -- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection. -- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt. -- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts. -- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat. - -### False positive analysis - -- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks. -- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts. -- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives. -- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives. -- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration. -- Terminate any active Telnet sessions on the affected host to stop unauthorized access. -- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed. -- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access. -- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation. -- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml index 625d5d4de54..4e477752c24 100644 --- a/rules/linux/persistence_apt_package_manager_execution.toml +++ b/rules/linux/persistence_apt_package_manager_execution.toml @@ -2,9 +2,7 @@ creation_date = "2024/02/01" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -20,6 +18,41 @@ index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Suspicious APT Package Manager Execution" +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 APT Package Manager Execution + +The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument. +- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands. +- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution. +- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited. +- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities. +- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution. + +### False positive analysis + +- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands. +- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names. +- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities. +- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule. +- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule. + +### Response and remediation + +- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria. +- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. +- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured. +- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary. +- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" references = ["https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms"] risk_score = 47 rule_id = "ad959eeb-2b7b-4722-ba08-a45f6622f005" @@ -76,41 +109,6 @@ sequence by host.id with maxspan=5s ) ] by process.parent.entity_id ''' -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 APT Package Manager Execution - -The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response. - -### Possible investigation steps - -- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument. -- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands. -- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution. -- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited. -- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities. -- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution. - -### False positive analysis - -- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands. -- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names. -- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities. -- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule. -- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule. - -### Response and remediation - -- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network. -- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria. -- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. -- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured. -- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary. -- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] diff --git a/rules/linux/persistence_boot_file_copy.toml b/rules/linux/persistence_boot_file_copy.toml index 2fc76720e24..f243084744a 100644 --- a/rules/linux/persistence_boot_file_copy.toml +++ b/rules/linux/persistence_boot_file_copy.toml @@ -2,17 +2,15 @@ creation_date = "2025/01/16" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/24" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the process of copying or moving files from or to the `/boot` directory on Linux systems. The -`/boot` directory contains files that are essential for the system to boot, such as the kernel and initramfs -images. Attackers may copy or move files to the `/boot` directory to modify the boot process, which can be -leveraged to maintain access to the system. +This rule detects the process of copying or moving files from or to the `/boot` directory on Linux systems. The `/boot` +directory contains files that are essential for the system to boot, such as the kernel and initramfs images. Attackers +may copy or move files to the `/boot` directory to modify the boot process, which can be leveraged to maintain access to +the system. """ from = "now-9m" index = [ @@ -21,11 +19,44 @@ index = [ "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", - "logs-sentinel_one_cloud_funnel.*" + "logs-sentinel_one_cloud_funnel.*", ] language = "eql" license = "Elastic License v2" name = "Boot File Copy" +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 Boot File Copy +The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications. + +### Possible investigation steps + +- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'. +- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'. +- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior. +- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events. +- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images. +- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern. + +### False positive analysis + +- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule. +- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria. +- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged. +- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory. +- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary. +- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications. +- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes.""" risk_score = 21 rule_id = "5bda8597-69a6-4b9e-87a2-69a7c963ea83" setup = """## Setup @@ -64,6 +95,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and @@ -73,43 +105,10 @@ process.name in ("cp", "mv") and process.parent.executable != null and process.a process.parent.args like~ ("/usr/bin/mkinitcpio", "/var/tmp/rpm-tmp.*") ) ''' -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 Boot File Copy -The `/boot` directory in Linux systems is crucial for storing files necessary for booting, such as the kernel. Adversaries may exploit this by copying or moving files to alter the boot process, potentially gaining persistent access. The 'Boot File Copy' detection rule identifies suspicious file operations in this directory, excluding legitimate processes, to flag potential unauthorized modifications. - -### Possible investigation steps - -- Review the process details to identify the specific file operation by examining the process name and arguments, particularly focusing on the use of 'cp' or 'mv' commands with paths involving '/boot/*'. -- Investigate the parent process executable and name to determine if the operation was initiated by a known legitimate process or script, ensuring it is not one of the excluded processes like 'update-initramfs' or 'grub-mkconfig'. -- Check the user account associated with the process to assess whether it is a privileged account and if the activity aligns with typical user behavior. -- Analyze recent system logs and audit records for any other suspicious activities or anomalies around the time of the alert to identify potential patterns or related events. -- Verify the integrity and authenticity of the files in the /boot directory to ensure no unauthorized modifications have been made, focusing on critical files like the kernel and initramfs images. -- If possible, correlate the alert with other data sources such as Elastic Endgame or Crowdstrike to gather additional context and confirm whether this is part of a broader attack pattern. - -### False positive analysis - -- System updates and maintenance tasks often involve legitimate processes that interact with the /boot directory. Processes like update-initramfs, dracut, and grub-mkconfig are common during these operations. Users can exclude these processes by adding them to the exception list in the detection rule. -- Custom scripts or administrative tasks that require copying or moving files to the /boot directory may trigger false positives. Identify these scripts and add their parent process names or paths to the exclusion criteria. -- Package management operations, such as those involving dpkg or rpm, may also interact with the /boot directory. Exclude paths like /var/lib/dpkg/info/* and /var/tmp/rpm-tmp.* to prevent these from being flagged. -- Temporary system recovery or installation processes might use directories like /tmp/newroot. Exclude these paths to avoid unnecessary alerts during legitimate recovery operations. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. -- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized 'cp' or 'mv' operations in the /boot directory. -- Conduct a thorough review of the /boot directory to identify and remove any unauthorized files or modifications. Restore any altered files from a known good backup if necessary. -- Check for any unauthorized changes to boot configuration files, such as GRUB or LILO, and restore them to their original state. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized access attempts or modifications. -- Review and update access controls and permissions for the /boot directory to ensure only authorized processes and users can make changes.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" @@ -125,29 +124,28 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -155,3 +153,4 @@ framework = "MITRE ATT&CK" id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/persistence_chkconfig_service_add.toml b/rules/linux/persistence_chkconfig_service_add.toml index 2a908cda88a..56bd686bc5f 100644 --- a/rules/linux/persistence_chkconfig_service_add.toml +++ b/rules/linux/persistence_chkconfig_service_add.toml @@ -2,9 +2,7 @@ creation_date = "2022/07/22" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -176,6 +174,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.action in ("exec", "exec_event", "start") and ( @@ -188,15 +187,17 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event", ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1037" name = "Boot or Logon Initialization Scripts" reference = "https://attack.mitre.org/techniques/T1037/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_dbus_service_creation.toml b/rules/linux/persistence_dbus_service_creation.toml index cf7b3a78f60..81d20357dd7 100644 --- a/rules/linux/persistence_dbus_service_creation.toml +++ b/rules/linux/persistence_dbus_service_creation.toml @@ -2,24 +2,57 @@ creation_date = "2025/01/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the creation of D-Bus service files on Linux systems. D-Bus is a message bus system that provides -a way for applications to talk to one another. D-Bus services are defined in service files that are typically -located in default directories. The rule looks for the creation of service files that are not associated with -known package managers or system services. Attackers may create malicious D-Bus services to establish persistence -or escalate privileges on a system. +This rule detects the creation of D-Bus service files on Linux systems. D-Bus is a message bus system that provides a +way for applications to talk to one another. D-Bus services are defined in service files that are typically located in +default directories. The rule looks for the creation of service files that are not associated with known package +managers or system services. Attackers may create malicious D-Bus services to establish persistence or escalate +privileges on a system. """ from = "now-9m" index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] language = "eql" license = "Elastic License v2" name = "D-Bus Service Created" +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 D-Bus Service Created + +D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity. + +### Possible investigation steps + +- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension. +- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose. +- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*. +- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert. +- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system. + +### False positive analysis + +- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule. +- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management. +- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise. +- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list. +- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity. +- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred. +- Restore the system from a known good backup if unauthorized changes or damage to the system are detected. +- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" risk_score = 21 rule_id = "952c92af-d67f-4f01-8a9c-725efefa7e07" setup = """## Setup @@ -61,6 +94,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.extension in ("service", "conf") and file.path like~ ( @@ -96,64 +130,30 @@ file.extension in ("service", "conf") and file.path like~ ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' -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 D-Bus Service Created - -D-Bus is an inter-process communication system in Linux, enabling applications to communicate. Adversaries may exploit D-Bus by creating unauthorized service files to maintain persistence or escalate privileges. The detection rule identifies suspicious service file creations in key directories, excluding known legitimate processes, to flag potential malicious activity. - -### Possible investigation steps - -- Review the file path and extension to confirm if the created file is located in one of the monitored directories such as /usr/share/dbus-1/system-services/ or /etc/dbus-1/system.d/, and ensure it has a .service or .conf extension. -- Examine the process executable that created the file to determine if it is listed as a known legitimate process in the exclusion list. If not, investigate the process further to understand its origin and purpose. -- Check the process name and path for any unusual or unexpected patterns, especially if it is not part of the known exclusions like ssm-agent-worker or platform-python*. -- Investigate the file creation time and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of the alert. -- Look into the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. -- Search for any related alerts or logs that might indicate a broader attack pattern, such as other unauthorized file creations or modifications in the system. - -### False positive analysis - -- Package manager operations can trigger false positives when legitimate service files are created during software installations or updates. To manage this, exclude processes associated with known package managers like dpkg, rpm, and yum from the detection rule. -- System service updates may also result in false positives. Exclude processes such as systemd and crond that are responsible for legitimate system service management. -- Development and testing environments often involve the creation of temporary or test service files. Exclude paths and processes specific to these environments, such as those under /tmp or /dev/fd, to reduce noise. -- Automation tools like Puppet and Chef can create service files as part of their configuration management tasks. Exclude these tools by adding their executable paths to the exception list. -- Custom scripts or tools that mimic package manager behavior might also cause false positives. Identify and exclude these specific scripts or tools by their process names or paths if they are known to be benign. -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Terminate any suspicious processes associated with the creation of unauthorized D-Bus service files to halt potential malicious activity. -- Remove any unauthorized D-Bus service files identified in the specified directories to eliminate persistence mechanisms. -- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred. -- Restore the system from a known good backup if unauthorized changes or damage to the system are detected. -- Monitor the system and network for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting mechanisms. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" + diff --git a/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml b/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml index 3ed85e11d02..219d9888e23 100644 --- a/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml +++ b/rules/linux/persistence_dbus_unsual_daemon_parent_execution.toml @@ -2,22 +2,55 @@ creation_date = "2025/01/21" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This rule detects when an unusual child process is spawned from the `dbus-daemon` parent process. The `dbus-daemon` -process is a message bus system that provides a way for applications to talk to each other. Attackers may abuse -this process to execute malicious code or escalate privileges. +process is a message bus system that provides a way for applications to talk to each other. Attackers may abuse this +process to execute malicious code or escalate privileges. """ from = "now-9m" index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Unusual D-Bus Daemon Child Process" +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 Unusual D-Bus Daemon Child Process + +The D-Bus daemon is a crucial component in Linux environments, facilitating inter-process communication by allowing applications to exchange information. Adversaries may exploit this by spawning unauthorized child processes to execute malicious code or gain elevated privileges. The detection rule identifies anomalies by monitoring child processes of the D-Bus daemon, excluding known benign processes and paths, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details to identify the unusual child process spawned from the dbus-daemon, focusing on the process name and executable path to determine if it is known or potentially malicious. +- Examine the command-line arguments (process.args) of the unusual child process to understand its intended function and assess if it aligns with typical usage patterns. +- Investigate the parent process arguments (process.parent.args) to confirm whether the dbus-daemon was running in a session context or another mode that might explain the unusual child process. +- Check the process start time and correlate it with other system events or logs to identify any related activities or anomalies occurring around the same time. +- Look into the user context under which the unusual child process was executed to determine if it was initiated by a legitimate user or potentially compromised account. +- Search for any network connections or file modifications associated with the unusual child process to identify potential data exfiltration or lateral movement activities. + +### False positive analysis + +- Known benign processes such as gnome-keyring-daemon and abrt-dbus may trigger the rule. Users can exclude these processes by adding them to the exception list in the detection rule. +- Processes executed from common library paths like /usr/lib/ or /usr/local/lib/ are typically non-threatening. Users should review these paths and consider excluding them if they are consistently generating false positives. +- The dbus-daemon with the --session argument is generally safe. Users can ensure this argument is included in the exception criteria to prevent unnecessary alerts. +- Specific applications like software-properties-dbus and serviceHelper.py are known to be benign. Users should verify these applications' legitimacy in their environment and exclude them if they are frequently flagged. +- Regularly review and update the exception list to include any new benign processes or paths that are identified over time, ensuring the rule remains effective without generating excessive false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious child processes spawned by the dbus-daemon that are not recognized as legitimate or necessary for system operations. +- Conduct a thorough review of the affected system's logs to identify any unauthorized access or changes made by the suspicious process. +- Restore any altered or compromised system files from a known good backup to ensure system integrity. +- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring on the dbus-daemon to prevent unauthorized process execution in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" risk_score = 21 rule_id = "9705b458-689a-4ec6-afe8-b4648d090612" setup = """## Setup @@ -60,6 +93,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and process.parent.name == "dbus-daemon" and process.args_count > 1 and not ( @@ -69,82 +103,47 @@ process.parent.name == "dbus-daemon" and process.args_count > 1 and not ( process.executable like~ ("/usr/lib/*", "/usr/local/lib/*", "/usr/libexec/*", "/tmp/newroot/*") ) ''' -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 Unusual D-Bus Daemon Child Process - -The D-Bus daemon is a crucial component in Linux environments, facilitating inter-process communication by allowing applications to exchange information. Adversaries may exploit this by spawning unauthorized child processes to execute malicious code or gain elevated privileges. The detection rule identifies anomalies by monitoring child processes of the D-Bus daemon, excluding known benign processes and paths, thus highlighting potential threats. - -### Possible investigation steps - -- Review the process details to identify the unusual child process spawned from the dbus-daemon, focusing on the process name and executable path to determine if it is known or potentially malicious. -- Examine the command-line arguments (process.args) of the unusual child process to understand its intended function and assess if it aligns with typical usage patterns. -- Investigate the parent process arguments (process.parent.args) to confirm whether the dbus-daemon was running in a session context or another mode that might explain the unusual child process. -- Check the process start time and correlate it with other system events or logs to identify any related activities or anomalies occurring around the same time. -- Look into the user context under which the unusual child process was executed to determine if it was initiated by a legitimate user or potentially compromised account. -- Search for any network connections or file modifications associated with the unusual child process to identify potential data exfiltration or lateral movement activities. - -### False positive analysis - -- Known benign processes such as gnome-keyring-daemon and abrt-dbus may trigger the rule. Users can exclude these processes by adding them to the exception list in the detection rule. -- Processes executed from common library paths like /usr/lib/ or /usr/local/lib/ are typically non-threatening. Users should review these paths and consider excluding them if they are consistently generating false positives. -- The dbus-daemon with the --session argument is generally safe. Users can ensure this argument is included in the exception criteria to prevent unnecessary alerts. -- Specific applications like software-properties-dbus and serviceHelper.py are known to be benign. Users should verify these applications' legitimacy in their environment and exclude them if they are frequently flagged. -- Regularly review and update the exception list to include any new benign processes or paths that are identified over time, ensuring the rule remains effective without generating excessive false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious child processes spawned by the dbus-daemon that are not recognized as legitimate or necessary for system operations. -- Conduct a thorough review of the affected system's logs to identify any unauthorized access or changes made by the suspicious process. -- Restore any altered or compromised system files from a known good backup to ensure system integrity. -- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. -- Implement stricter access controls and monitoring on the dbus-daemon to prevent unauthorized process execution in the future. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml index 44b04b6286d..bbf353ca4cf 100644 --- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml +++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml @@ -2,9 +2,7 @@ creation_date = "2024/06/25" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/24" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -20,6 +18,42 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg language = "eql" license = "Elastic License v2" name = "DNF Package Manager Plugin 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 DNF Package Manager Plugin File Creation + +DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*". +- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria. +- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx". +- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior. +- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates. +- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise. +- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat. + +### False positive analysis + +- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule. +- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list. +- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria. +- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives. +- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes. +- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager. +- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots. +- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker. +- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation.""" references = [ "https://pwnshift.github.io/2020/10/01/persistence.html", "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms", @@ -91,42 +125,6 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/* process.name like~ ("ssm-agent-worker, NinjaOrbit", "python*") ) ''' -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 DNF Package Manager Plugin File Creation - -DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities. - -### Possible investigation steps - -- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*". -- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria. -- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx". -- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior. -- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates. -- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise. -- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat. - -### False positive analysis - -- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule. -- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list. -- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria. -- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives. -- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. -- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes. -- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager. -- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots. -- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker. -- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms. -- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation.""" [[rule.threat]] diff --git a/rules/linux/persistence_dracut_module_creation.toml b/rules/linux/persistence_dracut_module_creation.toml index 80ce775951a..7f2207cd93f 100644 --- a/rules/linux/persistence_dracut_module_creation.toml +++ b/rules/linux/persistence_dracut_module_creation.toml @@ -2,23 +2,56 @@ creation_date = "2025/01/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an -initramfs image that is used to boot the system. Dracut modules are scripts that are executed during the -initramfs image generation process. Attackers may create malicious Dracut modules to execute arbitrary code -at boot time, which can be leveraged to maintain persistence on a Linux system. +This rule detects the creation of Dracut module files on Linux systems. Dracut is a tool used to generate an initramfs +image that is used to boot the system. Dracut modules are scripts that are executed during the initramfs image +generation process. Attackers may create malicious Dracut modules to execute arbitrary code at boot time, which can be +leveraged to maintain persistence on a Linux system. """ from = "now-9m" index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] language = "eql" license = "Elastic License v2" name = "Dracut Module 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 Dracut Module Creation + +Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats. + +### Possible investigation steps + +- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*". +- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process. +- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove". +- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity. +- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert. + +### False positive analysis + +- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts. +- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening. +- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts. +- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules. +- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes. +- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities. +- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident.""" risk_score = 21 rule_id = "dc765fb2-0c99-4e57-8c11-dafdf1992b66" setup = """## Setup @@ -57,6 +90,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and not ( @@ -81,45 +115,10 @@ file.path like~ ("/lib/dracut/modules.d/*", "/usr/lib/dracut/modules.d/*") and n (process.name == "sed" and file.name : "sed*") ) ''' -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 Dracut Module Creation - -Dracut is a utility for generating initramfs images, crucial for booting Linux systems. It uses modules, which are scripts executed during image creation. Adversaries may exploit this by crafting malicious modules to execute code at boot, ensuring persistence. The detection rule identifies unauthorized module creation by monitoring file paths and excluding known legitimate processes, helping to flag potential threats. - -### Possible investigation steps - -- Review the file path of the created Dracut module to determine if it matches known legitimate paths or if it appears suspicious, focusing on paths like "/lib/dracut/modules.d/*" and "/usr/lib/dracut/modules.d/*". -- Identify the process that created the Dracut module by examining the process.executable field, and verify if it is listed in the known legitimate processes or if it is an unexpected process. -- Check the file extension of the created module to ensure it is not one of the excluded extensions such as "swp", "swpx", "swx", or "dpkg-remove". -- Investigate the history and behavior of the process that created the module, including its parent process and any associated network activity, to assess if it has been involved in other suspicious activities. -- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that might suggest malicious activity. -- Consult threat intelligence sources to determine if there are any known threats or campaigns associated with the process or file path involved in the alert. - -### False positive analysis - -- Package managers like dpkg, rpm, and yum may trigger false positives when they update or install packages. To handle this, ensure these processes are included in the exclusion list within the detection rule. -- Automated system management tools such as Puppet, Chef, and Ansible can create or modify Dracut modules as part of their configuration management tasks. Add these tools to the exclusion list to prevent false alerts. -- System updates or maintenance scripts that run as part of regular system operations might be flagged. Review these scripts and add their executables to the exclusion list if they are verified as non-threatening. -- Custom scripts or applications that interact with Dracut modules for legitimate purposes should be reviewed and, if deemed safe, added to the exclusion list to avoid unnecessary alerts. -- Temporary files or backup files with extensions like swp or dpkg-remove may be mistakenly flagged. Ensure these extensions are included in the exclusion criteria to reduce false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. -- Conduct a thorough review of the Dracut module files located in the specified directories (/lib/dracut/modules.d/*, /usr/lib/dracut/modules.d/*) to identify and remove any unauthorized or suspicious modules. -- Restore the system from a known good backup if malicious Dracut modules are confirmed, ensuring that the backup predates the unauthorized changes. -- Implement additional monitoring on the affected system to detect any further unauthorized Dracut module creation or other suspicious activities. -- Review and tighten access controls and permissions for the directories and processes involved in Dracut module creation to prevent unauthorized modifications. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Update and enhance detection capabilities to include alerts for any future unauthorized Dracut module creation attempts, leveraging the specific indicators identified in this incident.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" @@ -135,29 +134,28 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -165,3 +163,4 @@ framework = "MITRE ATT&CK" id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/persistence_dynamic_linker_backup.toml b/rules/linux/persistence_dynamic_linker_backup.toml index c59e3a57064..4908718e419 100644 --- a/rules/linux/persistence_dynamic_linker_backup.toml +++ b/rules/linux/persistence_dynamic_linker_backup.toml @@ -2,9 +2,7 @@ creation_date = "2022/07/12" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] diff --git a/rules/linux/persistence_extract_initramfs_via_cpio.toml b/rules/linux/persistence_extract_initramfs_via_cpio.toml index bd4c2e51b40..f5ab24a7a21 100644 --- a/rules/linux/persistence_extract_initramfs_via_cpio.toml +++ b/rules/linux/persistence_extract_initramfs_via_cpio.toml @@ -2,16 +2,14 @@ creation_date = "2025/01/16" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the extraction of an initramfs image using the `cpio` command on Linux systems. The -`cpio` command is used to create or extract cpio archives. Attackers may extract the initramfs image to -modify the contents or add malicious files, which can be leveraged to maintain persistence on the system. +This rule detects the extraction of an initramfs image using the `cpio` command on Linux systems. The `cpio` command is +used to create or extract cpio archives. Attackers may extract the initramfs image to modify the contents or add +malicious files, which can be leveraged to maintain persistence on the system. """ from = "now-9m" index = [ @@ -20,11 +18,45 @@ index = [ "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", - "logs-sentinel_one_cloud_funnel.*" + "logs-sentinel_one_cloud_funnel.*", ] language = "eql" license = "Elastic License v2" name = "Initramfs Extraction via CPIO" +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 Initramfs Extraction via CPIO + +Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive. +- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded. +- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*". +- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism. +- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files. +- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat. + +### False positive analysis + +- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut. +- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe. +- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly. +- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. +- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`. +- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files. +- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms. +- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats.""" risk_score = 21 rule_id = "17b3fcd1-90fb-4f5d-858c-dc1d998fa368" setup = """## Setup @@ -63,6 +95,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and @@ -71,44 +104,10 @@ process.name == "cpio" and process.args in ("-H", "--format") and process.args = process.parent.executable like~ ("/usr/share/initramfs-tools/*", "/nix/store/*") ) ''' -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 Initramfs Extraction via CPIO - -Initramfs is a temporary filesystem used during the Linux boot process, containing essential drivers and scripts. Attackers may exploit the `cpio` command to extract and modify initramfs, embedding malicious files to ensure persistence. The detection rule identifies suspicious `cpio` usage by monitoring process execution patterns, excluding legitimate parent processes, to flag potential threats. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the cpio command with arguments "-H" or "--format" and "newc" to ensure the alert is not a false positive. -- Investigate the parent process of the cpio command to determine if it is an unexpected or unauthorized process, as legitimate processes like mkinitramfs or dracut should be excluded. -- Check the execution path of the parent process to verify if it matches any known legitimate paths such as "/usr/share/initramfs-tools/*" or "/nix/store/*". -- Analyze the timeline of events around the cpio execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or persistence mechanism. -- Examine the system for any unauthorized modifications or additions to the initramfs image that could indicate tampering or the presence of malicious files. -- Correlate the alert with other security data sources like Elastic Endgame, Elastic Defend, or Crowdstrike to gather additional context and assess the scope of the potential threat. - -### False positive analysis - -- Legitimate system updates or maintenance activities may trigger the rule when tools like mkinitramfs or dracut are used. To handle this, ensure these processes are excluded by verifying that the parent process is mkinitramfs or dracut. -- Custom scripts or automation tools that manage initramfs might use cpio in a non-malicious context. Review these scripts and add their parent process names or paths to the exclusion list if they are verified as safe. -- Systems using non-standard initramfs management tools located in directories like /usr/share/initramfs-tools or /nix/store may cause false positives. Confirm these tools' legitimacy and update the exclusion paths accordingly. -- Development or testing environments where initramfs is frequently modified for legitimate reasons can generate alerts. Consider creating environment-specific exceptions to reduce noise while maintaining security in production systems. - -### Response and remediation - -- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. -- Terminate any suspicious processes related to the `cpio` command that do not have legitimate parent processes, such as `mkinitramfs` or `dracut`. -- Conduct a thorough review of the extracted initramfs contents to identify and remove any unauthorized or malicious files. -- Restore the initramfs from a known good backup to ensure system integrity and remove any potential persistence mechanisms. -- Monitor the system for any further suspicious activity, particularly related to the `cpio` command, to ensure the threat has been fully mitigated. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. -- Update security policies and procedures to include specific checks for unauthorized `cpio` usage and enhance detection capabilities for similar threats.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" @@ -124,7 +123,9 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml index ca06e3deee9..afd3c5fe188 100644 --- a/rules/linux/persistence_git_hook_execution.toml +++ b/rules/linux/persistence_git_hook_execution.toml @@ -2,9 +2,7 @@ creation_date = "2024/07/15" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,6 +16,41 @@ index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Git Hook Command Execution" +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 Git Hook Command Execution + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems. + +### Possible investigation steps + +- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields. +- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated. +- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise. +- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command. +- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise. +- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms. + +### False positive analysis + +- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes. +- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious. +- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them. +- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions. +- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity. +- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only.""" references = [ "https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git", "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms", @@ -72,41 +105,6 @@ sequence by host.id with maxspan=3s [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id ''' -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 Git Hook Command Execution - -Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems. - -### Possible investigation steps - -- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields. -- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated. -- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts. -- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise. -- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command. -- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise. -- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms. - -### False positive analysis - -- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes. -- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious. -- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them. -- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. -- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions. -- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. -- Restore any modified or deleted files from a known good backup to ensure system integrity. -- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only.""" [[rule.threat]] diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml index 3ba54dfdbdc..98e9a56dc87 100644 --- a/rules/linux/persistence_git_hook_file_creation.toml +++ b/rules/linux/persistence_git_hook_file_creation.toml @@ -2,9 +2,7 @@ creation_date = "2024/06/26" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,41 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg language = "eql" license = "Elastic License v2" name = "Git Hook Created or Modified" +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 Git Hook Created or Modified + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse. + +### Possible investigation steps + +- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system. +- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query. +- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook. +- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes. +- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule. +- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts. +- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria. +- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts. +- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code. +- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule. +- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes. +- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms. +- Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users.""" references = [ "https://git-scm.com/docs/githooks/2.26.0", "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms", @@ -85,45 +118,10 @@ file.extension == null and process.executable != null and not ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' -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 Git Hook Created or Modified - -Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse. - -### Possible investigation steps - -- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system. -- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query. -- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook. -- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious. -- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes. -- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise. - -### False positive analysis - -- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule. -- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts. -- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria. -- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts. -- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code. -- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule. -- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes. -- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms. -- Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" @@ -134,29 +132,28 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -164,3 +161,4 @@ framework = "MITRE ATT&CK" id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml index dd246b05bf3..d94e5860c5a 100644 --- a/rules/linux/persistence_git_hook_process_execution.toml +++ b/rules/linux/persistence_git_hook_process_execution.toml @@ -2,9 +2,7 @@ creation_date = "2024/06/26" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,50 @@ spawned by the Git process itself. This behavior may indicate an attacker attemp leveraging the legitimate Git process to execute unauthorized commands. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] +index = [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", + "endgame-*", +] language = "eql" license = "Elastic License v2" name = "Git Hook Child Process" +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 Git Hook Child Process + +Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process. +- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed. +- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful. +- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner. +- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise. +- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks. + +### False positive analysis + +- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers. +- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows. +- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening. +- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities. +- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables. +- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations. +- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks. +- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.""" references = [ "https://git-scm.com/docs/githooks/2.26.0", "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms", @@ -86,41 +124,6 @@ process where host.os.type == "linux" and event.type == "start" and ) and not process.name in ("git", "dirname") ''' -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 Git Hook Child Process - -Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse. - -### Possible investigation steps - -- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process. -- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed. -- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful. -- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner. -- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise. -- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks. - -### False positive analysis - -- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers. -- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows. -- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening. -- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities. -- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands. -- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables. -- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts. -- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations. -- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks. -- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.""" [[rule.threat]] diff --git a/rules/linux/persistence_grub_configuration_creation.toml b/rules/linux/persistence_grub_configuration_creation.toml index 44f71f9b107..c5e5b0ff394 100644 --- a/rules/linux/persistence_grub_configuration_creation.toml +++ b/rules/linux/persistence_grub_configuration_creation.toml @@ -2,23 +2,56 @@ creation_date = "2025/01/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This rule detects the creation of GRUB configuration files on Linux systems. The GRUB configuration file is used to -configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious -GRUB configuration files to execute arbitrary code or escalate privileges during the boot process, which can be -leveraged to maintain persistence on the system. +configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious GRUB +configuration files to execute arbitrary code or escalate privileges during the boot process, which can be leveraged to +maintain persistence on the system. """ from = "now-9m" index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] language = "eql" license = "Elastic License v2" name = "GRUB Configuration 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 GRUB Configuration File Creation + +GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats. + +### Possible investigation steps + +- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg"). +- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes. +- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time. +- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent. +- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment. +- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup. +- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts. +- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access. +- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced. +- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials. +- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications.""" risk_score = 21 rule_id = "ce4a32e5-32aa-47e6-80da-ced6d234387d" setup = """## Setup @@ -57,6 +90,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.path like~ ( "/etc/default/grub.d/*", "/etc/default/grub", "/etc/grub.d/*", @@ -84,45 +118,10 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec (process.name == "sed" and file.name : "sed*") ) ''' -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 GRUB Configuration File Creation - -GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats. - -### Possible investigation steps - -- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg"). -- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes. -- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time. -- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior. -- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent. -- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise. - -### False positive analysis - -- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule. -- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment. -- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup. -- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts. -- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access. -- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary. -- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced. -- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials. -- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" @@ -138,7 +137,9 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_grub_makeconfig.toml b/rules/linux/persistence_grub_makeconfig.toml index 9b8d543986e..23b192d4459 100644 --- a/rules/linux/persistence_grub_makeconfig.toml +++ b/rules/linux/persistence_grub_makeconfig.toml @@ -2,9 +2,7 @@ creation_date = "2025/01/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,48 @@ during the boot process. Attackers may use these built-in utilities to generate includes malicious kernel parameters or boot options, which can be leveraged to maintain persistence on the system. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "endgame-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "logs-endpoint.events.process*", + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "GRUB Configuration Generation through Built-in Utilities" +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 GRUB Configuration Generation through Built-in Utilities + +GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse. + +### Possible investigation steps + +- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list. +- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options. +- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications. +- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context. + +### False positive analysis + +- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration. +- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria. +- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions. +- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes. +- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present. +- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities. +- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only.""" risk_score = 21 rule_id = "aabdad51-51fb-4a66-9d82-3873e42accb8" setup = """## Setup @@ -56,6 +92,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -66,43 +103,10 @@ process.parent.executable != null and process.name in ("grub-mkconfig", "grub2-m ) ) ''' -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 GRUB Configuration Generation through Built-in Utilities - -GRUB, the Grand Unified Bootloader, is crucial for loading the Linux kernel during system startup. It uses configuration files to determine boot parameters. Adversaries may exploit utilities like `grub-mkconfig` to alter these files, embedding malicious parameters for persistence. The detection rule identifies suspicious executions of these utilities, especially when initiated by atypical parent processes, signaling potential misuse. - -### Possible investigation steps -- Review the process execution details to identify the parent process of the suspicious GRUB configuration utility execution. Check if the parent process is unusual or unexpected based on the query's exclusion list. -- Examine the command-line arguments used in the execution of the GRUB configuration utility to identify any potentially malicious kernel parameters or boot options. -- Investigate the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. -- Check the system's recent changes or updates, especially those related to bootloader configurations, to identify any unauthorized modifications. -- Analyze system logs for any other suspicious activities or anomalies around the time of the GRUB configuration utility execution to gather additional context. - -### False positive analysis - -- Routine system updates or maintenance tasks may trigger the rule when legitimate processes like package managers (e.g., pacman, dnf, yum) or system utilities (e.g., sudo) execute GRUB configuration commands. Users can mitigate this by adding these processes to the exception list in the rule configuration. -- Automated scripts or cron jobs that regularly update GRUB configurations for legitimate reasons might be flagged. To handle this, identify these scripts and add their parent process names or paths to the exclusion criteria. -- Custom administrative scripts that manage bootloader settings could also cause false positives. Review these scripts and, if verified as safe, include their parent process details in the rule's exceptions. -- Some Linux distributions may have specific utilities or services that interact with GRUB as part of their normal operation. Investigate these utilities and consider excluding them if they are confirmed to be benign and necessary for system functionality. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. -- Terminate any suspicious processes related to `grub-mkconfig`, `grub2-mkconfig`, or `update-grub` that were initiated by atypical parent processes. -- Review and restore the GRUB configuration file from a known good backup to ensure no malicious parameters are present. -- Conduct a thorough examination of the system for additional signs of compromise, focusing on persistence mechanisms and unauthorized changes to boot parameters. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. -- Implement monitoring for future unauthorized executions of GRUB configuration utilities, ensuring alerts are generated for similar suspicious activities. -- Review and update access controls and permissions to restrict the execution of GRUB configuration utilities to authorized personnel only.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" @@ -118,7 +122,9 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_init_d_file_creation.toml b/rules/linux/persistence_init_d_file_creation.toml index b268ef38aac..9596e5bce38 100644 --- a/rules/linux/persistence_init_d_file_creation.toml +++ b/rules/linux/persistence_init_d_file_creation.toml @@ -2,9 +2,7 @@ creation_date = "2023/03/21" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -179,15 +177,18 @@ and file.path : "/etc/init.d/*" and not ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' + + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1037" name = "Boot or Logon Initialization Scripts" reference = "https://attack.mitre.org/techniques/T1037/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_insmod_kernel_module_load.toml b/rules/linux/persistence_insmod_kernel_module_load.toml index be9b7a9fe67..cf26c1d712a 100644 --- a/rules/linux/persistence_insmod_kernel_module_load.toml +++ b/rules/linux/persistence_insmod_kernel_module_load.toml @@ -2,9 +2,7 @@ creation_date = "2022/07/11" integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -41,7 +39,13 @@ security products. Manually loading a kernel module in this manner should not be suspcious or malicious behavior. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Kernel Module Load via insmod" @@ -162,6 +166,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and process.name == "insmod" and process.args : "*.ko" and not process.parent.executable like ( @@ -170,20 +175,22 @@ not process.parent.executable like ( ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1547" name = "Boot or Logon Autostart Execution" reference = "https://attack.mitre.org/techniques/T1547/" - [[rule.threat.technique.subtechnique]] id = "T1547.006" name = "Kernel Modules and Extensions" reference = "https://attack.mitre.org/techniques/T1547/006/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_kde_autostart_modification.toml b/rules/linux/persistence_kde_autostart_modification.toml index 9fd2b9acc31..83b65a7ba7b 100644 --- a/rules/linux/persistence_kde_autostart_modification.toml +++ b/rules/linux/persistence_kde_autostart_modification.toml @@ -2,9 +2,7 @@ creation_date = "2021/01/06" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -232,15 +230,17 @@ file where host.os.type == "linux" and event.type != "deletion" and ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1547" name = "Boot or Logon Autostart Execution" reference = "https://attack.mitre.org/techniques/T1547/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_kworker_file_creation.toml b/rules/linux/persistence_kworker_file_creation.toml index 79e32fb1943..d5e19a63317 100644 --- a/rules/linux/persistence_kworker_file_creation.toml +++ b/rules/linux/persistence_kworker_file_creation.toml @@ -2,9 +2,7 @@ creation_date = "2023/10/26" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -167,6 +165,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and process.name : "kworker*" and not ( @@ -181,28 +180,29 @@ file where host.os.type == "linux" and event.action in ("creation", "file_create ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1547" name = "Boot or Logon Autostart Execution" reference = "https://attack.mitre.org/techniques/T1547/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1014" name = "Rootkit" reference = "https://attack.mitre.org/techniques/T1014/" + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/persistence_linux_backdoor_user_creation.toml b/rules/linux/persistence_linux_backdoor_user_creation.toml index 70a01525ea2..40dd37a98c1 100644 --- a/rules/linux/persistence_linux_backdoor_user_creation.toml +++ b/rules/linux/persistence_linux_backdoor_user_creation.toml @@ -2,9 +2,7 @@ creation_date = "2023/03/07" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -38,7 +36,14 @@ Identifies the attempt to create a new backdoor user by setting the user's UID t 0 to establish persistence on a system. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Linux Backdoor User Account Creation" diff --git a/rules/linux/persistence_linux_shell_activity_via_web_server.toml b/rules/linux/persistence_linux_shell_activity_via_web_server.toml index 75ef6bee4a2..3ad4f9a155f 100644 --- a/rules/linux/persistence_linux_shell_activity_via_web_server.toml +++ b/rules/linux/persistence_linux_shell_activity_via_web_server.toml @@ -2,9 +2,7 @@ creation_date = "2023/03/04" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] diff --git a/rules/linux/persistence_linux_user_added_to_privileged_group.toml b/rules/linux/persistence_linux_user_added_to_privileged_group.toml index 192d6627424..da38cb65f9b 100644 --- a/rules/linux/persistence_linux_user_added_to_privileged_group.toml +++ b/rules/linux/persistence_linux_user_added_to_privileged_group.toml @@ -2,9 +2,7 @@ creation_date = "2023/02/13" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -31,7 +29,14 @@ Identifies attempts to add a user to a privileged group. Attackers may add users establish persistence on a system. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Linux User Added to Privileged Group" @@ -124,6 +129,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and @@ -136,20 +142,22 @@ process where host.os.type == "linux" and event.type == "start" and ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1136" name = "Create Account" reference = "https://attack.mitre.org/techniques/T1136/" - [[rule.threat.technique.subtechnique]] id = "T1136.001" name = "Local Account" reference = "https://attack.mitre.org/techniques/T1136/001/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_manual_dracut_execution.toml b/rules/linux/persistence_manual_dracut_execution.toml index 260b43dcdab..afc04702740 100644 --- a/rules/linux/persistence_manual_dracut_execution.toml +++ b/rules/linux/persistence_manual_dracut_execution.toml @@ -2,22 +2,58 @@ creation_date = "2025/01/16" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This rule detects manual execution of the `dracut` command on Linux systems. Dracut is a tool used to generate an -initramfs image that is used to boot the system. Attackers may use `dracut` to create a custom initramfs image -that includes malicious code or backdoors, allowing them to maintain persistence on the system. +initramfs image that is used to boot the system. Attackers may use `dracut` to create a custom initramfs image that +includes malicious code or backdoors, allowing them to maintain persistence on the system. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Manual Dracut Execution" +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 Manual Dracut Execution + +Dracut is a utility in Linux systems used to create initramfs images, essential for booting. Adversaries might exploit Dracut to craft malicious initramfs, embedding backdoors for persistence. The detection rule identifies unusual Dracut executions by scrutinizing process origins and excluding legitimate parent processes, flagging potential unauthorized use. + +### Possible investigation steps + +- Review the process details to confirm the execution of the dracut command, focusing on the process.name and process.parent.executable fields to identify any unusual parent processes. +- Examine the command line arguments used with the dracut process by checking the process.parent.command_line field to understand the context of its execution. +- Investigate the user account associated with the dracut execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Check the system logs and any related security alerts around the time of the dracut execution to identify any correlated suspicious activities or anomalies. +- Assess the system for any changes to the initramfs image or other boot-related files that could indicate tampering or the presence of backdoors. + +### False positive analysis + +- Legitimate system updates or kernel installations may trigger the rule. To handle this, users can create exceptions for processes originating from known update paths like /usr/lib/kernel/* or /etc/kernel/install.d/*. +- Automated scripts or maintenance tasks that use dracut for legitimate purposes might be flagged. Users should identify these scripts and add their parent process names, such as dracut-install or run-parts, to the exclusion list. +- Custom administrative scripts executed by trusted users could be mistaken for suspicious activity. Users can exclude specific command lines or arguments associated with these scripts, such as /usr/bin/dracut-rebuild, to prevent false positives. +- Temporary or testing environments where dracut is used for non-malicious testing purposes might trigger alerts. Users can exclude these environments by specifying unique parent process paths or names that are characteristic of the testing setup. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious or unauthorized dracut processes identified on the system to halt any ongoing malicious activity. +- Conduct a thorough review of the initramfs images on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore the system's initramfs from a known good backup to ensure the integrity of the boot process. +- Implement monitoring for any future unauthorized dracut executions by setting up alerts for similar process activities, ensuring quick detection and response. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions to limit the ability to execute dracut to only authorized personnel, reducing the risk of future exploitation.""" risk_score = 21 rule_id = "834ee026-f9f9-4ec7-b5e0-7fbfe84765f4" setup = """## Setup @@ -60,6 +96,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -75,67 +112,35 @@ process.name == "dracut" and process.parent.executable != null and not ( process.parent.command_line like~ "/bin/sh -c if command -v mkinitcpio*" ) ''' -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 Manual Dracut Execution - -Dracut is a utility in Linux systems used to create initramfs images, essential for booting. Adversaries might exploit Dracut to craft malicious initramfs, embedding backdoors for persistence. The detection rule identifies unusual Dracut executions by scrutinizing process origins and excluding legitimate parent processes, flagging potential unauthorized use. - -### Possible investigation steps - -- Review the process details to confirm the execution of the dracut command, focusing on the process.name and process.parent.executable fields to identify any unusual parent processes. -- Examine the command line arguments used with the dracut process by checking the process.parent.command_line field to understand the context of its execution. -- Investigate the user account associated with the dracut execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. -- Check the system logs and any related security alerts around the time of the dracut execution to identify any correlated suspicious activities or anomalies. -- Assess the system for any changes to the initramfs image or other boot-related files that could indicate tampering or the presence of backdoors. - -### False positive analysis - -- Legitimate system updates or kernel installations may trigger the rule. To handle this, users can create exceptions for processes originating from known update paths like /usr/lib/kernel/* or /etc/kernel/install.d/*. -- Automated scripts or maintenance tasks that use dracut for legitimate purposes might be flagged. Users should identify these scripts and add their parent process names, such as dracut-install or run-parts, to the exclusion list. -- Custom administrative scripts executed by trusted users could be mistaken for suspicious activity. Users can exclude specific command lines or arguments associated with these scripts, such as /usr/bin/dracut-rebuild, to prevent false positives. -- Temporary or testing environments where dracut is used for non-malicious testing purposes might trigger alerts. Users can exclude these environments by specifying unique parent process paths or names that are characteristic of the testing setup. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. -- Terminate any suspicious or unauthorized dracut processes identified on the system to halt any ongoing malicious activity. -- Conduct a thorough review of the initramfs images on the affected system to identify and remove any unauthorized or malicious modifications. -- Restore the system's initramfs from a known good backup to ensure the integrity of the boot process. -- Implement monitoring for any future unauthorized dracut executions by setting up alerts for similar process activities, ensuring quick detection and response. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. -- Review and update access controls and permissions to limit the ability to execute dracut to only authorized personnel, reducing the risk of future exploitation.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" reference = "https://attack.mitre.org/techniques/T1542/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/persistence_message_of_the_day_execution.toml b/rules/linux/persistence_message_of_the_day_execution.toml index ec84b27f6b7..bd5ad825aa5 100644 --- a/rules/linux/persistence_message_of_the_day_execution.toml +++ b/rules/linux/persistence_message_of_the_day_execution.toml @@ -2,9 +2,7 @@ creation_date = "2023/02/28" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/03" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -32,15 +30,15 @@ query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.u label = "Osquery - Retrieve Crontab Information" query = "SELECT * FROM crontab" + [rule] author = ["Elastic"] description = """ Message of the day (MOTD) is the message that is presented to the user when a user connects to a Linux server via SSH or a serial connection. Linux systems contain several default MOTD files located in the "/etc/update-motd.d/" directory. These scripts run as the root user every time a user connects over SSH or a serial connection. Adversaries may create -malicious MOTD files that grant them persistence onto the target every time a user connects to the system by executing -a backdoor script or command. This rule detects the execution of potentially malicious processes through the MOTD -utility. +malicious MOTD files that grant them persistence onto the target every time a user connects to the system by executing a +backdoor script or command. This rule detects the execution of potentially malicious processes through the MOTD utility. """ from = "now-9m" index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"] @@ -148,6 +146,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where event.type == "start" and host.os.type == "linux" and event.action : ("exec", "exec_event", "start") and process.parent.executable : "/etc/update-motd.d/*" and @@ -200,15 +199,17 @@ process where event.type == "start" and host.os.type == "linux" and event.action ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1037" name = "Boot or Logon Initialization Scripts" reference = "https://attack.mitre.org/techniques/T1037/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_network_manager_dispatcher_persistence.toml b/rules/linux/persistence_network_manager_dispatcher_persistence.toml index c0f3fb5b5f2..ff3fc273f41 100644 --- a/rules/linux/persistence_network_manager_dispatcher_persistence.toml +++ b/rules/linux/persistence_network_manager_dispatcher_persistence.toml @@ -2,23 +2,55 @@ creation_date = "2025/01/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This rule detects the creation of a NetworkManager dispatcher script on a Linux system. NetworkManager dispatcher -scripts are shell scripts that NetworkManager executes when network interfaces change state. Attackers can -abuse NetworkManager dispatcher scripts to maintain persistence on a system by executing malicious code -whenever a network event occurs. +scripts are shell scripts that NetworkManager executes when network interfaces change state. Attackers can abuse +NetworkManager dispatcher scripts to maintain persistence on a system by executing malicious code whenever a network +event occurs. """ from = "now-9m" index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] language = "eql" license = "Elastic License v2" name = "NetworkManager Dispatcher Script 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 NetworkManager Dispatcher Script Creation + +NetworkManager dispatcher scripts are executed on Linux systems when network interfaces change state, allowing for automated responses to network events. Adversaries can exploit this by creating scripts that execute malicious code, ensuring persistence and evasion. The detection rule identifies unauthorized script creation by monitoring file creation events in the dispatcher directory, excluding known legitimate processes and file types, thus highlighting potential abuse. + +### Possible investigation steps + +- Review the file creation event details to identify the specific script created in the /etc/NetworkManager/dispatcher.d/ directory, noting the file path and name. +- Examine the process that created the script by checking the process.executable field to determine if it is an unexpected or suspicious process not listed in the known legitimate processes. +- Investigate the contents of the newly created script to identify any potentially malicious code or commands that could indicate an attempt to maintain persistence or execute unauthorized actions. +- Check the system's recent network events and changes to see if the script has been triggered and executed, which could provide further context on its intended use. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. + +### False positive analysis + +- Package management tools like dpkg, rpm, and yum may trigger false positives when they create or modify dispatcher scripts during software installations or updates. To handle these, ensure that the process executables for these tools are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they deploy or update configurations. Verify that the executables for these tools are part of the exclusion criteria to prevent unnecessary alerts. +- Temporary files created by text editors like Vim may be mistakenly flagged. These files typically have extensions like swp or swpx. Ensure these extensions are included in the exclusion list to avoid false positives. +- Custom scripts or applications that are known to create or modify dispatcher scripts for legitimate purposes should be reviewed. If deemed safe, add their process executables to the exclusion list to prevent them from being flagged. +- Consider monitoring the frequency and context of script creation events. If certain scripts are frequently created by known processes, evaluate the need to adjust the rule to reduce noise while maintaining security efficacy. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's ability to maintain persistence. +- Review and remove any unauthorized scripts found in the /etc/NetworkManager/dispatcher.d/ directory to eliminate the immediate threat. +- Conduct a thorough examination of the system for additional signs of compromise, such as unexpected processes or network connections, to identify any further malicious activity. +- Restore any affected systems from a known good backup to ensure the removal of any persistent threats that may have been established. +- Implement stricter access controls and monitoring on the /etc/NetworkManager/dispatcher.d/ directory to prevent unauthorized script creation in the future. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats, leveraging the MITRE ATT&CK framework for guidance on persistence and execution techniques.""" risk_score = 21 rule_id = "86aa8579-1526-4dff-97cd-3635eb0e0545" setup = """## Setup @@ -61,6 +93,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and file.path like~ "/etc/NetworkManager/dispatcher.d/*" and not ( process.executable in ( @@ -84,44 +117,10 @@ file where host.os.type == "linux" and event.type == "creation" and file.path li (process.name == "sed" and file.name : "sed*") ) ''' -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 NetworkManager Dispatcher Script Creation - -NetworkManager dispatcher scripts are executed on Linux systems when network interfaces change state, allowing for automated responses to network events. Adversaries can exploit this by creating scripts that execute malicious code, ensuring persistence and evasion. The detection rule identifies unauthorized script creation by monitoring file creation events in the dispatcher directory, excluding known legitimate processes and file types, thus highlighting potential abuse. - -### Possible investigation steps - -- Review the file creation event details to identify the specific script created in the /etc/NetworkManager/dispatcher.d/ directory, noting the file path and name. -- Examine the process that created the script by checking the process.executable field to determine if it is an unexpected or suspicious process not listed in the known legitimate processes. -- Investigate the contents of the newly created script to identify any potentially malicious code or commands that could indicate an attempt to maintain persistence or execute unauthorized actions. -- Check the system's recent network events and changes to see if the script has been triggered and executed, which could provide further context on its intended use. -- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. - -### False positive analysis - -- Package management tools like dpkg, rpm, and yum may trigger false positives when they create or modify dispatcher scripts during software installations or updates. To handle these, ensure that the process executables for these tools are included in the exclusion list within the detection rule. -- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they deploy or update configurations. Verify that the executables for these tools are part of the exclusion criteria to prevent unnecessary alerts. -- Temporary files created by text editors like Vim may be mistakenly flagged. These files typically have extensions like swp or swpx. Ensure these extensions are included in the exclusion list to avoid false positives. -- Custom scripts or applications that are known to create or modify dispatcher scripts for legitimate purposes should be reviewed. If deemed safe, add their process executables to the exclusion list to prevent them from being flagged. -- Consider monitoring the frequency and context of script creation events. If certain scripts are frequently created by known processes, evaluate the need to adjust the rule to reduce noise while maintaining security efficacy. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's ability to maintain persistence. -- Review and remove any unauthorized scripts found in the /etc/NetworkManager/dispatcher.d/ directory to eliminate the immediate threat. -- Conduct a thorough examination of the system for additional signs of compromise, such as unexpected processes or network connections, to identify any further malicious activity. -- Restore any affected systems from a known good backup to ensure the removal of any persistent threats that may have been established. -- Implement stricter access controls and monitoring on the /etc/NetworkManager/dispatcher.d/ directory to prevent unauthorized script creation in the future. -- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. -- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats, leveraging the MITRE ATT&CK framework for guidance on persistence and execution techniques.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" @@ -132,29 +131,28 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -162,3 +160,4 @@ framework = "MITRE ATT&CK" id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/persistence_openssl_passwd_hash_generation.toml b/rules/linux/persistence_openssl_passwd_hash_generation.toml index f4dd830d1de..4b121002a06 100644 --- a/rules/linux/persistence_openssl_passwd_hash_generation.toml +++ b/rules/linux/persistence_openssl_passwd_hash_generation.toml @@ -2,23 +2,63 @@ creation_date = "2025/01/16" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects the usage of the `openssl` binary to generate password hashes on Linux systems. The `openssl` command is a -cryptographic utility that can be used to generate password hashes. Attackers may use `openssl` to generate password hashes -for new user accounts or to change the password of existing accounts, which can be leveraged to maintain persistence -on a Linux system. +This rule detects the usage of the `openssl` binary to generate password hashes on Linux systems. The `openssl` command +is a cryptographic utility that can be used to generate password hashes. Attackers may use `openssl` to generate +password hashes for new user accounts or to change the password of existing accounts, which can be leveraged to maintain +persistence on a Linux system. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "logs-endpoint.events.process*", + "endgame-*", + "auditbeat-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "OpenSSL Password Hash Generation" +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 OpenSSL Password Hash Generation + +OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash. +- Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary. +- Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts. +- Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert. +- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly. +- Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. +- Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts. +- Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise. +- Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications. +- Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid. +- Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems. +- Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations.""" risk_score = 21 rule_id = "f4b857b3-faef-430d-b420-90be48647f00" setup = """## Setup @@ -61,61 +101,29 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "openssl" and process.args == "passwd" ''' -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 OpenSSL Password Hash Generation - -OpenSSL is a robust cryptographic toolkit used for secure communications and data protection, including generating password hashes. Adversaries may exploit OpenSSL to create hashes for unauthorized user accounts or modify existing ones, aiding in persistent access to Linux systems. The detection rule identifies suspicious OpenSSL executions by monitoring specific process actions and arguments, flagging potential misuse for further investigation. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the "openssl" command with the "passwd" argument, as this indicates an attempt to generate a password hash. -- Identify the user account associated with the process execution to determine if the action was performed by a legitimate user or a potential adversary. -- Check the system logs and user activity around the time of the alert to identify any suspicious behavior or unauthorized access attempts. -- Investigate any recent changes to user accounts on the system, focusing on new account creations or password modifications that coincide with the alert. -- Correlate the alert with other security events or alerts from the same host to identify patterns or additional indicators of compromise. -- Assess the risk and impact of the detected activity by considering the context of the system and its role within the organization, as well as any potential data exposure or system access implications. - -### False positive analysis - -- Routine administrative tasks may trigger the rule when system administrators use OpenSSL to generate password hashes for legitimate user account management. To handle this, create exceptions for specific administrator accounts or processes that are known to perform these tasks regularly. -- Automated scripts for user account provisioning or maintenance that utilize OpenSSL for password hashing can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. -- Security tools or compliance checks that periodically verify password strength or integrity using OpenSSL might be flagged. Review these tools and whitelist their operations to prevent unnecessary alerts. -- Development environments where OpenSSL is used for testing password hashing functions can generate alerts. Exclude these environments or specific test accounts from monitoring to reduce noise. -- Scheduled tasks or cron jobs that involve OpenSSL for password management purposes should be identified and excluded if they are part of regular system operations. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Terminate any suspicious OpenSSL processes identified by the detection rule to halt ongoing unauthorized password hash generation. -- Conduct a thorough review of user accounts on the affected system to identify any unauthorized accounts or changes to existing accounts, and revert any unauthorized modifications. -- Change passwords for all user accounts on the affected system, especially those with elevated privileges, to ensure that any compromised credentials are no longer valid. -- Implement additional monitoring on the affected system to detect any further unauthorized use of OpenSSL or similar tools, focusing on process execution and command-line arguments. -- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, and to assess potential impacts on other systems. -- Review and update access controls and authentication mechanisms to enhance security and prevent similar incidents in the future, ensuring that only authorized users can perform sensitive operations.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1136" name = "Create Account" reference = "https://attack.mitre.org/techniques/T1136/" - [[rule.threat.technique.subtechnique]] id = "T1136.001" name = "Local Account" reference = "https://attack.mitre.org/techniques/T1136/001/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" + diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml index a760ebe6b40..230bfedb129 100644 --- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml +++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml @@ -2,9 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -21,6 +19,41 @@ index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endg language = "eql" license = "Elastic License v2" name = "Pluggable Authentication Module (PAM) Creation in Unusual Directory" +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 Pluggable Authentication Module (PAM) Creation in Unusual Directory + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path and name to determine the exact location and nature of the PAM shared object file created. +- Investigate the process that created the file by examining the process name and its parent process to understand the context and legitimacy of the file creation. +- Check the user account associated with the process that created the file to assess if it has the necessary permissions and if the activity aligns with typical user behavior. +- Analyze recent system logs and command history for any suspicious activities or commands that might indicate an attempt to compile or move PAM modules. +- Correlate the event with other security alerts or anomalies on the system to identify potential patterns or coordinated actions that could indicate a broader compromise. +- If possible, retrieve and analyze the contents of the PAM shared object file to identify any malicious code or indicators of compromise. + +### False positive analysis + +- Development and testing environments may compile PAM modules in temporary directories. To manage this, exclude paths commonly used for development, such as "/tmp/dev/*" or "/var/tmp/test/*". +- Containerized applications might create PAM modules in non-standard directories. Exclude processes like "dockerd" and "containerd" to prevent false positives from container operations. +- Package managers or system update tools may temporarily store PAM modules in unusual directories during updates. Exclude paths like "/var/cache/pacman/pkg/*" or "/var/lib/dpkg/tmp.ci/*" to avoid alerts during legitimate system updates. +- Custom scripts or automation tools might generate PAM modules in user-specific directories. Identify and exclude these specific scripts or paths if they are known to be safe and necessary for operations. +- Temporary backup or recovery operations might involve copying PAM modules to non-standard locations. Exclude paths used for backups, such as "/backup/*" or "/recovery/*", if these operations are verified as secure. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the unusual directory where the PAM file was created to identify any other suspicious files or activities, and remove any malicious files found. +- Analyze the process that created the PAM file to determine if it was initiated by a legitimate user or process, and terminate any malicious processes. +- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges or access to sensitive systems. +- Restore the affected system from a known good backup to ensure that no malicious modifications persist. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create PAM files in unusual directories. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" references = [ "https://github.com/zephrax/linux-pam-backdoor", "https://github.com/eurialo/pambd", @@ -43,6 +76,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and file.name like "pam_*.so" and not file.path like ( "/lib/security/*", @@ -59,64 +93,30 @@ file where host.os.type == "linux" and event.type == "creation" and file.name li ) ) ''' -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 Pluggable Authentication Module (PAM) Creation in Unusual Directory - -Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats. - -### Possible investigation steps - -- Review the file creation event details, focusing on the file path and name to determine the exact location and nature of the PAM shared object file created. -- Investigate the process that created the file by examining the process name and its parent process to understand the context and legitimacy of the file creation. -- Check the user account associated with the process that created the file to assess if it has the necessary permissions and if the activity aligns with typical user behavior. -- Analyze recent system logs and command history for any suspicious activities or commands that might indicate an attempt to compile or move PAM modules. -- Correlate the event with other security alerts or anomalies on the system to identify potential patterns or coordinated actions that could indicate a broader compromise. -- If possible, retrieve and analyze the contents of the PAM shared object file to identify any malicious code or indicators of compromise. - -### False positive analysis - -- Development and testing environments may compile PAM modules in temporary directories. To manage this, exclude paths commonly used for development, such as "/tmp/dev/*" or "/var/tmp/test/*". -- Containerized applications might create PAM modules in non-standard directories. Exclude processes like "dockerd" and "containerd" to prevent false positives from container operations. -- Package managers or system update tools may temporarily store PAM modules in unusual directories during updates. Exclude paths like "/var/cache/pacman/pkg/*" or "/var/lib/dpkg/tmp.ci/*" to avoid alerts during legitimate system updates. -- Custom scripts or automation tools might generate PAM modules in user-specific directories. Identify and exclude these specific scripts or paths if they are known to be safe and necessary for operations. -- Temporary backup or recovery operations might involve copying PAM modules to non-standard locations. Exclude paths used for backups, such as "/backup/*" or "/recovery/*", if these operations are verified as secure. -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Conduct a thorough review of the unusual directory where the PAM file was created to identify any other suspicious files or activities, and remove any malicious files found. -- Analyze the process that created the PAM file to determine if it was initiated by a legitimate user or process, and terminate any malicious processes. -- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges or access to sensitive systems. -- Restore the affected system from a known good backup to ensure that no malicious modifications persist. -- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create PAM files in unusual directories. -- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1556" name = "Modify Authentication Process" reference = "https://attack.mitre.org/techniques/T1556/" + [rule.threat.tactic] id = "TA0006" name = "Credential Access" reference = "https://attack.mitre.org/tactics/TA0006/" + diff --git a/rules/linux/persistence_polkit_policy_creation.toml b/rules/linux/persistence_polkit_policy_creation.toml index 6a62c799bb5..3c93c229162 100644 --- a/rules/linux/persistence_polkit_policy_creation.toml +++ b/rules/linux/persistence_polkit_policy_creation.toml @@ -2,22 +2,55 @@ creation_date = "2025/01/16" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/23" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule monitors for the creation of Polkit policy files on Linux systems. Polkit policy files are used to -define the permissions for system-wide services and applications. The creation of new Polkit policy files may -indicate an attempt to modify the authentication process, which could be used for persistence by an adversary. +This rule monitors for the creation of Polkit policy files on Linux systems. Polkit policy files are used to define the +permissions for system-wide services and applications. The creation of new Polkit policy files may indicate an attempt +to modify the authentication process, which could be used for persistence by an adversary. """ from = "now-9m" index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] language = "eql" license = "Elastic License v2" name = "Polkit Policy 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 Polkit Policy Creation + +Polkit, or PolicyKit, is a system service in Linux environments that manages system-wide privileges, allowing non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by creating or modifying policy files to gain unauthorized access or maintain persistence. The detection rule monitors the creation of these files in critical directories, excluding known legitimate processes, to identify potential malicious activity. + +### Possible investigation steps + +- Review the file path and extension to confirm if the created file is located in one of the critical directories specified in the query, such as /etc/polkit-1/rules.d/ or /usr/share/polkit-1/actions/. +- Identify the process executable responsible for the file creation and verify if it is listed in the exclusion list of known legitimate processes. If not, this may warrant further investigation. +- Check the timestamp of the file creation event to determine if it coincides with any known maintenance or update activities, which could explain the file creation. +- Investigate the user account associated with the process that created the file to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. +- Examine any recent changes or updates to the system that might have triggered the creation of the Polkit policy file, such as software installations or configuration changes. +- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity, such as unauthorized access attempts or other policy modifications. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum may create or modify Polkit policy files during legitimate software installations or updates. To handle these, ensure that the rule excludes processes associated with these package managers as specified in the rule's exception list. +- Container management tools such as Docker and Podman might also trigger false positives when managing containerized applications. Users should verify that these executables are included in the exclusion list to prevent unnecessary alerts. +- Automation tools like Puppet and Chef can modify policy files as part of their configuration management tasks. Confirm that these processes are part of the exclusion criteria to avoid false positives. +- Snap package installations and updates can lead to the creation of policy files. Ensure that paths related to Snap are covered in the exclusion patterns to minimize false alerts. +- Virtualization software such as VirtualBox may interact with Polkit policy files. Users should check that relevant paths and executables are included in the exceptions to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as creating or modifying Polkit policy files, especially those not listed in the known legitimate processes. +- Review and restore the integrity of the Polkit policy files by comparing them against a known good baseline or backup to ensure no unauthorized changes persist. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create or modify Polkit policy files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update access controls and permissions related to Polkit policy files to ensure only authorized processes and users can create or modify these files, reducing the risk of future exploitation.""" risk_score = 21 rule_id = "0f54e947-9ab3-4dff-9e8d-fb42493eaa2f" severity = "low" @@ -34,6 +67,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.extension in ("rules", "pkla", "policy") and file.path like~ ( @@ -69,64 +103,30 @@ process.executable like~ ( ) ) ''' -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 Polkit Policy Creation - -Polkit, or PolicyKit, is a system service in Linux environments that manages system-wide privileges, allowing non-privileged processes to communicate with privileged ones. Adversaries may exploit Polkit by creating or modifying policy files to gain unauthorized access or maintain persistence. The detection rule monitors the creation of these files in critical directories, excluding known legitimate processes, to identify potential malicious activity. - -### Possible investigation steps - -- Review the file path and extension to confirm if the created file is located in one of the critical directories specified in the query, such as /etc/polkit-1/rules.d/ or /usr/share/polkit-1/actions/. -- Identify the process executable responsible for the file creation and verify if it is listed in the exclusion list of known legitimate processes. If not, this may warrant further investigation. -- Check the timestamp of the file creation event to determine if it coincides with any known maintenance or update activities, which could explain the file creation. -- Investigate the user account associated with the process that created the file to determine if it has the necessary privileges and if the activity aligns with the user's typical behavior. -- Examine any recent changes or updates to the system that might have triggered the creation of the Polkit policy file, such as software installations or configuration changes. -- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity, such as unauthorized access attempts or other policy modifications. - -### False positive analysis - -- System package managers like dpkg, rpm, and yum may create or modify Polkit policy files during legitimate software installations or updates. To handle these, ensure that the rule excludes processes associated with these package managers as specified in the rule's exception list. -- Container management tools such as Docker and Podman might also trigger false positives when managing containerized applications. Users should verify that these executables are included in the exclusion list to prevent unnecessary alerts. -- Automation tools like Puppet and Chef can modify policy files as part of their configuration management tasks. Confirm that these processes are part of the exclusion criteria to avoid false positives. -- Snap package installations and updates can lead to the creation of policy files. Ensure that paths related to Snap are covered in the exclusion patterns to minimize false alerts. -- Virtualization software such as VirtualBox may interact with Polkit policy files. Users should check that relevant paths and executables are included in the exceptions to reduce false positives. -### Response and remediation - -- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Terminate any suspicious processes identified as creating or modifying Polkit policy files, especially those not listed in the known legitimate processes. -- Review and restore the integrity of the Polkit policy files by comparing them against a known good baseline or backup to ensure no unauthorized changes persist. -- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. -- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create or modify Polkit policy files. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. -- Review and update access controls and permissions related to Polkit policy files to ensure only authorized processes and users can create or modify these files, reducing the risk of future exploitation.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1543" name = "Create or Modify System Process" reference = "https://attack.mitre.org/techniques/T1543/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1556" name = "Modify Authentication Process" reference = "https://attack.mitre.org/techniques/T1556/" + [rule.threat.tactic] id = "TA0006" name = "Credential Access" reference = "https://attack.mitre.org/tactics/TA0006/" + diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml index 02f1b624b3c..d403890c025 100644 --- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml +++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml @@ -2,9 +2,7 @@ creation_date = "2024/06/03" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/24" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,40 @@ index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Executable Bit Set for Potential Persistence Script" +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 Executable Bit Set for Potential Persistence Script + +In Linux environments, scripts with executable permissions can be used to automate tasks, including system start-up processes. Adversaries exploit this by setting executable bits on scripts in directories typically used for persistence, allowing malicious code to run automatically. The detection rule identifies such activities by monitoring for changes in executable permissions in these directories, signaling potential unauthorized persistence attempts. + +### Possible investigation steps + +- Review the process details to identify the specific script or file that had its executable bit set, focusing on the process.args field to determine the exact file path. +- Examine the process.parent.executable field to understand the parent process that initiated the permission change, which can provide context on whether the action was part of a legitimate process or potentially malicious activity. +- Check the user account associated with the process to determine if the action was performed by a legitimate user or a compromised account. +- Investigate the history of the file in question, including recent modifications and the creation date, to assess if it aligns with known system changes or updates. +- Analyze the contents of the script or file to identify any suspicious or unauthorized code that could indicate malicious intent. +- Correlate this event with other recent alerts or logs from the same host to identify patterns or additional indicators of compromise that may suggest a broader persistence mechanism. + +### False positive analysis + +- System administrators or automated scripts may legitimately change executable permissions in directories like /etc/init.d or /etc/cron* for maintenance or updates. To handle these, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Software installations or updates might trigger this rule when they modify startup scripts or configuration files. Users can mitigate this by excluding processes originating from trusted package managers or installation paths, such as /var/lib/dpkg. +- Custom user scripts in home directories, especially in /home/*/.config/autostart, may be flagged if users set them to run at startup. To reduce false positives, maintain a whitelist of user scripts that are known and approved for startup execution. +- Security tools or monitoring solutions might adjust permissions as part of their operations. Identify these tools and exclude their processes from triggering the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are associated with unauthorized script execution. +- Remove or disable the executable permissions on the identified scripts to prevent further unauthorized execution. +- Conduct a thorough review of the affected directories to identify and remove any additional unauthorized scripts or files. +- Restore any modified system files or configurations from a known good backup to ensure system integrity. +- Monitor the system for any signs of re-infection or further unauthorized changes, focusing on the directories and processes highlighted in the alert. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" references = [ "https://www.intezer.com/blog/malware-analysis/hiddenwasp-malware-targeting-linux-systems/", "https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#8-boot-or-logon-initialization-scripts-rc-scripts", @@ -90,40 +122,6 @@ process.args : ( process.command_line in ("chmod 777 /etc/update-motd.d/", "chmod 755 /etc/update-motd.d/") ) ''' -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 Executable Bit Set for Potential Persistence Script - -In Linux environments, scripts with executable permissions can be used to automate tasks, including system start-up processes. Adversaries exploit this by setting executable bits on scripts in directories typically used for persistence, allowing malicious code to run automatically. The detection rule identifies such activities by monitoring for changes in executable permissions in these directories, signaling potential unauthorized persistence attempts. - -### Possible investigation steps - -- Review the process details to identify the specific script or file that had its executable bit set, focusing on the process.args field to determine the exact file path. -- Examine the process.parent.executable field to understand the parent process that initiated the permission change, which can provide context on whether the action was part of a legitimate process or potentially malicious activity. -- Check the user account associated with the process to determine if the action was performed by a legitimate user or a compromised account. -- Investigate the history of the file in question, including recent modifications and the creation date, to assess if it aligns with known system changes or updates. -- Analyze the contents of the script or file to identify any suspicious or unauthorized code that could indicate malicious intent. -- Correlate this event with other recent alerts or logs from the same host to identify patterns or additional indicators of compromise that may suggest a broader persistence mechanism. - -### False positive analysis - -- System administrators or automated scripts may legitimately change executable permissions in directories like /etc/init.d or /etc/cron* for maintenance or updates. To handle these, create exceptions for known administrative scripts or processes that regularly perform these actions. -- Software installations or updates might trigger this rule when they modify startup scripts or configuration files. Users can mitigate this by excluding processes originating from trusted package managers or installation paths, such as /var/lib/dpkg. -- Custom user scripts in home directories, especially in /home/*/.config/autostart, may be flagged if users set them to run at startup. To reduce false positives, maintain a whitelist of user scripts that are known and approved for startup execution. -- Security tools or monitoring solutions might adjust permissions as part of their operations. Identify these tools and exclude their processes from triggering the rule to prevent unnecessary alerts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes identified in the alert that are associated with unauthorized script execution. -- Remove or disable the executable permissions on the identified scripts to prevent further unauthorized execution. -- Conduct a thorough review of the affected directories to identify and remove any additional unauthorized scripts or files. -- Restore any modified system files or configurations from a known good backup to ensure system integrity. -- Monitor the system for any signs of re-infection or further unauthorized changes, focusing on the directories and processes highlighted in the alert. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml index 7064135fca3..c1efe8be0ca 100644 --- a/rules/linux/persistence_process_capability_set_via_setcap.toml +++ b/rules/linux/persistence_process_capability_set_via_setcap.toml @@ -2,9 +2,7 @@ creation_date = "2024/06/03" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,39 @@ index = ["logs-endpoint.events.process*", "endgame-*", "logs-sentinel_one_cloud_ language = "eql" license = "Elastic License v2" name = "Process Capability Set via setcap Utility" +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 Process Capability Set via setcap Utility + +The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit this to maintain persistence or escalate privileges by misconfiguring capabilities. The detection rule identifies suspicious `setcap` usage by monitoring process execution patterns, excluding benign parent processes, to flag potential misuse. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the setcap utility, focusing on the process name and event action fields to ensure the alert is not a false positive. +- Investigate the parent process executable and name to determine if the setcap command was executed by a potentially malicious or unexpected process, especially if it is not among the excluded benign parent processes. +- Check the capabilities that were set by the setcap command to assess if they could allow privilege escalation or persistence, and determine if they align with normal operational requirements. +- Examine the timeline of events around the setcap execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that could suggest a coordinated attack. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule when package managers like dpkg or Docker set capabilities during their processes. To handle this, exclude paths such as /var/lib/dpkg/* and /var/lib/docker/* from the detection rule. +- Development environments or containerized applications might use setcap for testing purposes. Exclude processes originating from /tmp/newroot/* and /var/tmp/newroot/* to reduce noise from these environments. +- Custom scripts or administrative tools that use setcap for legitimate configuration tasks can be excluded by identifying their parent process names and adding them to the exclusion list, similar to the existing exclusions for jem and vzctl. +- Regular audits of the exclusion list should be conducted to ensure that no malicious processes are inadvertently whitelisted, maintaining a balance between reducing false positives and ensuring security. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes associated with the `setcap` utility that are not part of legitimate administrative tasks. +- Review and remove any unnecessary capabilities set on executables using the `setcap` utility to prevent privilege escalation. +- Conduct a thorough audit of the system to identify any backdoors or unauthorized changes made by the attacker, and remove them. +- Restore affected systems from a known good backup if unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for `setcap` usage and similar privilege escalation attempts to improve future detection capabilities.""" risk_score = 21 rule_id = "f18a474c-3632-427f-bcf5-363c994309ee" setup = """## Setup @@ -57,10 +88,11 @@ tags = [ "Data Source: Elastic Endgame", "Data Source: Elastic Defend", "Data Source: SentinelOne", - "Resources: Investigation Guide" + "Resources: Investigation Guide", ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start") and process.name == "setcap" and not ( @@ -69,39 +101,7 @@ process.name == "setcap" and not ( process.parent.name in ("jem", "vzctl") ) ''' -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 Process Capability Set via setcap Utility - -The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit this to maintain persistence or escalate privileges by misconfiguring capabilities. The detection rule identifies suspicious `setcap` usage by monitoring process execution patterns, excluding benign parent processes, to flag potential misuse. - -### Possible investigation steps - -- Review the process execution details to confirm the use of the setcap utility, focusing on the process name and event action fields to ensure the alert is not a false positive. -- Investigate the parent process executable and name to determine if the setcap command was executed by a potentially malicious or unexpected process, especially if it is not among the excluded benign parent processes. -- Check the capabilities that were set by the setcap command to assess if they could allow privilege escalation or persistence, and determine if they align with normal operational requirements. -- Examine the timeline of events around the setcap execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. -- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that could suggest a coordinated attack. - -### False positive analysis -- Legitimate software installations or updates may trigger the rule when package managers like dpkg or Docker set capabilities during their processes. To handle this, exclude paths such as /var/lib/dpkg/* and /var/lib/docker/* from the detection rule. -- Development environments or containerized applications might use setcap for testing purposes. Exclude processes originating from /tmp/newroot/* and /var/tmp/newroot/* to reduce noise from these environments. -- Custom scripts or administrative tools that use setcap for legitimate configuration tasks can be excluded by identifying their parent process names and adding them to the exclusion list, similar to the existing exclusions for jem and vzctl. -- Regular audits of the exclusion list should be conducted to ensure that no malicious processes are inadvertently whitelisted, maintaining a balance between reducing false positives and ensuring security. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. -- Terminate any suspicious processes associated with the `setcap` utility that are not part of legitimate administrative tasks. -- Review and remove any unnecessary capabilities set on executables using the `setcap` utility to prevent privilege escalation. -- Conduct a thorough audit of the system to identify any backdoors or unauthorized changes made by the attacker, and remove them. -- Restore affected systems from a known good backup if unauthorized changes or persistent threats are detected. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. -- Implement enhanced monitoring and logging for `setcap` usage and similar privilege escalation attempts to improve future detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" @@ -110,7 +110,6 @@ framework = "MITRE ATT&CK" id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -118,3 +117,4 @@ framework = "MITRE ATT&CK" id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" + diff --git a/rules/linux/persistence_setuid_setgid_capability_set.toml b/rules/linux/persistence_setuid_setgid_capability_set.toml index f281b3b7e24..64bcaa630b4 100644 --- a/rules/linux/persistence_setuid_setgid_capability_set.toml +++ b/rules/linux/persistence_setuid_setgid_capability_set.toml @@ -2,9 +2,7 @@ creation_date = "2023/09/05" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [transform] [[transform.osquery]] @@ -41,7 +39,12 @@ file owner or group. Threat actors can exploit these attributes to achieve persi allowing them to maintain control over a compromised system with elevated permissions. """ from = "now-9m" -index = ["endgame-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "endgame-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Setcap setuid/setgid Capability Set" @@ -146,6 +149,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -155,6 +159,7 @@ process where host.os.type == "linux" and event.type == "start" and ) ''' + [[rule.threat]] framework = "MITRE ATT&CK" @@ -162,21 +167,21 @@ framework = "MITRE ATT&CK" id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1548" name = "Abuse Elevation Control Mechanism" reference = "https://attack.mitre.org/techniques/T1548/" - [[rule.threat.technique.subtechnique]] id = "T1548.001" name = "Setuid and Setgid" reference = "https://attack.mitre.org/techniques/T1548/001/" + + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" + diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml index 8628309fc60..7f31d6c923a 100644 --- a/rules/linux/persistence_simple_web_server_creation.toml +++ b/rules/linux/persistence_simple_web_server_creation.toml @@ -2,9 +2,7 @@ creation_date = "2024/12/17" integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/24" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,10 +12,50 @@ simple HTTP web servers to establish persistence on a compromised system by uplo to the server web root, allowing them to regain remote access to the system if lost. """ from = "now-9m" -index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"] +index = [ + "logs-endpoint.events.process*", + "logs-crowdstrike.fdr*", + "logs-sentinel_one_cloud_funnel.*", + "endgame-*", +] language = "eql" license = "Elastic License v2" name = "Simple HTTP Web Server 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 Simple HTTP Web Server Creation + +Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised Linux systems. By deploying a web server, they can upload malicious payloads, such as reverse shells, to maintain remote access. The detection rule identifies suspicious server creation by monitoring process executions that match specific patterns, such as PHP or Python commands indicative of server setup, thereby alerting analysts to potential threats. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of PHP or Python commands with arguments matching the patterns specified in the query, such as PHP with the "-S" argument or Python with "--cgi" or "CGIHTTPServer". +- Identify the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise. +- Examine the network activity associated with the process to identify any unusual connections or data transfers that could suggest malicious intent or data exfiltration. +- Check the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads, such as reverse shells. +- Investigate the parent process of the suspicious server creation to understand how the process was initiated and whether it was triggered by another potentially malicious activity. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Development and testing environments often use simple HTTP servers for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development directories or user accounts frequently involved in these activities. +- Automated scripts or cron jobs may start simple HTTP servers for routine tasks like file distribution or internal data sharing. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. +- Educational or training sessions might involve setting up simple HTTP servers as part of learning exercises. Exclude specific IP ranges or user groups associated with training environments to prevent false positives. +- System administrators might use simple HTTP servers for quick troubleshooting or system maintenance tasks. Document these activities and create exceptions based on the administrator's user accounts or specific server names. +- Continuous integration and deployment pipelines may temporarily start HTTP servers during build or deployment processes. Identify these pipelines and exclude their associated processes or execution contexts from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious PHP or Python processes identified by the detection rule to halt the operation of the unauthorized web server. +- Conduct a thorough examination of the web server's root directory to identify and remove any malicious payloads, such as reverse shells or unauthorized scripts. +- Review system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary. +- Restore the system from a known good backup if any critical system files or configurations have been altered by the adversary. +- Implement stricter access controls and monitoring on the affected system to prevent similar unauthorized server setups in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" risk_score = 21 rule_id = "907a26f5-3eb6-4338-a70e-6c375c1cde8a" setup = """## Setup @@ -61,6 +99,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and @@ -70,87 +109,52 @@ process where host.os.type == "linux" and event.type == "start" and ) and not process.parent.name in ("check_kmp_wrapper", "naemon") ''' -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 Simple HTTP Web Server Creation -Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised Linux systems. By deploying a web server, they can upload malicious payloads, such as reverse shells, to maintain remote access. The detection rule identifies suspicious server creation by monitoring process executions that match specific patterns, such as PHP or Python commands indicative of server setup, thereby alerting analysts to potential threats. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of PHP or Python commands with arguments matching the patterns specified in the query, such as PHP with the "-S" argument or Python with "--cgi" or "CGIHTTPServer". -- Identify the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise. -- Examine the network activity associated with the process to identify any unusual connections or data transfers that could suggest malicious intent or data exfiltration. -- Check the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads, such as reverse shells. -- Investigate the parent process of the suspicious server creation to understand how the process was initiated and whether it was triggered by another potentially malicious activity. -- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. - -### False positive analysis - -- Development and testing environments often use simple HTTP servers for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development directories or user accounts frequently involved in these activities. -- Automated scripts or cron jobs may start simple HTTP servers for routine tasks like file distribution or internal data sharing. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. -- Educational or training sessions might involve setting up simple HTTP servers as part of learning exercises. Exclude specific IP ranges or user groups associated with training environments to prevent false positives. -- System administrators might use simple HTTP servers for quick troubleshooting or system maintenance tasks. Document these activities and create exceptions based on the administrator's user accounts or specific server names. -- Continuous integration and deployment pipelines may temporarily start HTTP servers during build or deployment processes. Identify these pipelines and exclude their associated processes or execution contexts from the detection rule. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious PHP or Python processes identified by the detection rule to halt the operation of the unauthorized web server. -- Conduct a thorough examination of the web server's root directory to identify and remove any malicious payloads, such as reverse shells or unauthorized scripts. -- Review system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary. -- Restore the system from a known good backup if any critical system files or configurations have been altered by the adversary. -- Implement stricter access controls and monitoring on the affected system to prevent similar unauthorized server setups in the future. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1505" +name = "Server Software Component" +reference = "https://attack.mitre.org/techniques/T1505/" +[[rule.threat.technique.subtechnique]] +id = "T1505.003" +name = "Web Shell" +reference = "https://attack.mitre.org/techniques/T1505/003/" - [rule.threat.tactic] - name = "Persistence" - id = "TA0003" - reference = "https://attack.mitre.org/tactics/TA0003/" - - [[rule.threat.technique]] - id = "T1505" - name = "Server Software Component" - reference = "https://attack.mitre.org/techniques/T1505/" - [[rule.threat.technique.subtechnique]] - id = "T1505.003" - name = "Web Shell" - reference = "https://attack.mitre.org/techniques/T1505/003/" +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1059" +name = "Command and Scripting Interpreter" +reference = "https://attack.mitre.org/techniques/T1059/" +[[rule.threat.technique.subtechnique]] +id = "T1059.004" +name = "Unix Shell" +reference = "https://attack.mitre.org/techniques/T1059/004/" - [rule.threat.tactic] - name = "Execution" - id = "TA0002" - reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat.technique]] - id = "T1059" - name = "Command and Scripting Interpreter" - reference = "https://attack.mitre.org/techniques/T1059/" - - [[rule.threat.technique.subtechnique]] - name = "Unix Shell" - id = "T1059.004" - reference = "https://attack.mitre.org/techniques/T1059/004/" +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1071" +name = "Application Layer Protocol" +reference = "https://attack.mitre.org/techniques/T1071/" + - [rule.threat.tactic] - name = "Command and Control" - id = "TA0011" - reference = "https://attack.mitre.org/tactics/TA0011/" +[rule.threat.tactic] +id = "TA0011" +name = "Command and Control" +reference = "https://attack.mitre.org/tactics/TA0011/" - [[rule.threat.technique]] - name = "Application Layer Protocol" - id = "T1071" - reference = "https://attack.mitre.org/techniques/T1071/" diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml index 15c65e37d54..e8f2c4ff724 100644 --- a/rules/linux/persistence_ssh_key_generation.toml +++ b/rules/linux/persistence_ssh_key_generation.toml @@ -2,9 +2,7 @@ creation_date = "2024/05/31" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/15" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,29 +17,6 @@ index = ["logs-endpoint.events.file*", "endgame-*", "logs-sentinel_one_cloud_fun language = "eql" license = "Elastic License v2" name = "SSH Key Generated via ssh-keygen" -references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"] -risk_score = 21 -rule_id = "7df3cb8b-5c0c-4228-b772-bb6cd619053c" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Linux", - "Use Case: Threat Detection", - "Tactic: Lateral Movement", - "Tactic: Persistence", - "Data Source: Elastic Endgame", - "Data Source: Elastic Defend", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and -process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and -not file.name : "known_hosts.*" -''' note = """## Triage and analysis > **Disclaimer**: @@ -77,6 +52,29 @@ SSH keys, created using the ssh-keygen tool, are essential for secure authentica - Monitor network traffic and system logs for any signs of further unauthorized access attempts or suspicious activity related to SSH. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. - Implement additional monitoring and alerting for SSH key generation activities across the network to enhance detection of similar threats in the future.""" +references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"] +risk_score = 21 +rule_id = "7df3cb8b-5c0c-4228-b772-bb6cd619053c" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Lateral Movement", + "Tactic: Persistence", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +file where host.os.type == "linux" and event.action in ("creation", "file_create_event") and +process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and +not file.name : "known_hosts.*" +''' [[rule.threat]] diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml index 2dfb4da2e50..a3db7c8cbe3 100644 --- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml +++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml @@ -2,9 +2,7 @@ creation_date = "2023/07/25" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -21,6 +19,41 @@ language = "eql" license = "Elastic License v2" max_signals = 1 name = "Potential Suspicious File Edit" +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 Suspicious File Edit + +In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further. + +### Possible investigation steps + +- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query. +- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update. +- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role. +- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies. +- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories. +- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd. + +### False positive analysis + +- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel. +- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives. +- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives. +- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences. +- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity. +- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes. +- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future.""" risk_score = 21 rule_id = "3728c08d-9b70-456b-b6b8-007c7d246128" severity = "low" @@ -59,41 +92,6 @@ file.path : ( "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp" ) ''' -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 Suspicious File Edit - -In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further. - -### Possible investigation steps - -- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query. -- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update. -- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role. -- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies. -- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories. -- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd. - -### False positive analysis - -- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel. -- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives. -- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives. -- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences. -- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. -- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity. -- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes. -- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access. -- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. -- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future.""" [[rule.threat]] diff --git a/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml b/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml index 2ff447924d2..185fac40937 100644 --- a/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml +++ b/rules/linux/persistence_unpack_initramfs_via_unmkinitramfs.toml @@ -2,17 +2,15 @@ creation_date = "2025/01/16" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/22" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ This rule detects the unpacking of an initramfs image using the `unmkinitramfs` command on Linux systems. The -`unmkinitramfs` command is used to extract the contents of an initramfs image, which is used to boot the -system. Attackers may use `unmkinitramfs` to unpack an initramfs image and modify its contents to include -malicious code or backdoors, allowing them to maintain persistence on the system. +`unmkinitramfs` command is used to extract the contents of an initramfs image, which is used to boot the system. +Attackers may use `unmkinitramfs` to unpack an initramfs image and modify its contents to include malicious code or +backdoors, allowing them to maintain persistence on the system. """ from = "now-9m" index = [ @@ -21,11 +19,44 @@ index = [ "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", - "logs-sentinel_one_cloud_funnel.*" + "logs-sentinel_one_cloud_funnel.*", ] language = "eql" license = "Elastic License v2" name = "Initramfs Unpacking via unmkinitramfs" +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 Initramfs Unpacking via unmkinitramfs + +Initramfs is a crucial component in Linux boot processes, containing essential drivers and scripts. The `unmkinitramfs` tool extracts its contents, which attackers might exploit to insert malicious code, ensuring persistence. The detection rule identifies the execution of `unmkinitramfs`, flagging potential unauthorized modifications by monitoring process initiation events on Linux systems. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the unmkinitramfs command, focusing on the process.name field to ensure it matches "unmkinitramfs". +- Check the user context under which the unmkinitramfs command was executed to determine if it aligns with expected administrative activities or if it was run by an unauthorized user. +- Investigate the parent process of the unmkinitramfs execution to understand how the command was initiated and if it was part of a legitimate script or an unexpected process chain. +- Examine recent system logs and audit logs for any other suspicious activities or anomalies around the time of the unmkinitramfs execution, such as unauthorized access attempts or changes to critical system files. +- Assess the integrity of the initramfs image by comparing it with a known good version, if available, to identify any unauthorized modifications or inclusions of malicious code. + +### False positive analysis + +- Routine system maintenance or updates may trigger the rule when legitimate processes unpack initramfs for kernel updates. Users can create exceptions for known maintenance scripts or processes that regularly perform these actions. +- Automated backup or recovery solutions might use unmkinitramfs to verify or restore system images. Identify and exclude these processes if they are part of trusted backup operations. +- Developers or system administrators testing or customizing initramfs images for legitimate purposes could trigger the rule. Establish a whitelist for specific user accounts or scripts that are authorized to perform these tasks. +- Security tools or monitoring solutions that analyze initramfs contents for integrity checks might inadvertently trigger the rule. Ensure these tools are recognized and excluded from detection to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the attacker. +- Terminate any suspicious processes related to `unmkinitramfs` to halt any ongoing malicious activity. +- Conduct a thorough review of the initramfs image and its contents to identify and remove any unauthorized modifications or malicious code. +- Restore the initramfs image from a known good backup to ensure system integrity and remove any potential backdoors. +- Monitor the system for any further attempts to execute `unmkinitramfs` and investigate any such occurrences to determine if they are legitimate or part of an ongoing attack. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement additional logging and monitoring for process execution events on Linux systems to enhance detection capabilities for similar threats in the future.""" risk_score = 21 rule_id = "c5fc788c-7576-4a02-b3d6-d2c016eb85a6" setup = """## Setup @@ -64,48 +95,16 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and process.name == "unmkinitramfs" ''' -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 Initramfs Unpacking via unmkinitramfs - -Initramfs is a crucial component in Linux boot processes, containing essential drivers and scripts. The `unmkinitramfs` tool extracts its contents, which attackers might exploit to insert malicious code, ensuring persistence. The detection rule identifies the execution of `unmkinitramfs`, flagging potential unauthorized modifications by monitoring process initiation events on Linux systems. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the unmkinitramfs command, focusing on the process.name field to ensure it matches "unmkinitramfs". -- Check the user context under which the unmkinitramfs command was executed to determine if it aligns with expected administrative activities or if it was run by an unauthorized user. -- Investigate the parent process of the unmkinitramfs execution to understand how the command was initiated and if it was part of a legitimate script or an unexpected process chain. -- Examine recent system logs and audit logs for any other suspicious activities or anomalies around the time of the unmkinitramfs execution, such as unauthorized access attempts or changes to critical system files. -- Assess the integrity of the initramfs image by comparing it with a known good version, if available, to identify any unauthorized modifications or inclusions of malicious code. - -### False positive analysis - -- Routine system maintenance or updates may trigger the rule when legitimate processes unpack initramfs for kernel updates. Users can create exceptions for known maintenance scripts or processes that regularly perform these actions. -- Automated backup or recovery solutions might use unmkinitramfs to verify or restore system images. Identify and exclude these processes if they are part of trusted backup operations. -- Developers or system administrators testing or customizing initramfs images for legitimate purposes could trigger the rule. Establish a whitelist for specific user accounts or scripts that are authorized to perform these tasks. -- Security tools or monitoring solutions that analyze initramfs contents for integrity checks might inadvertently trigger the rule. Ensure these tools are recognized and excluded from detection to prevent unnecessary alerts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the attacker. -- Terminate any suspicious processes related to `unmkinitramfs` to halt any ongoing malicious activity. -- Conduct a thorough review of the initramfs image and its contents to identify and remove any unauthorized modifications or malicious code. -- Restore the initramfs image from a known good backup to ensure system integrity and remove any potential backdoors. -- Monitor the system for any further attempts to execute `unmkinitramfs` and investigate any such occurrences to determine if they are legitimate or part of an ongoing attack. -- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. -- Implement additional logging and monitoring for process execution events on Linux systems to enhance detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1542" name = "Pre-OS Boot" @@ -121,29 +120,28 @@ id = "T1574" name = "Hijack Execution Flow" reference = "https://attack.mitre.org/techniques/T1574/" + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" - [[rule.threat]] framework = "MITRE ATT&CK" @@ -151,3 +149,4 @@ framework = "MITRE ATT&CK" id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/persistence_web_server_sus_child_spawned.toml b/rules/linux/persistence_web_server_sus_child_spawned.toml index c20aef20884..3229775dd7c 100644 --- a/rules/linux/persistence_web_server_sus_child_spawned.toml +++ b/rules/linux/persistence_web_server_sus_child_spawned.toml @@ -2,18 +2,16 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/03/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects unusual processes spawned from a web server parent process by identifying low -frequency counts of process spawning activity. Unusual process spawning activity may indicate an -attacker attempting to establish persistence, execute malicious commands, or establish command -and control channels on the host system. ES|QL rules have limited fields available in its alert -documents. Make sure to review the original documents to aid in the investigation of this alert. +This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of +process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish +persistence, execute malicious commands, or establish command and control channels on the host system. ES|QL rules have +limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation +of this alert. """ from = "now-61m" interval = "1h" @@ -59,6 +57,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.process-* | keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.executable, process.command_line, process.parent.executable, agent.id @@ -90,51 +89,51 @@ not ( | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - -[rule.threat.tactic] -name = "Persistence" -id = "TA0003" -reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat.technique]] id = "T1505" name = "Server Software Component" reference = "https://attack.mitre.org/techniques/T1505/" - [[rule.threat.technique.subtechnique]] id = "T1505.003" name = "Web Shell" reference = "https://attack.mitre.org/techniques/T1505/003/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[rule.threat.tactic] -name = "Execution" -id = "TA0002" -reference = "https://attack.mitre.org/tactics/TA0002/" +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" +[[rule.threat]] +framework = "MITRE ATT&CK" [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1071" +name = "Application Layer Protocol" +reference = "https://attack.mitre.org/techniques/T1071/" + [rule.threat.tactic] -name = "Command and Control" id = "TA0011" +name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" -[[rule.threat.technique]] -name = "Application Layer Protocol" -id = "T1071" -reference = "https://attack.mitre.org/techniques/T1071/" diff --git a/rules/linux/persistence_web_server_sus_command_execution.toml b/rules/linux/persistence_web_server_sus_command_execution.toml index edeedf094f5..b44e6f12ca4 100644 --- a/rules/linux/persistence_web_server_sus_command_execution.toml +++ b/rules/linux/persistence_web_server_sus_command_execution.toml @@ -2,20 +2,17 @@ creation_date = "2025/03/04" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/03/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] description = """ -This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may -attempt to execute commands from a web server parent process to blend in with normal web server activity and -evade detection. This behavior is commonly observed in web shell attacks where adversaries exploit web server -vulnerabilities to execute arbitrary commands on the host. The detection rule identifies unusual command -execution from web server parent processes, which may indicate a compromised host or an ongoing attack. -ES|QL rules have limited fields available in its alert documents. Make sure to review the original documents -to aid in the investigation of this alert. +This rule detects potential command execution from a web server parent process on a Linux host. Adversaries may attempt +to execute commands from a web server parent process to blend in with normal web server activity and evade detection. +This behavior is commonly observed in web shell attacks where adversaries exploit web server vulnerabilities to execute +arbitrary commands on the host. The detection rule identifies unusual command execution from web server parent +processes, which may indicate a compromised host or an ongoing attack. ES|QL rules have limited fields available in its +alert documents. Make sure to review the original documents to aid in the investigation of this alert. """ from = "now-61m" interval = "1h" @@ -61,6 +58,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.process-* | keep @timestamp, host.os.type, event.type, event.action, process.parent.name, user.name, user.id, process.working_directory, process.name, process.command_line, process.parent.executable, agent.id @@ -95,51 +93,51 @@ from logs-endpoint.events.process-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - -[rule.threat.tactic] -name = "Persistence" -id = "TA0003" -reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat.technique]] id = "T1505" name = "Server Software Component" reference = "https://attack.mitre.org/techniques/T1505/" - [[rule.threat.technique.subtechnique]] id = "T1505.003" name = "Web Shell" reference = "https://attack.mitre.org/techniques/T1505/003/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[rule.threat.tactic] -name = "Execution" -id = "TA0002" -reference = "https://attack.mitre.org/tactics/TA0002/" +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" +[[rule.threat]] +framework = "MITRE ATT&CK" [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1071" +name = "Application Layer Protocol" +reference = "https://attack.mitre.org/techniques/T1071/" + [rule.threat.tactic] -name = "Command and Control" id = "TA0011" +name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" -[[rule.threat.technique]] -name = "Application Layer Protocol" -id = "T1071" -reference = "https://attack.mitre.org/techniques/T1071/" diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml index 6dd7ba60122..4bd670306f2 100644 --- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml +++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml @@ -2,9 +2,7 @@ creation_date = "2023/07/28" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,51 @@ commands or input containing wildcards (e.g., *, ?, []) to execute unintended op tricking the system into interpreting the wildcard characters in unexpected ways. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Unauthorized Access via Wildcard Injection Detected" +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 Unauthorized Access via Wildcard Injection Detected + +In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse aimed at privilege escalation or unauthorized data access. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "chown" or "chmod" command with the "-R" flag and wildcard usage in the arguments, as indicated by the query fields process.name, process.args, and event.action. +- Examine the user account associated with the process execution to determine if it has the necessary permissions to perform such operations and assess if the account has been compromised. +- Check the command execution history and related logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or unauthorized access attempts. +- Investigate the source and destination of the command execution by analyzing network logs and connections to determine if the activity originated from a known or unknown IP address or host. +- Correlate this event with other alerts or anomalies in the system to identify potential patterns or coordinated attacks, focusing on privilege escalation or credential access attempts as suggested by the rule's tags and threat information. + +### False positive analysis + +- Routine administrative tasks using chown or chmod with recursive flags may trigger the rule. To manage this, identify and whitelist specific scripts or users that regularly perform these tasks without security risks. +- Automated system maintenance processes that involve changing file permissions or ownership across directories can be mistaken for malicious activity. Exclude these processes by specifying their command patterns or associated user accounts in the monitoring system. +- Backup operations that involve copying and setting permissions on large sets of files might be flagged. To prevent this, configure exceptions for known backup tools or scripts that use these commands in a controlled manner. +- Development environments where developers frequently change file permissions for testing purposes can generate false positives. Implement user-based exceptions for development teams to reduce unnecessary alerts. +- System updates or package installations that modify file permissions as part of their normal operation may be detected. Create exceptions for trusted package managers or update processes to avoid false alarms. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as running the `chown` or `chmod` commands with wildcard injections to halt potential privilege escalation activities. +- Conduct a thorough review of system logs and command histories to identify any unauthorized changes made to file permissions or ownership and revert them to their original state. +- Reset credentials and review access permissions for users on the affected system to ensure no unauthorized access persists. +- Implement file integrity monitoring to detect unauthorized changes to critical files and directories in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and patch the affected system to address any vulnerabilities that may have been exploited during the attack, ensuring all security updates are applied.""" references = ["https://www.exploit-db.com/papers/33930"] risk_score = 21 rule_id = "4a99ac6f-9a54-4ba5-a64f-6eb65695841b" @@ -69,40 +108,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*" ''' -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 Unauthorized Access via Wildcard Injection Detected - -In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse aimed at privilege escalation or unauthorized data access. - -### Possible investigation steps - -- Review the process execution details to confirm the presence of the "chown" or "chmod" command with the "-R" flag and wildcard usage in the arguments, as indicated by the query fields process.name, process.args, and event.action. -- Examine the user account associated with the process execution to determine if it has the necessary permissions to perform such operations and assess if the account has been compromised. -- Check the command execution history and related logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or unauthorized access attempts. -- Investigate the source and destination of the command execution by analyzing network logs and connections to determine if the activity originated from a known or unknown IP address or host. -- Correlate this event with other alerts or anomalies in the system to identify potential patterns or coordinated attacks, focusing on privilege escalation or credential access attempts as suggested by the rule's tags and threat information. - -### False positive analysis - -- Routine administrative tasks using chown or chmod with recursive flags may trigger the rule. To manage this, identify and whitelist specific scripts or users that regularly perform these tasks without security risks. -- Automated system maintenance processes that involve changing file permissions or ownership across directories can be mistaken for malicious activity. Exclude these processes by specifying their command patterns or associated user accounts in the monitoring system. -- Backup operations that involve copying and setting permissions on large sets of files might be flagged. To prevent this, configure exceptions for known backup tools or scripts that use these commands in a controlled manner. -- Development environments where developers frequently change file permissions for testing purposes can generate false positives. Implement user-based exceptions for development teams to reduce unnecessary alerts. -- System updates or package installations that modify file permissions as part of their normal operation may be detected. Create exceptions for trusted package managers or update processes to avoid false alarms. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. -- Terminate any suspicious processes identified as running the `chown` or `chmod` commands with wildcard injections to halt potential privilege escalation activities. -- Conduct a thorough review of system logs and command histories to identify any unauthorized changes made to file permissions or ownership and revert them to their original state. -- Reset credentials and review access permissions for users on the affected system to ensure no unauthorized access persists. -- Implement file integrity monitoring to detect unauthorized changes to critical files and directories in the future. -- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. -- Update and patch the affected system to address any vulnerabilities that may have been exploited during the attack, ensuring all security updates are applied.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml index eb87c2531d8..cf3c4082eaf 100644 --- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml +++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml @@ -2,9 +2,7 @@ creation_date = "2024/01/15" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,6 +16,41 @@ index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Potential Chroot Container Escape via Mount" +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 Chroot Container Escape via Mount + +Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved. +- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes. +- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks. +- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations. +- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior. +- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise. + +### False positive analysis + +- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule. +- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users. +- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users. +- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe. +- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. +- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts. +- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits. +- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity. +- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure. +- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape. +- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences.""" references = [ "https://book.hacktricks.xyz/v/portugues-ht/linux-hardening/privilege-escalation/escaping-from-limited-bash", ] @@ -79,41 +112,6 @@ sequence by host.id, process.parent.entity_id with maxspan=5m [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "chroot"] ''' -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 Chroot Container Escape via Mount - -Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts. - -### Possible investigation steps - -- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved. -- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes. -- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks. -- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations. -- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior. -- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise. - -### False positive analysis - -- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule. -- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users. -- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users. -- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe. -- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule. - -### Response and remediation - -- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. -- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts. -- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits. -- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity. -- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure. -- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape. -- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml index 1f39e9a2a8c..be48d513e96 100644 --- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml +++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml @@ -2,9 +2,7 @@ creation_date = "2023/06/09" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -16,10 +14,52 @@ escalate privileges, establish persistence or hide their activities by loading a tamper with the system's trusted state, allowing e.g. a VM Escape. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Kernel Load or Unload via Kexec Detected" +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 Kernel Load or Unload via Kexec Detected + +Kexec is a Linux feature allowing a new kernel to load without rebooting, streamlining updates and recovery. However, attackers can exploit kexec to bypass security, escalate privileges, or hide activities by loading malicious kernels. The detection rule identifies suspicious kexec usage by monitoring process actions and arguments, excluding benign parent processes, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the presence of the kexec command with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u". +- Investigate the parent process of the kexec command to ensure it is not a benign process like "kdumpctl" or "unload.sh", which are excluded from the detection rule. +- Check the user account associated with the kexec process to determine if it has the necessary privileges and if the activity aligns with their typical behavior. +- Analyze recent system logs and security events for any signs of privilege escalation or unauthorized kernel modifications around the time the kexec command was executed. +- Examine the system for any signs of persistence mechanisms or other indicators of compromise that may suggest a broader attack campaign. +- Correlate this event with other alerts or anomalies in the environment to assess if this is part of a larger attack pattern or isolated incident. + +### False positive analysis + +- Kdump operations may trigger false positives as kdumpctl is a benign parent process for kexec. Ensure kdumpctl is included in the exclusion list to prevent unnecessary alerts. +- Custom scripts for kernel unloading, such as unload.sh, can cause false positives. Verify these scripts are legitimate and add them to the exclusion list if they are frequently used in your environment. +- Routine administrative tasks involving kernel updates or testing may involve kexec. Confirm these activities are authorized and consider excluding specific administrative accounts or processes from detection. +- Automated system recovery processes that utilize kexec might be flagged. Identify these processes and exclude them if they are part of a known and secure recovery mechanism. +- Security tools or monitoring solutions that use kexec for legitimate purposes should be reviewed and excluded to avoid false alerts, ensuring they are recognized as trusted applications. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Terminate any suspicious kexec processes identified by the detection rule to halt any ongoing malicious kernel loading activities. +- Conduct a thorough review of system logs and process histories to identify any unauthorized kernel loads or modifications, and revert to a known good state if necessary. +- Restore the system from a clean backup taken before the suspicious activity was detected to ensure system integrity and remove any potential backdoors or malicious kernels. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that could be exploited by similar attacks in the future. +- Implement strict access controls and monitoring on systems with kexec capabilities to prevent unauthorized usage and ensure only trusted personnel can perform kernel operations. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network.""" references = [ "https://www.crowdstrike.com/blog/venom-vulnerability-details/", "https://www.makeuseof.com/what-is-venom-vulnerability/", @@ -69,93 +109,59 @@ tags = [ ] timestamp_override = "event.ingested" type = "eql" + query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and not process.parent.name in ("kdumpctl", "unload.sh") ''' -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 Kernel Load or Unload via Kexec Detected - -Kexec is a Linux feature allowing a new kernel to load without rebooting, streamlining updates and recovery. However, attackers can exploit kexec to bypass security, escalate privileges, or hide activities by loading malicious kernels. The detection rule identifies suspicious kexec usage by monitoring process actions and arguments, excluding benign parent processes, to flag potential threats. - -### Possible investigation steps - -- Review the process details to confirm the presence of the kexec command with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u". -- Investigate the parent process of the kexec command to ensure it is not a benign process like "kdumpctl" or "unload.sh", which are excluded from the detection rule. -- Check the user account associated with the kexec process to determine if it has the necessary privileges and if the activity aligns with their typical behavior. -- Analyze recent system logs and security events for any signs of privilege escalation or unauthorized kernel modifications around the time the kexec command was executed. -- Examine the system for any signs of persistence mechanisms or other indicators of compromise that may suggest a broader attack campaign. -- Correlate this event with other alerts or anomalies in the environment to assess if this is part of a larger attack pattern or isolated incident. - -### False positive analysis - -- Kdump operations may trigger false positives as kdumpctl is a benign parent process for kexec. Ensure kdumpctl is included in the exclusion list to prevent unnecessary alerts. -- Custom scripts for kernel unloading, such as unload.sh, can cause false positives. Verify these scripts are legitimate and add them to the exclusion list if they are frequently used in your environment. -- Routine administrative tasks involving kernel updates or testing may involve kexec. Confirm these activities are authorized and consider excluding specific administrative accounts or processes from detection. -- Automated system recovery processes that utilize kexec might be flagged. Identify these processes and exclude them if they are part of a known and secure recovery mechanism. -- Security tools or monitoring solutions that use kexec for legitimate purposes should be reviewed and excluded to avoid false alerts, ensuring they are recognized as trusted applications. - -### Response and remediation -- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. -- Terminate any suspicious kexec processes identified by the detection rule to halt any ongoing malicious kernel loading activities. -- Conduct a thorough review of system logs and process histories to identify any unauthorized kernel loads or modifications, and revert to a known good state if necessary. -- Restore the system from a clean backup taken before the suspicious activity was detected to ensure system integrity and remove any potential backdoors or malicious kernels. -- Update and patch the system to the latest security standards to mitigate any vulnerabilities that could be exploited by similar attacks in the future. -- Implement strict access controls and monitoring on systems with kexec capabilities to prevent unauthorized usage and ensure only trusted personnel can perform kernel operations. -- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1611" name = "Escape to Host" reference = "https://attack.mitre.org/techniques/T1611/" + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1547" name = "Boot or Logon Autostart Execution" reference = "https://attack.mitre.org/techniques/T1547/" - [[rule.threat.technique.subtechnique]] id = "T1547.006" name = "Kernel Modules and Extensions" reference = "https://attack.mitre.org/techniques/T1547/006/" + + [rule.threat.tactic] id = "TA0003" name = "Persistence" reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1601" name = "Modify System Image" reference = "https://attack.mitre.org/techniques/T1601/" - [[rule.threat.technique.subtechnique]] id = "T1601.001" name = "Patch System Image" reference = "https://attack.mitre.org/techniques/T1601/001/" + + [rule.threat.tactic] id = "TA0005" name = "Defense Evasion" reference = "https://attack.mitre.org/tactics/TA0005/" + diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml index 793e90b2b57..9df3d417f82 100644 --- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml +++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml @@ -2,9 +2,7 @@ creation_date = "2022/01/26" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,41 @@ index = ["endgame-*", "logs-endpoint.events.file*", "logs-sentinel_one_cloud_fun language = "eql" license = "Elastic License v2" name = "Potential Privilege Escalation via PKEXEC" +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 Privilege Escalation via PKEXEC + +Polkit's pkexec is a command-line utility that allows an authorized user to execute commands as another user, typically root, in Linux environments. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, enabling unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on environment variable manipulation to preemptively flag potential threats. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the file path pattern "/*GCONV_PATH*" on a Linux host, as this is indicative of the potential exploitation attempt. +- Examine the process execution history on the affected host to identify any instances of pkexec being executed around the time of the alert. Look for unusual or unauthorized command executions. +- Check the environment variables set during the pkexec execution to identify any suspicious or unauthorized modifications that could indicate an exploitation attempt. +- Investigate the user account associated with the alert to determine if it has a history of privilege escalation attempts or other suspicious activities. +- Analyze system logs and security events for any additional indicators of compromise or related suspicious activities that occurred before or after the alert. +- Assess the patch status of the affected system to determine if it is vulnerable to CVE-2021-4034 and ensure that appropriate security updates have been applied. + +### False positive analysis + +- Routine administrative tasks involving pkexec may trigger alerts if they involve environment variable manipulation. Review the context of the command execution to determine if it aligns with expected administrative behavior. +- Custom scripts or applications that legitimately use environment variables in their execution paths might be flagged. Identify these scripts and consider adding them to an exception list if they are verified as non-threatening. +- Automated system management tools that modify environment variables for legitimate purposes could cause false positives. Monitor these tools and exclude their known safe operations from the detection rule. +- Development environments where developers frequently test applications with varying environment variables might generate alerts. Establish a baseline of normal activity and exclude these patterns if they are consistent and verified as safe. +- Scheduled tasks or cron jobs that involve environment variable changes should be reviewed. If they are part of regular system maintenance, document and exclude them from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker. +- Terminate any suspicious processes associated with pkexec or unauthorized privilege escalation attempts to halt ongoing exploitation. +- Conduct a thorough review of system logs and file access records to identify any unauthorized changes or access patterns, focusing on the presence of GCONV_PATH in file paths. +- Revert any unauthorized changes made by the attacker, such as modifications to critical system files or configurations, to restore system integrity. +- Apply the latest security patches and updates to the polkit package to address CVE-2021-4034 and prevent future exploitation. +- Implement enhanced monitoring and alerting for similar privilege escalation attempts, ensuring that any future attempts are detected and responded to promptly. +- Report the incident to relevant internal security teams and, if necessary, escalate to external authorities or cybersecurity partners for further investigation and support.""" references = ["https://seclists.org/oss-sec/2022/q1/80", "https://haxx.in/files/blasty-vs-pkexec.c"] risk_score = 73 rule_id = "8da41fc9-7735-4b24-9cc6-c78dfc9fc9c9" @@ -63,41 +96,6 @@ type = "eql" query = ''' file where host.os.type == "linux" and file.path : "/*GCONV_PATH*" ''' -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 Privilege Escalation via PKEXEC - -Polkit's pkexec is a command-line utility that allows an authorized user to execute commands as another user, typically root, in Linux environments. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, enabling unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on environment variable manipulation to preemptively flag potential threats. - -### Possible investigation steps - -- Review the alert details to confirm the presence of the file path pattern "/*GCONV_PATH*" on a Linux host, as this is indicative of the potential exploitation attempt. -- Examine the process execution history on the affected host to identify any instances of pkexec being executed around the time of the alert. Look for unusual or unauthorized command executions. -- Check the environment variables set during the pkexec execution to identify any suspicious or unauthorized modifications that could indicate an exploitation attempt. -- Investigate the user account associated with the alert to determine if it has a history of privilege escalation attempts or other suspicious activities. -- Analyze system logs and security events for any additional indicators of compromise or related suspicious activities that occurred before or after the alert. -- Assess the patch status of the affected system to determine if it is vulnerable to CVE-2021-4034 and ensure that appropriate security updates have been applied. - -### False positive analysis - -- Routine administrative tasks involving pkexec may trigger alerts if they involve environment variable manipulation. Review the context of the command execution to determine if it aligns with expected administrative behavior. -- Custom scripts or applications that legitimately use environment variables in their execution paths might be flagged. Identify these scripts and consider adding them to an exception list if they are verified as non-threatening. -- Automated system management tools that modify environment variables for legitimate purposes could cause false positives. Monitor these tools and exclude their known safe operations from the detection rule. -- Development environments where developers frequently test applications with varying environment variables might generate alerts. Establish a baseline of normal activity and exclude these patterns if they are consistent and verified as safe. -- Scheduled tasks or cron jobs that involve environment variable changes should be reviewed. If they are part of regular system maintenance, document and exclude them from triggering alerts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker. -- Terminate any suspicious processes associated with pkexec or unauthorized privilege escalation attempts to halt ongoing exploitation. -- Conduct a thorough review of system logs and file access records to identify any unauthorized changes or access patterns, focusing on the presence of GCONV_PATH in file paths. -- Revert any unauthorized changes made by the attacker, such as modifications to critical system files or configurations, to restore system integrity. -- Apply the latest security patches and updates to the polkit package to address CVE-2021-4034 and prevent future exploitation. -- Implement enhanced monitoring and alerting for similar privilege escalation attempts, ensuring that any future attempts are detected and responded to promptly. -- Report the incident to relevant internal security teams and, if necessary, escalate to external authorities or cybersecurity partners for further investigation and support.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml index a3ba3a40cad..99c6f5add45 100644 --- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml +++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml @@ -2,9 +2,7 @@ creation_date = "2023/07/28" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -19,6 +17,41 @@ index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] language = "eql" license = "Elastic License v2" name = "Potential Shell via Wildcard Injection Detected" +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 Shell via Wildcard Injection Detected + +Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts. + +### Possible investigation steps + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`. +- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation. +- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation. +- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise. +- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign. +- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account. + +### False positive analysis + +- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns. +- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities. +- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments. +- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" references = ["https://www.exploit-db.com/papers/33930"] risk_score = 47 rule_id = "0b803267-74c5-444d-ae29-32b5db2d562a" @@ -73,64 +106,30 @@ sequence by host.id with maxspan=1s process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] by process.parent.entity_id ''' -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 Shell via Wildcard Injection Detected - -Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts. - -### Possible investigation steps - -- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`. -- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation. -- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation. -- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise. -- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign. -- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account. - -### False positive analysis - -- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe. -- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns. -- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities. -- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments. -- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary alerts. - -### Response and remediation - -- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. -- Terminate any suspicious processes identified in the alert, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`. -- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts. -- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed. -- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. -- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files. -- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1068" name = "Exploitation for Privilege Escalation" reference = "https://attack.mitre.org/techniques/T1068/" + [rule.threat.tactic] id = "TA0004" name = "Privilege Escalation" reference = "https://attack.mitre.org/tactics/TA0004/" - [[rule.threat]] framework = "MITRE ATT&CK" - [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" + [rule.threat.tactic] id = "TA0002" name = "Execution" reference = "https://attack.mitre.org/tactics/TA0002/" + diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml index 259c129272f..bd74f25d548 100644 --- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml +++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/30" integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -15,10 +13,52 @@ that can be chosen arbitrarily. By using the sudo privileges, the command "sudo representing the root user. This exploit may work for sudo versions prior to v1.28. """ from = "now-9m" -index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-crowdstrike.fdr*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Potential Sudo Privilege Escalation via CVE-2019-14287" +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 Sudo Privilege Escalation via CVE-2019-14287 + +CVE-2019-14287 exploits a flaw in certain sudo versions, allowing users to execute commands as root by bypassing user ID verification. Attackers can misuse this to gain unauthorized root access, posing significant security risks. The detection rule identifies suspicious sudo commands indicative of this exploit, focusing on specific command patterns that translate to root execution, thereby alerting security teams to potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the suspicious command pattern "sudo -u#-1" in the process arguments, as this is indicative of the CVE-2019-14287 exploit attempt. +- Identify the user account associated with the process execution to determine if the user should have legitimate access to execute commands with elevated privileges. +- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. +- Check the version of sudo installed on the affected system to verify if it is vulnerable to CVE-2019-14287, specifically versions prior to v1.28. +- Investigate the source IP address and hostname of the affected system to assess if it is part of a larger attack pattern or if there are other systems potentially compromised. +- Review system logs and audit trails for any additional unauthorized access attempts or privilege escalation activities around the time of the alert. +- If possible, isolate the affected system to prevent further unauthorized access while conducting a more thorough forensic analysis. + +### False positive analysis + +- Legitimate administrative tasks using sudo with unconventional user ID arguments may trigger the rule. Review the context of the command execution to determine if it aligns with expected administrative activities. +- Automated scripts or maintenance tools that use sudo with arbitrary user IDs for testing or configuration purposes might be flagged. Identify and document these scripts, then create exceptions in the monitoring system to exclude them from alerts. +- Development environments where developers have elevated privileges for testing purposes could generate false positives. Ensure that such environments are well-documented and consider excluding them from this specific rule if they consistently trigger alerts. +- Security tools or monitoring systems that simulate attacks for testing detection capabilities may inadvertently trigger this rule. Coordinate with security teams to whitelist these tools or adjust their configurations to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified with the command pattern "sudo -u#-1" to halt any ongoing unauthorized activities. +- Conduct a thorough review of system logs and sudo logs to identify any additional unauthorized access attempts or successful privilege escalations. +- Reset passwords and review user accounts on the affected system to ensure no unauthorized accounts have been created or existing accounts have been compromised. +- Apply patches or upgrade sudo to a version later than v1.28 to mitigate the vulnerability exploited by CVE-2019-14287. +- Monitor the network for any signs of data exfiltration or further exploitation attempts, using enhanced logging and alerting mechanisms. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and actions taken.""" references = ["https://www.exploit-db.com/exploits/47502"] risk_score = 47 rule_id = "8af5b42f-8d74-48c8-a8d0-6d14b4197288" @@ -69,41 +109,6 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "sudo" and process.args == "-u#-1" ''' -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 Sudo Privilege Escalation via CVE-2019-14287 - -CVE-2019-14287 exploits a flaw in certain sudo versions, allowing users to execute commands as root by bypassing user ID verification. Attackers can misuse this to gain unauthorized root access, posing significant security risks. The detection rule identifies suspicious sudo commands indicative of this exploit, focusing on specific command patterns that translate to root execution, thereby alerting security teams to potential privilege escalation attempts. - -### Possible investigation steps - -- Review the alert details to confirm the presence of the suspicious command pattern "sudo -u#-1" in the process arguments, as this is indicative of the CVE-2019-14287 exploit attempt. -- Identify the user account associated with the process execution to determine if the user should have legitimate access to execute commands with elevated privileges. -- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. -- Check the version of sudo installed on the affected system to verify if it is vulnerable to CVE-2019-14287, specifically versions prior to v1.28. -- Investigate the source IP address and hostname of the affected system to assess if it is part of a larger attack pattern or if there are other systems potentially compromised. -- Review system logs and audit trails for any additional unauthorized access attempts or privilege escalation activities around the time of the alert. -- If possible, isolate the affected system to prevent further unauthorized access while conducting a more thorough forensic analysis. - -### False positive analysis - -- Legitimate administrative tasks using sudo with unconventional user ID arguments may trigger the rule. Review the context of the command execution to determine if it aligns with expected administrative activities. -- Automated scripts or maintenance tools that use sudo with arbitrary user IDs for testing or configuration purposes might be flagged. Identify and document these scripts, then create exceptions in the monitoring system to exclude them from alerts. -- Development environments where developers have elevated privileges for testing purposes could generate false positives. Ensure that such environments are well-documented and consider excluding them from this specific rule if they consistently trigger alerts. -- Security tools or monitoring systems that simulate attacks for testing detection capabilities may inadvertently trigger this rule. Coordinate with security teams to whitelist these tools or adjust their configurations to prevent unnecessary alerts. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. -- Terminate any suspicious processes identified with the command pattern "sudo -u#-1" to halt any ongoing unauthorized activities. -- Conduct a thorough review of system logs and sudo logs to identify any additional unauthorized access attempts or successful privilege escalations. -- Reset passwords and review user accounts on the affected system to ensure no unauthorized accounts have been created or existing accounts have been compromised. -- Apply patches or upgrade sudo to a version later than v1.28 to mitigate the vulnerability exploited by CVE-2019-14287. -- Monitor the network for any signs of data exfiltration or further exploitation attempts, using enhanced logging and alerting mechanisms. -- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and actions taken.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml index 110652ad38b..959c700af03 100644 --- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml +++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml @@ -2,9 +2,7 @@ creation_date = "2022/08/30" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/02/04" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -18,6 +16,39 @@ index = ["auditbeat-*", "endgame-*", "logs-endpoint.events.process*", "logs-sent language = "eql" license = "Elastic License v2" name = "Namespace Manipulation Using Unshare" +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 Namespace Manipulation Using Unshare + +The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. + +### Possible investigation steps + +- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare. +- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised. +- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls. +- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts. +- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign. + +### False positive analysis + +- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables. +- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts. +- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives. +- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts. + +### Response and remediation + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query. +- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution. +- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted. +- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected. +- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.""" references = [ "https://man7.org/linux/man-pages/man1/unshare.1.html", "https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/", @@ -81,39 +112,6 @@ process.executable: "/usr/bin/unshare" and not process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") and not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java") ''' -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 Namespace Manipulation Using Unshare - -The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. - -### Possible investigation steps - -- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare. -- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised. -- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls. -- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts. -- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign. - -### False positive analysis - -- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables. -- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts. -- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives. -- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts. - -### Response and remediation - -- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. -- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query. -- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution. -- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted. -- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected. -- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences. -- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.""" [[rule.threat]] diff --git a/rules/threat_intel/threat_intel_rapid7_threat_command.toml b/rules/threat_intel/threat_intel_rapid7_threat_command.toml index bab9e900435..949b292ceda 100644 --- a/rules/threat_intel/threat_intel_rapid7_threat_command.toml +++ b/rules/threat_intel/threat_intel_rapid7_threat_command.toml @@ -2,9 +2,7 @@ creation_date = "2024/05/29" integration = ["ti_rapid7_threat_command"] maturity = "production" -min_stack_comments = "Breaking change at 8.13.0 for Rapid7 Threat Command Integration" -min_stack_version = "8.13.0" -updated_date = "2025/01/10" +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -41,11 +39,11 @@ Additional investigation can be done by reviewing the source of the activity and """ references = [ "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html", - "https://docs.elastic.co/integrations/ti_rapid7_threat_command"] + "https://docs.elastic.co/integrations/ti_rapid7_threat_command", +] risk_score = 99 rule_id = "3a657da0-1df2-11ef-a327-f661ea17fbcc" setup = """ - ## Setup This rule needs threat intelligence indicators to work. @@ -81,9 +79,6 @@ tags = [ threat_index = ["logs-ti_rapid7_threat_command_latest.vulnerability"] threat_indicator_path = "rapid7.tc.vulnerability" threat_language = "kuery" -threat_query = """ -@timestamp >= "now-30d/d" and vulnerability.id : * and event.module: ti_rapid7_threat_command -""" timestamp_override = "event.ingested" type = "threat_match" @@ -92,6 +87,12 @@ vulnerability.id : * ''' + +threat_query = ''' +@timestamp >= "now-30d/d" and vulnerability.id : * and event.module: ti_rapid7_threat_command +''' + + [[rule.filters]] [rule.filters."$state"] diff --git a/rules/windows/command_and_control_teamviewer_remote_file_copy.toml b/rules/windows/command_and_control_teamviewer_remote_file_copy.toml index 63d8333bd37..925a6eb1859 100644 --- a/rules/windows/command_and_control_teamviewer_remote_file_copy.toml +++ b/rules/windows/command_and_control_teamviewer_remote_file_copy.toml @@ -2,9 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/02/03" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [transform] [[transform.osquery]] diff --git a/rules/windows/credential_access_kerberoasting_unusual_process.toml b/rules/windows/credential_access_kerberoasting_unusual_process.toml index 7977da3371d..7f3932dcef5 100644 --- a/rules/windows/credential_access_kerberoasting_unusual_process.toml +++ b/rules/windows/credential_access_kerberoasting_unusual_process.toml @@ -2,9 +2,7 @@ creation_date = "2020/11/02" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/02/03" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [transform] [[transform.osquery]] diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml index a3ec450fcf1..548fd088051 100644 --- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml +++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml @@ -2,9 +2,7 @@ creation_date = "2020/12/14" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -17,6 +15,41 @@ index = ["logs-endpoint.events.process-*", "endgame-*", "logs-sentinel_one_cloud language = "eql" license = "Elastic License v2" name = "Suspicious SolarWinds Child Process" +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 SolarWinds Child Process + +SolarWinds is a widely used IT management software that operates critical network and system monitoring functions. Adversaries may exploit its trusted processes to execute unauthorized programs, leveraging its elevated privileges to bypass security controls. The detection rule identifies unusual child processes spawned by SolarWinds' core services, excluding known legitimate operations, to flag potential malicious activity. + +### Possible investigation steps + +- Review the details of the triggered alert to identify the specific child process name and executable path that caused the alert. +- Check the parent process details, specifically SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, to confirm its legitimacy and ensure it is running from the expected directory. +- Investigate the child process's code signature to determine if it is trusted or if there are any anomalies in the signature that could indicate tampering. +- Analyze the historical activity of the suspicious child process on the host to identify any patterns or previous instances of execution that could provide context. +- Correlate the suspicious process activity with other security events or logs from the same host to identify any related malicious behavior or indicators of compromise. +- Consult threat intelligence sources to determine if the suspicious process or executable path is associated with known malware or adversary techniques. + +### False positive analysis + +- Legitimate SolarWinds updates or patches may trigger the rule. Ensure that the process code signature is verified as trusted and matches known update signatures. +- Custom scripts or tools integrated with SolarWinds for automation purposes might be flagged. Review these processes and add them to the exclusion list if they are verified as safe and necessary for operations. +- Third-party plugins or extensions that interact with SolarWinds could be misidentified. Validate these plugins and consider excluding them if they are from a trusted source and essential for functionality. +- Scheduled tasks or maintenance activities that involve SolarWinds processes may appear suspicious. Confirm these tasks are part of regular operations and exclude them if they are consistent with expected behavior. +- Temporary diagnostic or troubleshooting tools used by IT staff might be detected. Ensure these tools are authorized and add them to the exclusion list if they are frequently used and pose no threat. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious child processes identified that are not part of the known legitimate operations list, ensuring that no malicious programs continue to execute. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or unauthorized changes. +- Restore the affected system from a known good backup to ensure that any potential malware or unauthorized changes are removed. +- Update all SolarWinds software and related components to the latest versions to patch any known vulnerabilities that could be exploited. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of suspicious activity, focusing on unusual child processes spawned by SolarWinds services. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts need to be addressed.""" references = [ "https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html", "https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20CHILD%20PROCESSES%20(METHODOLOGY).ioc", @@ -59,41 +92,6 @@ process where host.os.type == "windows" and event.type == "start" and ) and not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe") ''' -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 SolarWinds Child Process - -SolarWinds is a widely used IT management software that operates critical network and system monitoring functions. Adversaries may exploit its trusted processes to execute unauthorized programs, leveraging its elevated privileges to bypass security controls. The detection rule identifies unusual child processes spawned by SolarWinds' core services, excluding known legitimate operations, to flag potential malicious activity. - -### Possible investigation steps - -- Review the details of the triggered alert to identify the specific child process name and executable path that caused the alert. -- Check the parent process details, specifically SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, to confirm its legitimacy and ensure it is running from the expected directory. -- Investigate the child process's code signature to determine if it is trusted or if there are any anomalies in the signature that could indicate tampering. -- Analyze the historical activity of the suspicious child process on the host to identify any patterns or previous instances of execution that could provide context. -- Correlate the suspicious process activity with other security events or logs from the same host to identify any related malicious behavior or indicators of compromise. -- Consult threat intelligence sources to determine if the suspicious process or executable path is associated with known malware or adversary techniques. - -### False positive analysis - -- Legitimate SolarWinds updates or patches may trigger the rule. Ensure that the process code signature is verified as trusted and matches known update signatures. -- Custom scripts or tools integrated with SolarWinds for automation purposes might be flagged. Review these processes and add them to the exclusion list if they are verified as safe and necessary for operations. -- Third-party plugins or extensions that interact with SolarWinds could be misidentified. Validate these plugins and consider excluding them if they are from a trusted source and essential for functionality. -- Scheduled tasks or maintenance activities that involve SolarWinds processes may appear suspicious. Confirm these tasks are part of regular operations and exclude them if they are consistent with expected behavior. -- Temporary diagnostic or troubleshooting tools used by IT staff might be detected. Ensure these tools are authorized and add them to the exclusion list if they are frequently used and pose no threat. - -### Response and remediation - -- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. -- Terminate any suspicious child processes identified that are not part of the known legitimate operations list, ensuring that no malicious programs continue to execute. -- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or unauthorized changes. -- Restore the affected system from a known good backup to ensure that any potential malware or unauthorized changes are removed. -- Update all SolarWinds software and related components to the latest versions to patch any known vulnerabilities that could be exploited. -- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of suspicious activity, focusing on unusual child processes spawned by SolarWinds services. -- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts need to be addressed.""" [[rule.threat]] diff --git a/rules/windows/impact_backup_file_deletion.toml b/rules/windows/impact_backup_file_deletion.toml index 1e0c2a2c735..a1f0d3d8726 100644 --- a/rules/windows/impact_backup_file_deletion.toml +++ b/rules/windows/impact_backup_file_deletion.toml @@ -2,9 +2,7 @@ creation_date = "2021/10/01" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml index ac992d40a27..29f14f2b79d 100644 --- a/rules/windows/persistence_msoffice_startup_registry.toml +++ b/rules/windows/persistence_msoffice_startup_registry.toml @@ -2,9 +2,7 @@ creation_date = "2023/08/22" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2025/01/15" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] @@ -14,35 +12,15 @@ specify a DLL which will be executed every time an MS Office application is star persistence on a compromised host. """ from = "now-9m" -index = ["logs-endpoint.events.registry-*", "logs-m365_defender.event-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"] +index = [ + "logs-endpoint.events.registry-*", + "logs-m365_defender.event-*", + "endgame-*", + "logs-sentinel_one_cloud_funnel.*", +] language = "eql" license = "Elastic License v2" name = "Office Test Registry Persistence" -references = [ - "https://unit42.paloaltonetworks.com/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/", -] -risk_score = 21 -rule_id = "14dab405-5dd9-450c-8106-72951af2391f" -severity = "low" -tags = [ - "Domain: Endpoint", - "OS: Windows", - "Use Case: Threat Detection", - "Tactic: Persistence", - "Tactic: Defense Evasion", - "Data Source: Elastic Defend", - "Data Source: Elastic Endgame", - "Data Source: Microsoft Defender for Endpoint", - "Data Source: SentinelOne", - "Resources: Investigation Guide", -] -timestamp_override = "event.ingested" -type = "eql" - -query = ''' -registry where host.os.type == "windows" and event.action != "deletion" and - registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*" -''' note = """## Triage and analysis > **Disclaimer**: @@ -77,6 +55,31 @@ The Office Test Registry key in Windows environments allows specifying a DLL to - Review recent user activity and system logs to identify any unauthorized access or changes that may have led to the registry modification, and reset credentials if necessary. - Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. - Implement enhanced monitoring and alerting for similar registry modifications across the network to detect and respond to future attempts promptly.""" +references = [ + "https://unit42.paloaltonetworks.com/unit42-technical-walkthrough-office-test-persistence-method-used-in-recent-sofacy-attacks/", +] +risk_score = 21 +rule_id = "14dab405-5dd9-450c-8106-72951af2391f" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Defense Evasion", + "Data Source: Elastic Defend", + "Data Source: Elastic Endgame", + "Data Source: Microsoft Defender for Endpoint", + "Data Source: SentinelOne", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" + +query = ''' +registry where host.os.type == "windows" and event.action != "deletion" and + registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*" +''' [[rule.threat]] diff --git a/rules_building_block/execution_github_new_event_action_for_pat.toml b/rules_building_block/execution_github_new_event_action_for_pat.toml index e8ab2101ae1..493f8c1d897 100644 --- a/rules_building_block/execution_github_new_event_action_for_pat.toml +++ b/rules_building_block/execution_github_new_event_action_for_pat.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml index af1fe749b4a..7fe869ba5b9 100644 --- a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml +++ b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/execution_github_new_repo_interaction_for_user.toml b/rules_building_block/execution_github_new_repo_interaction_for_user.toml index 5aabab32d3c..d49d6623008 100644 --- a/rules_building_block/execution_github_new_repo_interaction_for_user.toml +++ b/rules_building_block/execution_github_new_repo_interaction_for_user.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/execution_github_repo_created.toml b/rules_building_block/execution_github_repo_created.toml index 40ab0a8d88b..0b5f2635db1 100644 --- a/rules_building_block/execution_github_repo_created.toml +++ b/rules_building_block/execution_github_repo_created.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml index 46e625fe8c3..60a170fd098 100644 --- a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml +++ b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/impact_github_member_removed_from_organization.toml b/rules_building_block/impact_github_member_removed_from_organization.toml index 7153494eaa4..dd033c85e0e 100644 --- a/rules_building_block/impact_github_member_removed_from_organization.toml +++ b/rules_building_block/impact_github_member_removed_from_organization.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/impact_github_pat_access_revoked.toml b/rules_building_block/impact_github_pat_access_revoked.toml index 4dd48492420..f94c6f93197 100644 --- a/rules_building_block/impact_github_pat_access_revoked.toml +++ b/rules_building_block/impact_github_pat_access_revoked.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/impact_github_user_blocked_from_organization.toml b/rules_building_block/impact_github_user_blocked_from_organization.toml index 60fb77cb60d..fe47316b132 100644 --- a/rules_building_block/impact_github_user_blocked_from_organization.toml +++ b/rules_building_block/impact_github_user_blocked_from_organization.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml index 173fa693fb1..37549956dce 100644 --- a/rules_building_block/initial_access_github_new_ip_address_for_pat.toml +++ b/rules_building_block/initial_access_github_new_ip_address_for_pat.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/initial_access_github_new_ip_address_for_user.toml b/rules_building_block/initial_access_github_new_ip_address_for_user.toml index b9e80d855c5..37c0310bccb 100644 --- a/rules_building_block/initial_access_github_new_ip_address_for_user.toml +++ b/rules_building_block/initial_access_github_new_ip_address_for_user.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml index de9956f7246..f0283064362 100644 --- a/rules_building_block/initial_access_github_new_user_agent_for_pat.toml +++ b/rules_building_block/initial_access_github_new_user_agent_for_pat.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/initial_access_github_new_user_agent_for_user.toml b/rules_building_block/initial_access_github_new_user_agent_for_user.toml index 15d3b4dfcf7..00894a02e93 100644 --- a/rules_building_block/initial_access_github_new_user_agent_for_user.toml +++ b/rules_building_block/initial_access_github_new_user_agent_for_user.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/persistence_github_new_pat_for_user.toml b/rules_building_block/persistence_github_new_pat_for_user.toml index 1e6f93f050b..11d8588d202 100644 --- a/rules_building_block/persistence_github_new_pat_for_user.toml +++ b/rules_building_block/persistence_github_new_pat_for_user.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/persistence_github_new_user_added_to_organization.toml b/rules_building_block/persistence_github_new_user_added_to_organization.toml index 70bec844ae0..ebf6de67223 100644 --- a/rules_building_block/persistence_github_new_user_added_to_organization.toml +++ b/rules_building_block/persistence_github_new_user_added_to_organization.toml @@ -3,9 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" -min_stack_version = "8.13.0" -min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." +updated_date = "2025/03/20" [rule] author = ["Elastic"] diff --git a/rules_building_block/persistence_web_server_sus_file_creation.toml b/rules_building_block/persistence_web_server_sus_file_creation.toml index 805e785a620..8f4907918aa 100644 --- a/rules_building_block/persistence_web_server_sus_file_creation.toml +++ b/rules_building_block/persistence_web_server_sus_file_creation.toml @@ -3,18 +3,16 @@ bypass_bbr_timing = true creation_date = "2025/03/06" integration = ["endpoint"] maturity = "production" -min_stack_comments = "ES|QL rule type in technical preview as of 8.13" -min_stack_version = "8.13.0" -updated_date = "2025/03/06" +updated_date = "2025/03/20" [rule] author = ["Elastic"] building_block_type = "default" description = """ -This rule detects unusual file creations from a web server parent process. Adversaries may attempt to -create files from a web server parent process to establish persistence, execute malicious scripts, or -exfiltrate data. ES|QL rules have limited fields available in its alert documents. Make sure to review -the original documents to aid in the investigation of this alert. +This rule detects unusual file creations from a web server parent process. Adversaries may attempt to create files from +a web server parent process to establish persistence, execute malicious scripts, or exfiltrate data. ES|QL rules have +limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation +of this alert. """ from = "now-61m" interval = "1h" @@ -61,6 +59,7 @@ tags = [ ] timestamp_override = "event.ingested" type = "esql" + query = ''' from logs-endpoint.events.file-* | keep @timestamp, host.os.type, event.type, event.action, user.name, user.id, process.name, process.executable, file.path, agent.id @@ -87,51 +86,51 @@ from logs-endpoint.events.file-* | limit 100 ''' + [[rule.threat]] framework = "MITRE ATT&CK" - -[rule.threat.tactic] -name = "Persistence" -id = "TA0003" -reference = "https://attack.mitre.org/tactics/TA0003/" - [[rule.threat.technique]] id = "T1505" name = "Server Software Component" reference = "https://attack.mitre.org/techniques/T1505/" - [[rule.threat.technique.subtechnique]] id = "T1505.003" name = "Web Shell" reference = "https://attack.mitre.org/techniques/T1505/003/" -[[rule.threat]] -framework = "MITRE ATT&CK" -[rule.threat.tactic] -name = "Execution" -id = "TA0002" -reference = "https://attack.mitre.org/tactics/TA0002/" +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" +[[rule.threat]] +framework = "MITRE ATT&CK" [[rule.threat.technique]] id = "T1059" name = "Command and Scripting Interpreter" reference = "https://attack.mitre.org/techniques/T1059/" - [[rule.threat.technique.subtechnique]] id = "T1059.004" name = "Unix Shell" reference = "https://attack.mitre.org/techniques/T1059/004/" + + +[rule.threat.tactic] +id = "TA0002" +name = "Execution" +reference = "https://attack.mitre.org/tactics/TA0002/" [[rule.threat]] framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1071" +name = "Application Layer Protocol" +reference = "https://attack.mitre.org/techniques/T1071/" + [rule.threat.tactic] -name = "Command and Control" id = "TA0011" +name = "Command and Control" reference = "https://attack.mitre.org/tactics/TA0011/" -[[rule.threat.technique]] -name = "Application Layer Protocol" -id = "T1071" -reference = "https://attack.mitre.org/techniques/T1071/"