nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_suppression_rule_created.toml

@@ -0,0 +1,94 @@
+[metadata]
+creation_date = "2021/08/27"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies the creation of suppression rules in Azure. Suppression rules are a mechanism used to suppress alerts
+previously identified as false positives or too noisy to be in production. This mechanism can be abused or mistakenly
+configured, resulting in defense evasions and loss of security visibility.
+"""
+false_positives = [
+    """
+    Suppression Rules can be created legitimately by a system administrator. Verify whether the user identity, user
+    agent, and/or hostname should be making changes in your environment. Suppression Rules created by unfamiliar users
+    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Alert Suppression Rule 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 Azure Alert Suppression Rule Created or Modified
+
+Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific suppression rule that was created or modified by filtering logs with the operation name "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and ensuring the event outcome is "success".
+- Determine the identity of the user or service principal that performed the operation by examining the associated user or service account details in the activity logs.
+- Investigate the context and justification for the creation or modification of the suppression rule by checking any related change management records or communications.
+- Assess the impact of the suppression rule on security visibility by identifying which alerts are being suppressed and evaluating whether these alerts are critical for detecting potential threats.
+- Cross-reference the suppression rule changes with recent security incidents or alerts to determine if there is any correlation or if the rule could have been used to hide malicious activity.
+- Verify the legitimacy of the suppression rule by consulting with relevant stakeholders, such as security operations or cloud management teams, to confirm if the change was authorized and aligns with security policies.
+
+### False positive analysis
+
+- Routine maintenance activities by IT staff may trigger alerts when legitimate suppression rules are created or modified. To manage this, establish a baseline of expected changes and create exceptions for known maintenance periods or personnel.
+- Automated processes or scripts that regularly update suppression rules for operational efficiency can generate false positives. Identify these processes and exclude their activity from alerting by using specific identifiers or tags associated with the automation.
+- Changes made by trusted third-party security services that integrate with Azure might be flagged. Verify the legitimacy of these services and whitelist their operations to prevent unnecessary alerts.
+- Frequent updates to suppression rules due to evolving security policies can lead to false positives. Document these policy changes and adjust the alerting criteria to accommodate expected modifications.
+- Temporary suppression rules created during incident response to manage alert noise can be mistaken for malicious activity. Ensure these rules are documented and time-bound, and exclude them from alerting during the response period.
+
+### Response and remediation
+
+- Immediately review the Azure activity logs to confirm the creation or modification of the suppression rule and identify the user or service account responsible for the change.
+- Temporarily disable the suspicious suppression rule to restore visibility into potential security alerts that may have been suppressed.
+- Conduct a thorough investigation of recent alerts that were suppressed by the rule to determine if any malicious activities were overlooked.
+- If malicious activity is confirmed, initiate incident response procedures to contain and remediate the threat, including isolating affected resources and accounts.
+- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture.
+- Implement additional monitoring and alerting for changes to suppression rules to ensure any future modifications are promptly detected and reviewed.
+- Review and update access controls and permissions for creating or modifying suppression rules to ensure only authorized personnel can make such changes.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations",
+    "https://docs.microsoft.com/en-us/rest/api/securitycenter/alerts-suppression-rules/update",
+]
+risk_score = 21
+rule_id = "f0bc081a-2346-4744-a6a4-81514817e888"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and
+event.outcome: "success"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/discovery_blob_container_access_mod.toml

@@ -0,0 +1,112 @@
+[metadata]
+creation_date = "2020/08/20"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies changes to container access levels in Azure. Anonymous public read access to containers and blobs in Azure is
+a way to share data broadly, but can present a security risk if access to sensitive data is not managed judiciously.
+"""
+false_positives = [
+    """
+    Access level modifications may be done by a system or network administrator. Verify whether the username, hostname,
+    and/or resource name should be making changes in your environment. Access level modifications from unfamiliar users
+    or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Blob Container Access Level 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 Azure Blob Container Access Level Modification
+
+Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific storage account and container where the access level modification occurred, using the operation name "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE".
+- Verify the identity of the user or service principal that performed the modification by examining the associated user information in the activity logs.
+- Check the timestamp of the modification to determine if it aligns with any known maintenance windows or authorized changes.
+- Investigate the previous access level settings of the container to assess the potential impact of the change, especially if it involved enabling anonymous public read access.
+- Correlate the event with any other recent suspicious activities or alerts in the Azure environment to identify potential patterns or coordinated actions.
+- Contact the owner of the storage account or relevant stakeholders to confirm whether the change was authorized and aligns with organizational policies.
+
+### False positive analysis
+
+- Routine administrative changes to container access levels by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that regularly perform these tasks.
+- Automated scripts or tools used for managing storage configurations may cause false positives. Identify and exclude these scripts or tools from monitoring if they are verified as non-threatening.
+- Scheduled updates or maintenance activities that involve access level modifications can be mistaken for unauthorized changes. Document and schedule these activities to align with monitoring rules, allowing for temporary exclusions during these periods.
+- Changes made by trusted third-party services integrated with Azure Blob Storage might be flagged. Verify these services and exclude their operations from triggering alerts if they are deemed secure and necessary for business operations.
+
+### Response and remediation
+
+- Immediately revoke public read access to the affected Azure Blob container to prevent unauthorized data exposure.
+- Review the access logs to identify any unauthorized access or data exfiltration attempts during the period when the access level was modified.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access level change and any potential data exposure.
+- Conduct a thorough audit of all Azure Blob containers to ensure that access levels are configured according to the organization's security policies and that no other containers are misconfigured.
+- Implement additional monitoring and alerting for changes to access levels on Azure Blob containers to ensure rapid detection of any future unauthorized modifications.
+- If sensitive data was exposed, initiate a data breach response plan, including notifying affected parties and regulatory bodies as required by law.
+- Review and update access management policies and procedures to prevent recurrence, ensuring that only authorized personnel can modify container access levels.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent"]
+risk_score = 21
+rule_id = "2636aa6c-88b5-4337-9c31-8d0192a8ef45"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Discovery", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1619"
+name = "Cloud Storage Object Discovery"
+reference = "https://attack.mitre.org/techniques/T1619/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+[[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.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1537"
+name = "Transfer Data to Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1537/"
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+

nldcsc_elastic_rules/rules/integrations/azure/discovery_bloodhound_user_agents_detected.toml

@@ -0,0 +1,171 @@
+[metadata]
+creation_date = "2025/06/03"
+integration = ["azure", "o365"]
+maturity = "production"
+updated_date = "2025/06/03"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services.
+These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access
+relationships within Microsoft Entra ID (Azure AD) and Microsoft 365.
+"""
+false_positives = [
+    """
+    Legitimate administrative or security assessment activities may use these user-agents, especially in environments
+    where BloodHound is employed for authorized audits. If this is expected behavior, consider adjusting the rule or
+    adding exceptions for specific user-agents or IP addresses.
+    """,
+    """
+    Expected red team assessments or penetration tests may utilize BloodHound tools to evaluate the security posture of
+    Azure or Microsoft 365 environments. If this is expected behavior, consider adjusting the rule or adding exceptions
+    for specific IP addresses, registered applications, JWT tokens, PRTs or user principal names (UPNs).
+    """,
+]
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.*", "logs-o365.audit-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "BloodHound Suite User-Agents Detected"
+note = """## Triage and analysis
+
+This rule identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365.
+
+The detection is based on known enumeration patterns, particularly the presence of suspicious user agent strings (e.g., `azurehound/`, `sharphound/`, `bloodhound/`) in various Azure and M365 logs. The rule monitors multiple log sources, including:
+
+- Azure Graph API Activity Logs
+- Microsoft 365 Audit Logs
+- Entra ID Sign-in Logs
+- Entra ID Audit Logs
+- Azure Activity Logs
+
+This ensures broader detection of credential abuse, token misuse, or unauthorized identity discovery activity from both interactive and non-interactive (API) sessions.
+
+### Possible investigation steps
+
+- Confirm the tool used via `user_agent.original`. Look for:
+    - `azurehound/x.y.z`
+    - `bloodhound/1.0`
+    - `sharphound/1.0`
+- Examine `url.original` or `url.path` to determine which APIs were accessed if Graph API activity logs. For example:
+    - `/v1.0/organization`, `/v1.0/users`, `/v1.0/groups` may indicate user/group/tenant discovery.
+- Identify the `user.id`, `user.name`, or `azure.auditlogs.properties.initiated_by.user.user_principal_name` fields to determine which identity executed the API request.
+- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app).
+- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs.
+- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious?
+- Review `source.ip`, `client.geo.*`, and `network.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs.
+- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit.
+
+### False positive analysis
+
+- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization.
+- Automated monitoring solutions, cloud posture scanners, or legitimate Azure/M365 integrations may generate similar traffic. Review the `app_id` and user context.
+- Developer activity in test tenants may include tool usage for learning or validation purposes.
+
+### Response and remediation
+
+- If confirmed malicious:
+    - Revoke active sessions or tokens associated with the identified user/app.
+    - Disable the account or rotate credentials immediately.
+    - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges.
+    - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried.
+    - Enable Conditional Access policies to require MFA for API and CLI-based access.
+    - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads.
+
+- If legitimate:
+    - Document the source (e.g., red team operation, security tool).
+    - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows.
+
+"""
+references = [
+    "https://specterops.io/bloodhound-overview/",
+    "https://github.com/SpecterOps/AzureHound",
+    "https://www.microsoft.com/en-us/security/blog/2025/05/27/new-russia-affiliated-actor-void-blizzard-targets-critical-sectors-for-espionage/",
+]
+risk_score = 47
+rule_id = "c28750fa-4092-11f0-aca6-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Data Source: Graph API",
+    "Data Source: Graph API Activity Logs",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Data Source: Microsoft Entra ID",
+    "Data Source: Microsoft Entra ID Audit Logs",
+    "Data Source: Microsoft Entra ID Sign-in Logs",
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+any where event.dataset : (
+    "azure.activitylogs",
+    "azure.graphactivitylogs",
+    "azure.auditlogs",
+    "azure.signinlogs",
+    "o365.audit"
+) and user_agent.original regex~ "(azure|sharp|blood)(hound)/.*"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1069"
+name = "Permission Groups Discovery"
+reference = "https://attack.mitre.org/techniques/T1069/"
+[[rule.threat.technique.subtechnique]]
+id = "T1069.003"
+name = "Cloud Groups"
+reference = "https://attack.mitre.org/techniques/T1069/003/"
+
+
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+[[rule.threat.technique]]
+id = "T1087"
+name = "Account Discovery"
+reference = "https://attack.mitre.org/techniques/T1087/"
+[[rule.threat.technique.subtechnique]]
+id = "T1087.004"
+name = "Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1087/004/"
+
+
+[[rule.threat.technique]]
+id = "T1201"
+name = "Password Policy Discovery"
+reference = "https://attack.mitre.org/techniques/T1201/"
+
+[[rule.threat.technique]]
+id = "T1526"
+name = "Cloud Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1526/"
+
+[[rule.threat.technique]]
+id = "T1580"
+name = "Cloud Infrastructure Discovery"
+reference = "https://attack.mitre.org/techniques/T1580/"
+
+[[rule.threat.technique]]
+id = "T1673"
+name = "Virtual Machine Discovery"
+reference = "https://attack.mitre.org/techniques/T1673/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/integrations/azure/discovery_teamfiltration_user_agents_detected.toml

@@ -0,0 +1,173 @@
+[metadata]
+creation_date = "2025/07/02"
+integration = ["azure", "o365"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an
+open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries
+are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password
+spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by
+monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs.
+"""
+false_positives = [
+    """
+    Legitimate administrative or security assessment activities may use these user-agents, especially in environments
+    where TeamFiltration is employed for authorized audits. If this is expected behavior, consider adjusting the rule or
+    adding exceptions for specific user-agents or IP addresses.
+    """,
+    """
+    Expected red team assessments or penetration tests may utilize TeamFiltration to evaluate the security posture of
+    Azure or Microsoft 365 environments. If this is expected behavior, consider adjusting the rule or adding exceptions
+    for specific IP addresses, registered applications, JWT tokens, PRTs or user
+    """,
+]
+from = "now-9m"
+index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-o365.audit-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "TeamFiltration User-Agents Detected"
+note = """## Triage and analysis
+
+Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs.
+
+The detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including:
+
+- Azure Graph API Activity Logs
+- Microsoft 365 Audit Logs
+- Entra ID Sign-in Logs
+- Entra ID Audit Logs
+- Azure Activity Logs
+
+### Possible investigation steps
+
+- Confirm the tool used via `user_agent.original`.
+- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts.
+- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration.
+- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs.
+- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious?
+- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway.
+- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit.
+
+### False positive analysis
+
+- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization.
+
+### Response and remediation
+
+- If confirmed malicious:
+    - Identify successful sign-in attempts or API calls made by the user or app.
+    - Revoke active sessions or tokens associated with the identified user/app.
+    - Disable the account or rotate credentials immediately.
+    - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges.
+    - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried.
+    - Enable Conditional Access policies to require MFA for API and CLI-based access.
+    - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads.
+
+- If legitimate:
+    - Document the source or user (e.g., red team operation, security tool).
+    - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows.
+
+"""
+references = [
+    "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
+    "https://github.com/Flangvik/TeamFiltration",
+]
+risk_score = 47
+rule_id = "f541ca3a-5752-11f0-b44b-f661ea17fbcd"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Microsoft 365",
+    "Data Source: Microsoft 365 Audit Logs",
+    "Data Source: Microsoft Entra ID",
+    "Data Source: Microsoft Entra ID Sign-in Logs",
+    "Use Case: Identity and Access Audit",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:("azure.signinlogs" or "o365.audit")
+    and ((user_agent.name:"Electron" and user_agent.os.name:"Windows" and user_agent.version:"8.5.1") or
+    user_agent.original:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1069"
+name = "Permission Groups Discovery"
+reference = "https://attack.mitre.org/techniques/T1069/"
+[[rule.threat.technique.subtechnique]]
+id = "T1069.003"
+name = "Cloud Groups"
+reference = "https://attack.mitre.org/techniques/T1069/003/"
+
+
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+[[rule.threat.technique]]
+id = "T1087"
+name = "Account Discovery"
+reference = "https://attack.mitre.org/techniques/T1087/"
+[[rule.threat.technique.subtechnique]]
+id = "T1087.004"
+name = "Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1087/004/"
+
+
+[[rule.threat.technique]]
+id = "T1201"
+name = "Password Policy Discovery"
+reference = "https://attack.mitre.org/techniques/T1201/"
+
+[[rule.threat.technique]]
+id = "T1526"
+name = "Cloud Service Discovery"
+reference = "https://attack.mitre.org/techniques/T1526/"
+
+[[rule.threat.technique]]
+id = "T1580"
+name = "Cloud Infrastructure Discovery"
+reference = "https://attack.mitre.org/techniques/T1580/"
+
+[[rule.threat.technique]]
+id = "T1673"
+name = "Virtual Machine Discovery"
+reference = "https://attack.mitre.org/techniques/T1673/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/integrations/azure/execution_azure_automation_runbook_created_or_modified.toml

@@ -0,0 +1,92 @@
+[metadata]
+creation_date = "2020/08/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an Azure Automation runbook is created or modified. An adversary may create or modify an Azure
+Automation runbook to execute malicious code and maintain persistence in their target's environment.
+"""
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Automation Runbook 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 Azure Automation Runbook Created or Modified
+
+Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code and maintain persistence. The detection rule monitors specific Azure activity logs for runbook creation or modification events, flagging successful operations to identify potential misuse. This helps in early detection of malicious activities, ensuring cloud security.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the specific runbook that was created or modified, focusing on the operation names: "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION".
+- Check the event.outcome field to confirm the operation was successful, as indicated by the values "Success" or "success".
+- Identify the user or service principal that performed the operation by examining the relevant user identity fields in the activity logs.
+- Investigate the content and purpose of the runbook by reviewing its script or configuration to determine if it contains any unauthorized or suspicious code.
+- Correlate the runbook activity with other security events or alerts in the environment to identify any patterns or related malicious activities.
+- Verify if the runbook changes align with recent legitimate administrative activities or if they were unexpected, which could indicate potential misuse.
+
+### False positive analysis
+
+- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
+- Automated deployment processes that include runbook creation or modification might be flagged. Identify and exclude these processes by tagging them with specific identifiers in the logs.
+- Integration with third-party tools that modify runbooks as part of their normal operation can result in false positives. Work with your IT team to whitelist these tools or their associated accounts.
+- Frequent testing or development activities in non-production environments may cause alerts. Consider setting up separate monitoring rules or thresholds for these environments to reduce noise.
+- Scheduled runbook updates for compliance or policy changes can be mistaken for suspicious activity. Document these schedules and adjust the detection rule to account for them, possibly by excluding specific operation names during these times.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions. This can be done by disabling the account or restricting its permissions temporarily.
+- Review the modified or newly created runbooks to identify any malicious code or unauthorized changes. Remove or revert any suspicious modifications to ensure the integrity of the automation scripts.
+- Conduct a thorough audit of recent activities associated with the affected Azure Automation account, focusing on identifying any unauthorized access or changes made by adversaries.
+- Reset credentials and update access controls for the affected Azure Automation account to prevent further unauthorized access. Ensure that only authorized personnel have the necessary permissions to create or modify runbooks.
+- Implement additional monitoring and alerting for Azure Automation activities, specifically focusing on runbook creation and modification events, to enhance early detection of similar threats in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised.
+- Document the incident, including all actions taken and findings, to improve response strategies and update incident response plans for future reference.
+
+## Setup
+
+The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor",
+    "https://github.com/hausec/PowerZure",
+    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
+    "https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/",
+]
+risk_score = 21
+rule_id = "16280f1e-57e6-4242-aa21-bb4d16f13b2f"
+severity = "low"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Execution", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and
+  azure.activitylogs.operation_name:
+  (
+    "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE" or
+    "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE" or
+    "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION"
+  ) and
+  event.outcome:(Success or success)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1648"
+name = "Serverless Execution"
+reference = "https://attack.mitre.org/techniques/T1648/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+