rule login_enumeration_exfiltration {
meta:
description = "Detects when a user logs in without multifactor authentication (MFA) and then performs enumeration and exfiltration"
rule_name = "Login Without MFA, Enumeration, Exfiltration"
severity = "High"
events:
// Detection with name "Console Login Without MFA"
// The affected user is saved as $target_user
$login_without_mfa.detection.detection.rule_name = /Console Login Without MFA/
$target_user = $login_without_mfa.detection.detection.outcomes["target_user"]
// Any detection with a rule name containing 'enumeration'
// The user performing enumeration is the user that logged in without mfa
$enumeration.detection.detection.rule_name = /enumeration/ nocase
$enumeration.detection.detection.outcomes["principal_users"] = $target_user
// Any detection with the mitre tactic 'TA0010' (Exfiltration)
// The user performing exfiltration is the user that logged in without mfa
$exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"
$exfiltration.detection.detection.outcomes["principal_users"] = $target_user
match:
// Looks for detections over a 24 hour period
$target_user over 24h
condition:
// All 3 must occur for a single user
$login_without_mfa and $enumeration and $exfiltration
}
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["Composite detections **Note:** This feature is covered by [Pre-GA Offerings Terms](https://chronicle.security/legal/service-terms/) of the Google Security Operations Service Specific Terms. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the [Google SecOps Technical Support Service guidelines](https://chronicle.security/legal/technical-support-services-guidelines/) and the [Google SecOps Service Specific Terms](https://chronicle.security/legal/service-terms/). \nSupported in: \nGoogle secops [SIEM](/chronicle/docs/secops/google-secops-siem-toc)\n\nComposite detection lets you interconnect rules so that the output\nof one rule acts as the input for another rule. This capability lets you\ncreate rules with more complexity and flexibility. By correlating and analyzing events\nacross different data sources and timeframes, composite detection overcomes the\nlimitations of isolated event detection.\n\nBenefits of composite detection\n\n- **Unmasking Multi-Stage Attacks**: Cyberattacks are often multi-faceted and interconnected. Composite detection helps to reveal the attack narrative by linking seemingly isolated incidents. For example, a composite rule can identify the\n entire attack sequence, such as an initial breach, followed by privilege escalation, and data exfiltration.\n\n- **Taming Alert Fatigue**: Prioritize critical threats and mitigate alert fatigue\n by implementing consumer rules. These rules consolidate and filter noisy alerts\n generated by input rules, enabling a more focused response, which can help prioritize high-impact incidents and minimize alert fatigue.\n\n- **Enhancing Detection Accuracy**: Combine insights from UDM events, other rule\n detections, entity information, UEBA findings, and data tables to create\n accurate detection logic.\n\n- **Streamlining Complex Logic**: Break down complex detection scenarios into\n manageable, interconnected, and reusable rules to streamline development and upkeep.\n\nComposite detection terms and concepts\n\n- **Detection**: the result of a rule and can also be referred to as an alert.\n\n- **Composite** : a series of interconnected rules where the output of one rule serves as the input for the next. For example, in the composite rule sequence `rule1 -\u003e rule2` -\\\u003e `rule3`, the detections generated by `rule1` are passed to `rule2`, which processes them to generate new detections. These detections are then consumed by `rule3` to produce its final output.\n\n- **Input rule**: a rule whose detections are used as input for\n another rule. Any rule can function as a input rule, and there is no specific\n designation required. Input rules use entities and events as a input.\n They don't use detections as input.\n\n- **Composite rule** : a rule that uses detections as input in the rule text.\n Composite rules must have a `match` section.\n\nAdvanced concepts\n\nSingle-event detection rules\n\nGoogle SecOps does not allow single-event composite rules. This means that any rule that\nuses detections as an input source must have a [`match` section](/chronicle/docs/detection/yara-l-2-0-syntax#match_section_syntax).\n\nDetection latency\n\nWe recommend composing composite rules only on single-event input rules due to scheduling\nbehavior. Single-event rules run in near real-time, so their detections are typically available by the time the composite rule executes.\nIf a composite rule depends on a multi-event rule as input, there's a risk that the input rule might run after the composite rule's scheduled execution. This can lead to delays or missed detections in the composite rule.\n\nTestRule and Retrohunt\n\nTesting or running a retrohunt on a composite rule only runs the specific rule that\nyou selected using existing detections. To run the entire composite, you must manually start retrohunts from the first rule in the sequence, wait for each run to finish, and then proceed to the next rule.\n\nRunning a test on a rule does not persist or write the detections to the\ndatabase and composite rules require the input detections to exist in the database.\n\nRunning a test on a rule does not persist or write the detections to the database. Because composite rules require the input detections to exist in the database to function, you can't use TestRule to validate a composite rule.\n\nConstruct composite rules\n\nYou create composite rules using combinations of input rules and composite rules.\n\nInput rules\n\nInput rules are the foundation of your composite rule. They detect specific events\nor conditions that, when combined, indicate malicious activity.\nTo configure an input rule, do the following:\n\n1. Create a new rule or reuse an existing one.\n\n2. Disable alerting. This\n prevents these input rules from generating individual alerts. By using this configuration, you can prioritize the more critical\n alerts generated by composite rules, which assess the entire chain of events.\n\n3. Use the `outcome` section to define the variables accessible to chaining rules.\n\nThe following producer rule example detects failed logins. \n\n rule failed_login {\n meta:\n\n events:\n $e.metadata.event_type = \"USER_LOGIN\"\n any $e.security_result.action = \"BLOCK\"\n\n outcome:\n $target_user = $e.target.user.userid\n\n condition:\n $e\n }\n\nThis rule identifies logins that are blocked and provides the associated user.\n\nComposite rules\n\nWriting a rule that uses detections is mostly the same as a rule that uses UDM,\nexcept that the source and the available fields are different. To reference a\ndetection field use the keyword `detection` as the source: `$eventname.detection.field1.field2`.\n\nThe subfields that are available under the `detection` source can be found in\nthe [collection resource](/chronicle/docs/reference/rest/v1alpha/Collection).\n\nFollowing are the common fields in collections:\n\n- `$d.detection.detection.rule_id`\n\n- `$d.detection.detection.detection_fields[\"match_var_name\"]`\n\n- `$d.detection.detection.outcomes[\"outcome_name\"]`\n\nThe following example rule detects logins without MFA, enumeration, and exfiltration. \n\n rule login_enumeration_exfiltration {\n meta:\n description = \"Detects when a user logs in without multifactor authentication (MFA) and then performs enumeration and exfiltration\"\n rule_name = \"Login Without MFA, Enumeration, Exfiltration\"\n severity = \"High\"\n\n events:\n // Detection with name \"Console Login Without MFA\"\n // The affected user is saved as $target_user\n $login_without_mfa.detection.detection.rule_name = /Console Login Without MFA/\n $target_user = $login_without_mfa.detection.detection.outcomes[\"target_user\"]\n\n // Any detection with a rule name containing 'enumeration'\n // The user performing enumeration is the user that logged in without mfa\n $enumeration.detection.detection.rule_name = /enumeration/ nocase\n $enumeration.detection.detection.outcomes[\"principal_users\"] = $target_user\n\n // Any detection with the mitre tactic 'TA0010' (Exfiltration)\n // The user performing exfiltration is the user that logged in without mfa\n $exfiltration.detection.detection.rule_labels[\"tactic\"] = \"TA0010\"\n $exfiltration.detection.detection.outcomes[\"principal_users\"] = $target_user\n\n match:\n // Looks for detections over a 24 hour period\n $target_user over 24h\n\n condition:\n // All 3 must occur for a single user\n $login_without_mfa and $enumeration and $exfiltration\n }\n\nHierarchical detections\n\nComposite detection lets you create a hierarchical detection system. Lower-level\ninput rules identify isolated suspicious events. Higher-level composite rules then consume the output of these input rules to correlate across time, entities, and data sources.\nThis approach helps correlate this information with data from other sources to detect multi-stage attack patterns that\nsingle-event rules might miss.\n\nGoogle Security Operations supports up to three levels\nof composition, providing a balance between detection deep detection logic and manageable complexity.\n\nFor example:\n\n- **Level 1**: Input rules detect individual suspicious events. For example,\n failed login events, unusual file access.\n\n- **Level 2**: Composite rules correlate level 1 detections. For example, failed login events\n followed by suspicious file access.\n\n- **Level 3**: Higher-level composite rules combine level 2 detections and other data\n for even more sophisticated detection. For example, a level 2 detection regarding the\n authentication and a level 2 detection regarding the security\n posture of the device being used.\n\nConsiderations when writing composite rules\n\nWhen you update an input rule that is used in one or more composite rules, the system automatically creates a new version of that input rule. This applies to both logic updates (`condition`, `events`, `outcomes`) and\nmetadata updates (name, description, severity). Composite rules continue to operate\nusing the new version. We recommend to test updated input rules and their\ndownstream composite rules to ensure the intended behavior.\n\nLimitations\n\nComposite rules have the following limitations.\n\nDetection-only rules and entity risk score\n\nDetection-only rules (rules that use only detection data as a source, and not event or entity data)\ndon't contribute to entity risk score. Any risk\nscore that is set for a detection-only rule only applies to the detections\ncreated by that rule. It won't contribute to any aggregate entity risk score.\n\n**Need more help?** [Get answers from Community members and Google SecOps professionals.](https://security.googlecloudcommunity.com/google-security-operations-2)"]]
