Elastic rules: 01

[rule]
description = """
Identifies attempts to queue an Asynchronous Procedure Call (APC) to a remote process. This may indicate a remote code
injection attack.
"""
id = "300195cb-5d38-4375-ab59-0110c8a486d9"
license = "Elastic License v2"
name = "Asynchronous Procedure Call from Unusual Module"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/doubling-down-etw-callstacks",
    "https://www.ired.team/offensive-security/code-injection-process-injection/apc-queue-code-injection",
]
version = "1.0.4"

query = '''
api where process.pid != 4 and process.Ext.api.name in ("NtQueueApcThread", "QueueUserAPC") and
 process.Ext.api.behaviors == "cross-process" and
 process.thread.Ext.call_stack_final_user_module.name != null and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != null and
 not process.thread.Ext.call_stack_final_user_module.name in ("Undetermined", "Kernel", "Unknown") and
 (
  _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == false or $entry.exists == false) or
  _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.subject_name in ("AutoIt Consulting Ltd", "Python Software Foundation")) or
  (process.thread.Ext.call_stack_final_user_module.name == "Unbacked" and
   (process.thread.Ext.call_stack_final_user_module.protection_provenance_path like "c:\\windows\\microsoft.net\\framework*\\clr.dll" or process.thread.Ext.call_stack_final_user_module.protection_provenance == "clr.dll"))
 ) and
 process.Ext.api.summary != "NtQueueApcThread( csrss.exe, basesrv.dll!BaseSrvNlsUpdateRegistryCache, NULL, Data, Data )" and
 not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == true and
                  $entry.subject_name in ("Microsoft Windows Hardware Compatibility Publisher",
                                          "Microsoft Windows Software Compatibility Publisher",
                                          "Mozilla Corporation", "Beijing Qihu Technology Co., Ltd.",
                                          "Symantec Corporation", "Deep Instinct Ltd",
                                          "TPZ SOLUCOES DIGITAIS LTDA",
                                          "Carbon Black, Inc.", 
                                          "MUSARUBRA US LLC")) and
 not _arraysearch(process.thread.Ext.call_stack, $entry,
                  $entry.symbol_info like ("c:\\windows\\sys?????\\ntdll.dll!NtCreateUserProcess+*",
                                           "c:\\windows\\sys?????\\ntdll.dll!ZwCreateUserProcess*")) and
 not (process.thread.Ext.call_stack_final_user_module.hash.sha256 == "d7d35019ce0c03d97c32ab25a145371806ca2d1572af1e5146ea886d41818850" and
      Target.process.executable : "?:\\Windows\\SysWOW64\\rserver30\\FamItrfc.Exe")
'''

min_endpoint_version = "8.14.2"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0
tree = true

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"
[[threat.technique.subtechnique]]
id = "T1055.004"
name = "Asynchronous Procedure Call"
reference = "https://attack.mitre.org/techniques/T1055/004/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "8.14.2"

[rule]
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.
"""
id = "bf76a9f8-42dd-44cc-9e2f-d8693df31d59"
license = "Elastic License v2"
name = "Attempt to Disable Auditd Service"
os_list = ["linux"]
version = "1.0.1"

query = '''
process where event.type == "start" and event.action == "exec" and (
  (process.name == "service" and process.args == "stop") or
  (process.name == "chkconfig" and process.args == "off") or
  (process.name == "update-rc.d" and process.args in ("remove", "disable")) or
  (process.name == "systemctl" and process.args in ("disable", "stop", "kill", "mask"))
) and
process.args in ("auditd", "auditd.service") and
not (
  process.parent.executable like (
    "/var/lib/dpkg/info/auditd.prerm", "/usr/libexec/platform-python*"
  ) or
  (process.name == "systemctl" and process.parent.args == "/usr/lib/systemd/systemd-update-helper") or
  process.parent.args like (
    "/home/*/.ansible/tmp/ansible-tmp-*/AnsiballZ_*.py", "/var/lib/dpkg/info/auditd.prerm", "/var/tmp/rpm-tmp*"
  ) or
  process.parent.executable == "/opt/kaspersky/kesl/libexec/kesl" or
  process.parent.command_line like "*logrotate_script*"
)
'''

min_endpoint_version = "7.15.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2024/04/20"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to
assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who
have established persistence through a rogue trust anchor may create or modify profiles to link them with highly
privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful
"CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations.
"""
false_positives = [
    """
    AWS Roles Anywhere profiles are legitimate profiles that can be created by administrators to allow access from any
    location. Ensure that the profile created is expected and that the trust policy is configured securely.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Roles Anywhere Profile Creation"
note = """## Triage and analysis

### Investigating AWS IAM Roles Anywhere Profile Creation

AWS IAM Roles Anywhere allows external workloads — such as CI/CD runners, on-premises systems, or third-party services — 
to assume IAM roles securely by presenting a certificate from a trusted anchor. A profile defines the IAM roles that 
can be assumed, the trust anchor they are associated with, and session duration limits.

This rule detects when a new Roles Anywhere profile is created using the `CreateProfile` API call. Unauthorized profile 
creation can enable persistent external access if tied to over-privileged roles or to trust anchors associated with 
unauthorized certificate authorities (CAs). Monitoring profile creation is crucial to ensuring that only approved roles 
and anchors are in use.

#### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine 
    which IAM user, role, or principal created the profile.
  - Check whether this identity normally manages Roles Anywhere configurations.

- **Review profile configuration**
  - Inspect `aws.cloudtrail.request_parameters` for key values such as:
    - `profileName`
    - `roleArns` – confirm that the listed IAM roles are expected and not overly permissive.
    - `trustAnchorArn` – verify the trust anchor is valid and authorized.
    - `durationSeconds` – check for unusually long session durations.
  - Determine if multiple roles were attached, which may indicate excessive privilege aggregation.

- **Correlate related activity**
  - Check for prior or concurrent events by the same actor, including:
    - `CreateTrustAnchor` with external or unauthorized certificate authorities.
    - `CreateRole`, `PutRolePolicy`, or `AttachRolePolicy` for privilege escalation paths.
  - Review whether subsequent `AssumeRoleWithCertificate` events occurred, indicating use of the new profile.

- **Assess the source context**
  - Investigate `source.ip`, `user_agent.original`, and `source.geo` fields to identify if this request originated from an unfamiliar host, region, or automation client (e.g., `boto3`, `curl`, custom SDKs).
  - Compare to baseline patterns of legitimate IAM or infrastructure automation.

- **Validate legitimacy**
  - Contact the responsible team (e.g., platform, PKI, or IAM administration) to confirm whether this profile creation 
    aligns with approved change management or onboarding activities.


### False positive analysis:

- **Legitimate administrative actions**
  - IAM or PKI engineers may legitimately create profiles during setup of new external integrations or workloads. 
    Validate against change control records and deployment logs.
- **Authorized automation**
  - Infrastructure-as-code (IaC) pipelines (Terraform, CloudFormation, etc.) may automatically create profiles. 
    Confirm these operations are sourced from known automation accounts or IP ranges.
- **Development and testing**
  - Lab or sandbox accounts may test Roles Anywhere configurations with less restrictive controls. 
    Ensure alerts from non-production accounts are tuned accordingly.

### Response and remediation:

- **Immediate review and containment**
  - If unauthorized, disable or delete the created profile (`aws rolesanywhere delete-profile`) and review all 
    associated IAM roles for misuse.
  - Rotate any credentials or revoke certificates issued from unapproved trust anchors.

- **Investigation**
  - Search CloudTrail for additional related actions by the same identity, such as 
    `CreateTrustAnchor`, `AssumeRoleWithCertificate`, or cross-account access attempts.
  - Verify whether any sessions have been initiated using the new profile and identify 
    which roles were assumed.

- **Recovery and hardening**
  - Restrict `rolesanywhere:CreateProfile` to a small set of administrative roles.
  - Implement AWS Config or Security Hub controls to alert on unauthorized or overly 
    permissive Roles Anywhere profiles.
  - Audit IAM role trust policies linked to external anchors and ensure adherence to the 
    principle of least privilege.
  - Review and document all approved Roles Anywhere profiles and their corresponding trust anchors.

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = [
    "https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html",
    "https://docs.datadoghq.com/security/default_rules/cloudtrail-aws-iam-roles-anywhere-trust-anchor-created/",
    "https://ermetic.com/blog/aws/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/",
    "https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html",
]
risk_score = 73
rule_id = "1d4ca9c0-ff1e-11ee-91cc-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: aws.cloudtrail
    and event.provider: rolesanywhere.amazonaws.com
    and event.action: CreateProfile
    and event.outcome: success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
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.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
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.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

[rule]
description = """
This rule detects the discovery of the GitHub Actions Runner process PID using the pgrep command. Adversaries may use
this technique to identify the PID of the GitHub Actions Runner process, which can be used to execute commands on the
runner host. This behavior may indicate malicious or unexpected workflow activity, including code execution, file
manipulation, or network exfiltration initiated through a compromised repository or unauthorized workflow.
"""
id = "d908caa5-2d4c-4ba7-9ce8-5f1ff4315397"
license = "Elastic License v2"
name = "Discovery of GitHub Actions Runner Process PID"
os_list = ["linux", "macos"]
reference = [
    "https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise",
    "https://www.stepsecurity.io/blog/trivy-compromised-a-second-time---malicious-v0-69-4-release",
    "https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/",
]
version = "1.0.2"

query = '''
sequence by process.parent.entity_id with maxspan=3s
  [process where event.type == "start" and event.action == "exec" and process.name == "pgrep" and
  process.args in ("Runner.Listener", "Runner.Worker", "Runner.PluginHost", "run.sh", "svc.sh", "runsvc.sh")] as event0
  [process where event.type == "start" and event.action == "exec" and process.name == "pgrep" and
  not startswith~(process.command_line, event0.process.command_line) and
  process.args in ("Runner.Listener", "Runner.Worker", "Runner.PluginHost", "run.sh", "svc.sh", "runsvc.sh")]
'''

min_endpoint_version = "8.4.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 1

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"
[[threat.technique.subtechnique]]
id = "T1195.001"
name = "Compromise Software Dependencies and Development Tools"
reference = "https://attack.mitre.org/techniques/T1195/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"


[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1057"
name = "Process Discovery"
reference = "https://attack.mitre.org/techniques/T1057/"


[threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"

[internal]
min_endpoint_version = "8.4.0"

[metadata]
creation_date = "2026/08/07"
integration = ["azure"]
maturity = "production"
min_stack_comments = "FIELD_EXTRACT for flattened fields requires 9.5.0"
min_stack_version = "9.5.0"
updated_date = "2026/08/07"

[rule]
author = ["Elastic"]
description = """
Identifies a Microsoft Entra ID device registration by the same user within 15 minutes of a phishing-resistant,
device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) signing in with no device
identifier. In the "borrowing Windows Hello keys" technique, an adversary reuses a WHfB/NGC key or passkey away from its
bound device to mint device-agnostic tokens, then uses those tokens to register an attacker-controlled device and obtain
a Primary Refresh Token (PRT) for long-lived persistence. Timing is taken from the authentication step on the sign-in,
not the sign-in document timestamp, because Entra can emit the sign-in record after the Register device audit event.
This chain is distinct from device-code-flow phishing kits.
"""
false_positives = [
    """
    A user completing initial passwordless enrollment and registering their first device in the same session can match.
    Validate against expected onboarding and the device's provenance (managed/compliant, expected name, expected
    source).
    """,
    """
    Authorized red team or research engagements that borrow a WHfB/passkey and register a device will match. Document
    the engagement and add scoped exceptions for the involved principals or source addresses.
    """,
]
from = "now-30m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID Deviceless Windows Hello Sign-in Followed by Device Registration"
note = """## Triage and analysis

### Investigating Entra ID Deviceless Windows Hello Sign-in Followed by Device Registration

This rule correlates, within 15 minutes for the same user: (1) a successful member sign-in satisfied by a device-bound credential (WHfB, FIDO2, or passkey) with an empty `device_detail.device_id`, and (2) a successful device registration (`Register device`, `Add registered owner to device`, or `Add device`). The alert is the sign-in document enriched with the matching registration. `Esql.signin_time` is the authentication step time from flattened `authentication_details` (falling back to `@timestamp`); use it and `Esql.signin_to_register_s` for sequencing, since Entra can write the sign-in record after the `Register device` audit event, making `@timestamp` unreliable for ordering.

This is the escalation step of the "borrowing Windows Hello keys" technique: an adversary mints a device-agnostic token from a deviceless WHfB/passkey assertion, then immediately registers an attacker-controlled device to obtain a Primary Refresh Token that survives `revokeSignInSessions` and password resets.

### Possible investigation steps

- Identify the user (`user_principal_name` / `Esql.actor_user_id`) and confirm `Esql.auth_method` is WHfB/FIDO2/passkey with an empty `device_detail.device_id` and `cross_tenant_access_type` of `none` - a device-bound method presenting without its device is the first-stage signal.
- Compare `Esql.signin_time` to `Esql.register_time` via `Esql.signin_to_register_s`; a gap of seconds to minutes is the expected attacker cadence. `Esql.registered_device_name`/`Esql.register_operation` for tooling-registered devices are often generic (`DESKTOP-*`) and absent from inventory/unmanaged.
- Check `app_display_name`/`resource_display_name` for non-interactive clients (Azure CLI, ROADtools/roadtx) against Graph or the Device Registration Service, `source.address`/`source.geo.country_name`/`user_agent.original` for hosting/VPS or automation, and pivot on `Esql.actor_user_id` for a follow-on `primaryRefreshToken` `incoming_token_type` from the new device or an `Add Windows Hello for Business credential` event (backdoor enrollment).

### False positive analysis

- Initial passwordless onboarding can produce a sign-in and first device registration in the same session; validate the device against inventory and confirm it is managed/compliant and named as expected.
- Authorized security assessments that replay a key and register a device will also match; document the engagement and add scoped exceptions.

### Response and remediation

- Remove the rogue device BEFORE revoking sessions (`GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices) - a device-bound PRT survives `revokeSignInSessions`, and a device left in place re-establishes access.
- Treat the key/passkey as compromised: delete the affected authentication methods, revoke refresh tokens and sessions (`POST /v1.0/users/{id}/revokeSignInSessions`), reset credentials, and re-enroll from a trusted device.
- Hunt for additional persistence in the same window (attacker-registered MFA methods, extra device registrations, PRT use from the new device), and restrict device registration/join via Conditional Access requiring a compliant device.
"""
references = [
    "https://dirkjanm.io/borrowing-windows-hello-keys/",
    "https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/",
]
risk_score = 73
rule_id = "62848597-595c-4cc3-8d24-6c47a5fee9a9"
setup = """#### Required Microsoft Entra ID Sign-In and Audit Logs
This rule requires the Azure integration with Microsoft Entra ID Sign-In logs and Audit logs enabled and collected via Azure Event Hub. Both data streams are required: the sign-in supplies the deviceless WHfB/passkey assertion, and the audit log supplies the follow-on device registration.
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Platform: Entra ID",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Rule Type: ESQL",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-azure.signinlogs-*, logs-azure.auditlogs-* METADATA _id, _version, _index
| WHERE
    (
      azure.signinlogs.result_signature == "SUCCESS" AND
      azure.signinlogs.properties.user_type == "Member" AND
      azure.signinlogs.properties.user_id IS NOT NULL AND
      azure.signinlogs.properties.cross_tenant_access_type == "none" AND
      (
        azure.signinlogs.properties.device_detail.device_id IS NULL OR
        azure.signinlogs.properties.device_detail.device_id == ""
      )
    ) OR
    (
      azure.auditlogs.operation_name IN ("Register device", "Add registered owner to device", "Add device") AND
      event.outcome == "success" AND
      azure.auditlogs.properties.initiated_by.user.id IS NOT NULL
    )
| EVAL
    Esql.sequence_stage = CASE(data_stream.dataset == "azure.signinlogs", "signin", "register"),
    Esql.actor_user_id = COALESCE(azure.signinlogs.properties.user_id, azure.auditlogs.properties.initiated_by.user.id),
    Esql.auth_method = FIELD_EXTRACT(azure.signinlogs.properties.authentication_details, "authentication_method"),
    Esql.auth_step_time = MV_MIN(TO_DATETIME(FIELD_EXTRACT(azure.signinlogs.properties.authentication_details, "authentication_step_date_time"))),
    Esql.register_candidate = CASE(
      data_stream.dataset == "azure.auditlogs",
      CONCAT(
        TO_STRING(@timestamp),
        "|",
        COALESCE(`azure.auditlogs.properties.target_resources.0.display_name`, ""),
        "|",
        azure.auditlogs.operation_name
      ),
      null
    )
| EVAL Esql.signin_time = COALESCE(Esql.auth_step_time, @timestamp)
| WHERE
    Esql.sequence_stage == "register" OR
    (
      MV_COUNT(Esql.auth_method) == 1 AND
      (
        Esql.auth_method == "Windows Hello for Business" OR
        TO_LOWER(Esql.auth_method) LIKE "fido2*" OR
        TO_LOWER(Esql.auth_method) LIKE "*passkey*"
      )
    )
| KEEP
    @timestamp,
    Esql.signin_time,
    Esql.actor_user_id,
    Esql.sequence_stage,
    Esql.auth_method,
    Esql.register_candidate,
    azure.signinlogs.properties.user_id,
    azure.signinlogs.properties.user_principal_name,
    azure.signinlogs.properties.device_detail.device_id,
    azure.signinlogs.properties.device_detail.is_managed,
    azure.signinlogs.properties.cross_tenant_access_type,
    azure.signinlogs.properties.app_id,
    azure.signinlogs.properties.app_display_name,
    azure.signinlogs.properties.resource_display_name,
    azure.signinlogs.properties.incoming_token_type,
    source.address,
    source.geo.country_name,
    user_agent.original,
    _id,
    _version,
    _index
| WHERE Esql.actor_user_id IS NOT NULL
| INLINE STATS
    Esql.register_count = COUNT(*) WHERE Esql.sequence_stage == "register",
    Esql.register_candidates = VALUES(Esql.register_candidate) WHERE Esql.sequence_stage == "register"
  BY Esql.actor_user_id
| DROP Esql.register_candidate
| WHERE Esql.sequence_stage == "signin" AND Esql.register_count > 0
| MV_EXPAND Esql.register_candidates
| EVAL
    Esql.register_time = TO_DATETIME(MV_FIRST(SPLIT(Esql.register_candidates, "|"))),
    Esql.registered_device_name = MV_SLICE(SPLIT(Esql.register_candidates, "|"), 1, 1),
    Esql.register_operation = MV_LAST(SPLIT(Esql.register_candidates, "|")),
    Esql.signin_to_register_s = DATE_DIFF("second", Esql.signin_time, Esql.register_time)
| DROP Esql.register_candidates, Esql.sequence_stage, Esql.register_count
| WHERE
    Esql.signin_to_register_s >= 0 AND
    Esql.signin_to_register_s <= 900
| SORT Esql.register_time ASC, Esql.signin_to_register_s ASC, _id ASC
| LIMIT 1 BY Esql.actor_user_id
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"


[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2020/11/19"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies execution of suspicious persistent programs (scripts, rundll32, etc.) by looking at process lineage and
command line usage.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-endpoint.events.process-*", "logs-windows.sysmon_operational-*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "Execution of Persistent Suspicious Program"
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 Execution of Persistent Suspicious Program

Persistent programs, like scripts or rundll32, are often used by adversaries to maintain access to a system. These programs can be executed at startup, leveraging process lineage and command line arguments to evade detection. The detection rule identifies suspicious executions by monitoring the sequence of processes initiated after user logon, focusing on known malicious executables and unusual file paths, thus highlighting potential abuse of persistence mechanisms.

### Possible investigation steps

- Review the process lineage to confirm the sequence of userinit.exe, explorer.exe, and the suspicious child process. Verify if the child process was indeed launched shortly after user logon.
- Examine the command line arguments of the suspicious process to identify any unusual or malicious patterns, especially those involving known suspicious paths like C:\\Users\\*, C:\\ProgramData\\*, or C:\\Windows\\Temp\\*.
- Check the original file name of the suspicious process against known malicious executables such as cscript.exe, wscript.exe, or PowerShell.EXE to determine if it matches any of these.
- Investigate the parent process explorer.exe to ensure it was not compromised or manipulated to launch the suspicious child process.
- Analyze the user account associated with the suspicious process to determine if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited.
- Review recent system changes or installations that might have introduced the suspicious executable or altered startup configurations.

### False positive analysis

- Legitimate administrative scripts or tools may trigger alerts if they are executed from common directories like C:\\Users or C:\\ProgramData. To manage this, create exceptions for known administrative scripts that are regularly used in your environment.
- Software updates or installations might use processes like PowerShell or RUNDLL32, leading to false positives. Identify and exclude these processes when they are part of a verified update or installation routine.
- Custom scripts or automation tasks that run at startup could be flagged. Document these tasks and exclude them from the rule if they are part of normal operations.
- Security or monitoring tools that use similar execution patterns may be mistakenly identified. Verify these tools and add them to an exclusion list to prevent unnecessary alerts.
- User-initiated actions that mimic suspicious behavior, such as running scripts from the command line, can cause false positives. Educate users on safe practices and adjust the rule to exclude known benign user actions.

### Response and remediation

- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers.
- Terminate any suspicious processes identified in the alert, such as those executed by cscript.exe, wscript.exe, PowerShell.EXE, MSHTA.EXE, RUNDLL32.EXE, REGSVR32.EXE, RegAsm.exe, MSBuild.exe, or InstallUtil.exe.
- Remove any unauthorized or suspicious startup entries or scheduled tasks that may have been created to ensure persistence.
- 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 remnants.
- Review and restore any modified system configurations or registry settings to their default or secure state.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.
- Implement enhanced monitoring and logging for the affected host and similar systems to detect any recurrence or related suspicious activities."""
risk_score = 47
rule_id = "e7125cea-9fe1-42a5-9a05-b0792cf86f5a"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
/* userinit followed by explorer followed by early child process of explorer (unlikely to be launched interactively) within 1m */
sequence by host.id, user.name with maxspan=1m
  [process where host.os.type == "windows" and event.type == "start" and process.name : "userinit.exe" and process.parent.name : "winlogon.exe"]
  [process where host.os.type == "windows" and event.type == "start" and process.name : "explorer.exe"]
  [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "explorer.exe" and
   /* add suspicious programs here */
   process.pe.original_file_name in ("cscript.exe",
                                     "wscript.exe",
                                     "PowerShell.EXE",
                                     "MSHTA.EXE",
                                     "RUNDLL32.EXE",
                                     "REGSVR32.EXE",
                                     "RegAsm.exe",
                                     "MSBuild.exe",
                                     "InstallUtil.exe") and
    /* add potential suspicious paths here */
    process.args : ("C:\\Users\\*", "C:\\ProgramData\\*", "C:\\Windows\\Temp\\*", "C:\\Windows\\Tasks\\*", "C:\\PerfLogs\\*", "C:\\Intel\\*")
   ]
'''

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
"""


[[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.001"
name = "Registry Run Keys / Startup Folder"
reference = "https://attack.mitre.org/techniques/T1547/001/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"

[[rule.threat.technique.subtechnique]]
id = "T1127.001"
name = "MSBuild"
reference = "https://attack.mitre.org/techniques/T1127/001/"

[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"

[[rule.threat.technique.subtechnique]]
id = "T1218.004"
name = "InstallUtil"
reference = "https://attack.mitre.org/techniques/T1218/004/"

[[rule.threat.technique.subtechnique]]
id = "T1218.005"
name = "Mshta"
reference = "https://attack.mitre.org/techniques/T1218/005/"

[[rule.threat.technique.subtechnique]]
id = "T1218.009"
name = "Regsvcs/Regasm"
reference = "https://attack.mitre.org/techniques/T1218/009/"

[[rule.threat.technique.subtechnique]]
id = "T1218.010"
name = "Regsvr32"
reference = "https://attack.mitre.org/techniques/T1218/010/"

[[rule.threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"

[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.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[metadata]
creation_date = "2022/09/13"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace.
Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient
address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection.
"""
false_positives = [
    """
    Administrators may create or change Gmail routing, dual-delivery, address maps, or mail hosts for migrations,
    journaling, spam handling, or partner integrations.
    """,
]
from = "now-20m"
index = ["logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Gmail Routing or Forwarding Rule Created or Modified"
note = """## Triage and analysis

### Investigating Google Workspace Gmail Routing or Forwarding Rule Created or Modified

Gmail administrators can change where mail is delivered using several Admin console areas under Apps > Google Workspace > Gmail:

- Routing — specialized rules (modify message, change route, also deliver to, change envelope recipient). Audit: `UNIFIED_MAIL_ROUTING` or `MESSAGE_SECURITY_RULE` (legacy); `google_workspace.admin.setting.metadata.rule.type` may repeat the legacy type on `RuleState` rows.
- Email forwarding using recipient address map — rewrite or forward by address mapping. Audit: `ALIAS_TABLE`.
- Hosts / Outbound gateway — custom SMTP routes. Audit: `EMAIL_ROUTE`.

Google may emit multiple admin audit events per single save (legacy `CREATE_GMAIL_SETTING`, new `CREATE_APPLICATION_SETTING`, rule body, and rule enabled state). Expect duplicate documents at the same `@timestamp`; correlate on `user.name`, `google_workspace.admin.USER_DEFINED_SETTING_NAME` (rule id), and `event.id`.

### Possible investigation steps

- Identify the administrator (`user.name`, `user.email`) and confirm the change was authorized.
- In Admin console, review the rule matching `google_workspace.admin.USER_DEFINED_SETTING_NAME`:
  - Routing (`UNIFIED_MAIL_ROUTING`, `MESSAGE_SECURITY_RULE`): Apps > Gmail > Routing
  - Recipient address map (`ALIAS_TABLE`): Apps > Gmail > Default routing > Email forwarding using recipient address map
  - Mail hosts / outbound gateway (`EMAIL_ROUTE`): Apps > Gmail > Hosts
- Map the alert to the admin area using `google_workspace.admin.setting.name` and `google_workspace.admin.setting.metadata.rule.type`
- Review whether the rule adds also deliver to, change envelope recipient, or routes to an external mail host or domain.
- Review related `event.action` values for the same administrator in the last 48 hours.
- If licensed for Gmail log events (BigQuery / Enterprise Plus), use Reporting > Audit and investigation > Gmail log events to confirm messages were delivered per the rule (`message_info.flattened_destinations`, `triggered_rule_info`).
- Submit suspicious URLs or attachments from affected mail to reputational services as needed.

### False positive analysis

- Legitimate mail migrations, journaling, compliance archiving, and internal dual-delivery are common.
- Tune with exceptions for known administrator accounts, rule ids (`USER_DEFINED_SETTING_NAME`), or approved external domains.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- 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).

## Setup

The Google Workspace Fleet integration with the Admin data stream (`logs-google_workspace.admin-*`) is required for this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule uses `timestamp_override = event.ingested` and is configured to run every 10 minutes with a lookback of 20 minutes, aligned with the integration's default Admin poll interval (`interval`: 15m) and lag time (`lag_time`: 3m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/docs/reference/integrations/google_workspace"""
references = [
    "https://support.google.com/a/answer/2685650?hl=en",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
  ]
risk_score = 73
rule_id = "9510add4-3392-11ed-bd01-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"google_workspace.admin" and event.action:(
  "CREATE_GMAIL_SETTING" or "CHANGE_GMAIL_SETTING"
  or "CREATE_APPLICATION_SETTING" or "CHANGE_APPLICATION_SETTING"
)
and (
  google_workspace.admin.setting.name:(
    "UNIFIED_MAIL_ROUTING"
    or "ALIAS_TABLE"
    or "EMAIL_ROUTE"
    or "MESSAGE_SECURITY_RULE"
  )
  or google_workspace.admin.setting.metadata.rule.type:(
    "UNIFIED_MAIL_ROUTING"
    or "ALIAS_TABLE"
    or "EMAIL_ROUTE"
  )
)
'''
[rule.investigation_fields]
field_names = [
    "source.ip",
    "user.name",
    "user.email",
    "event.action",
    "google_workspace.admin.org_unit.name",
    "google_workspace.admin.setting.name",
    "google_workspace.admin.setting.metadata.rule.type",
    "google_workspace.admin.USER_DEFINED_SETTING_NAME",
]


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1114"
name = "Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/"
[[rule.threat.technique.subtechnique]]
id = "T1114.003"
name = "Email Forwarding Rule"
reference = "https://attack.mitre.org/techniques/T1114/003/"



[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[metadata]
creation_date = "2023/01/13"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/05/04"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"

[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"

[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""

[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""


[rule]
author = ["Elastic"]
description = """
Identifies downloads of executable and archive files via the Windows Background Intelligent Transfer Service (BITS).
Adversaries could leverage Windows BITS transfer jobs to download remote payloads.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*"]
language = "eql"
license = "Elastic License v2"
name = "Ingress Transfer via Windows BITS"
note = """## Triage and analysis

### Investigating Ingress Transfer via Windows BITS

Windows Background Intelligent Transfer Service (BITS) is a technology that allows the transfer of files between a client and a server, which makes it a dual-use mechanism, being used by both legitimate apps and attackers. When malicious applications create BITS jobs, files are downloaded or uploaded in the context of the service host process, which can bypass security protections, and it helps to obscure which application requested the transfer.

This rule identifies such abuse by monitoring for file renaming events involving "svchost.exe" and "BIT*.tmp" on Windows systems.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.

### Possible investigation steps

- Gain context into the BITS transfer.
  - Try to determine the process that initiated the BITS transfer.
    - Search `bitsadmin.exe` processes and examine their command lines.
    - Look for unusual processes loading `Bitsproxy.dll` and other BITS-related DLLs.
  - Try to determine the origin of the file.
    - Inspect network connections initiated by `svchost.exe`.
    - Inspect `Microsoft-Windows-Bits-Client/Operational` Windows logs, specifically the event ID 59, for unusual events.
      - Velociraptor can be used to extract these entries using the [bitsadmin artifact](https://docs.velociraptor.app/exchange/artifacts/pages/bitsadmin/).
    - Check the reputation of the remote server involved in the BITS transfer, such as its IP address or domain, using threat intelligence platforms or online reputation services.
    - Check if the domain is newly registered or unexpected.
    - Use the identified domain as an indicator of compromise (IoCs) to scope other compromised hosts in the environment.
  - [BitsParser](https://github.com/fireeye/BitsParser) can be used to parse BITS database files to extract BITS job information.
- Examine the details of the dropped file, and whether it was executed.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Analyze the involved executables using a private sandboxed analysis system.
  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
    - Attempts to contact external domains and addresses.
      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process's `process.entity_id`.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3
  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.


### False positive analysis

- Known false positives for the rule include legitimate software and system updates that use BITS for downloading files.

### Related Rules

- Persistence via BITS Job Notify Cmdline - c3b915e0-22f3-4bf7-991d-b643513c722f
- Unsigned BITS Service Client Process - 9a3884d0-282d-45ea-86ce-b9c81100f026
- Bitsadmin Activity - 8eec4df1-4b4b-4502-b6c3-c788714604c9

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Isolate the involved hosts to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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).
"""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend
"""

references = ["https://attack.mitre.org/techniques/T1197/"]
risk_score = 21
rule_id = "f95972d3-c23b-463b-89a8-796b3f369b49"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.action == "rename" and
  process.name : "svchost.exe" and file.Ext.original.name : "BIT*.tmp" and 
  (file.extension : ("exe", "zip", "rar", "bat", "dll", "ps1", "vbs", "vbe", "wsh", "wsf", "sct", "js", "jse", "hta", "pif", "scr", "cmd", "cpl") or
   file.Ext.header_bytes : "4d5a*") and 
 
  /* noisy paths, for hunting purposes you can use the same query without the following exclusions */
  not file.path : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*", "?:\\Windows\\*", "?:\\ProgramData\\*\\*") and 
 
  /* lot of third party SW use BITS to download executables with a long file name */
  not length(file.name) > 30 and
  not file.path : (
        "?:\\Users\\*\\AppData\\Local\\Temp*\\wct*.tmp",
        "?:\\Users\\*\\AppData\\Local\\Adobe\\ARM\\*\\RdrServicesUpdater*.exe",
        "?:\\Users\\*\\AppData\\Local\\Adobe\\ARM\\*\\AcroServicesUpdater*.exe",
        "?:\\Users\\*\\AppData\\Local\\Docker Desktop Installer\\update-*.exe"
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"


[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1197"
name = "BITS Jobs"
reference = "https://attack.mitre.org/techniques/T1197/"


[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2025/03/12"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/19"

[rule]
author = ["Elastic"]
description = """
This rule detects when an interactive shell process is launched via an unusual parent processes inside a container.
Interactive processes are typically run in the foreground and require user input, which is unusual behavior for a
containerized environment. This activity could indicate an attacker attempting to gain access to the container
environment or perform malicious actions.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "kuery"
license = "Elastic License v2"
name = "Interactive Shell Launched via Unusual Parent Process in a Container"
risk_score = 47
rule_id = "7020ff25-76d7-4a7d-b95b-266cf27d70e8"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.

For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:process and host.os.type:linux and event.type:start and event.action:exec and
process.entry_leader.entry_meta.type:container and process.interactive:true and
process.name:(sh or bash or dash or tcsh or csh or zsh or ksh or fish) and
not (
  process.parent.name:(dpkg or runc or tini or frontend or elastic-agent or agentbeat or dpkg-query or ansible-playbook or gpgv or apt or apt-get) or
  process.parent.command_line:"runc init"
)
'''

[[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.new_terms]
field = "new_terms_fields"
value = ["process.parent.name"]

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2020/11/19"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when a safe attachment rule is disabled in Microsoft 365. Safe attachment rules can extend malware
protections to include routing all messages and attachments without a known malware signature to a special hypervisor
environment. An adversary or insider threat may disable a safe attachment rule to exfiltrate data or evade defenses.
"""
false_positives = [
    """
    A safe attachment rule may be disabled by a system or network administrator. Verify that the configuration change
    was expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Exchange Email Safe Attachment Rule Disabled"
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 M365 Exchange Email Safe Attachment Rule Disabled

Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect unknown malware. Disabling this rule can expose organizations to threats by allowing potentially harmful attachments to bypass scrutiny. Adversaries may exploit this to exfiltrate data or avoid detection. The detection rule monitors audit logs for successful attempts to disable this feature, signaling potential defense evasion activities.

### Possible investigation steps

- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to identify the user or account responsible for the action.
- Check the event.outcome field to confirm the success of the rule being disabled and gather additional context from related logs around the same timestamp.
- Investigate the event.provider "Exchange" to determine if there are any other recent suspicious activities or changes made by the same user or account.
- Assess the event.category "web" to understand if there were any web-based interactions or anomalies that coincide with the disabling of the safe attachment rule.
- Evaluate the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
- Cross-reference the identified user or account with known insider threat indicators or previous security incidents to assess the likelihood of malicious intent.

### False positive analysis

- Routine administrative changes can trigger alerts when IT staff disable Safe Attachment rules for legitimate reasons, such as testing or maintenance. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
- Automated scripts or third-party tools used for email management might disable Safe Attachment rules as part of their operations. Identify these tools and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses.
- Changes in organizational policy or security configurations might necessitate temporary disabling of Safe Attachment rules. Document these policy changes and adjust the monitoring rules to account for these temporary exceptions.
- Training or onboarding sessions for new IT staff might involve disabling Safe Attachment rules as part of learning exercises. Ensure these activities are logged and excluded from alerts by setting up temporary exceptions for training periods.

### Response and remediation

- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore the security posture and prevent further exposure to potentially harmful attachments.
- Conduct a thorough review of recent email logs and quarantine any suspicious attachments that were delivered during the period the rule was disabled.
- Isolate any systems or accounts that interacted with suspicious attachments to prevent potential malware spread or data exfiltration.
- Escalate the incident to the security operations team for further investigation and to determine if there was any unauthorized access or data compromise.
- Implement additional monitoring on the affected accounts and systems to detect any signs of ongoing or further malicious activity.
- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules and configurations.
- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing alerting mechanisms for critical security rule changes.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/powershell/module/exchange/disable-safeattachmentrule?view=exchange-ps",
]
risk_score = 21
rule_id = "03024bd9-d23f-4ec1-8674-3cf1a21e130b"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Disable-SafeAttachmentRule" 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.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/"

[metadata]
creation_date = "2024/09/04"
integration = ["o365"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Detects successful Microsoft 365 portal logins from a country and region the user has not previously authenticated
from in a specific time window. Atypical regions are identified by combining the user's country and region geolocation history; an
authentication from a new country/region pair for that user may indicate an adversary attempting to access the
account from an unusual location or behind a VPN. 
"""
false_positives = [
    """
    False positives may occur when users are using a VPN or when users are traveling to different locations"
    """,
    """
    Mobile access may also result in false positives, as users may log in from various locations while on the go.
    """,
]
from = "now-15m"
index = ["logs-o365.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Identity Login from Atypical Region"
note = """## Triage and analysis

### Investigating M365 Identity Login from Atypical Region

Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon regions, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical country/region pairs for a given user, flagging potential unauthorized access attempts by analyzing login events and user location patterns at country and region granularity.

### Possible investigation steps

- Review the user associated with these sign-ins to determine if the login attempt was legitimate or if further investigation is needed.
- Analyze the geographic locations of the logins to identify any patterns or anomalies that may indicate malicious activity.
- Review the ISP information for the login attempts to identify any unusual or suspicious providers.
- Review the authorization request type to understand the context of the login attempts and whether they align with the user's typical behavior.
- Analyze the client application used for the login attempts to determine if it is consistent with the user's normal usage patterns (Teams, Office, etc.)
- Analyze the user-agent associated with the login attempts to identify any unusual or suspicious patterns. These could also indicate mobile and endpoint logins causing false-positives.

### False positive analysis

- Users traveling or using VPNs may trigger this alert. Verify with the user if they were traveling or using a VPN at the time of the login attempt.
- Mobile access may also result in false positives, as users may log in from various locations while on the go.

### Response and remediation

- Investigate the login attempt further by checking for any additional context or related events that may provide insight into the user's behavior.
- If the login attempt is deemed suspicious, consider implementing additional security measures, such as requiring multi-factor authentication (MFA) for logins from unusual locations.
- Educate users about the risks of accessing corporate resources from unfamiliar locations and the importance of using secure connections (e.g., VPNs) when doing so.
- Monitor for any subsequent login attempts from the same location or IP address to identify potential patterns of malicious activity.
- Consider adding exceptions to this rule for the user or source application ID if the login attempts are determined to be legitimate and not a security concern.
"""
references = ["https://www.huntress.com/blog/time-travelers-busted-how-to-detect-impossible-travel-"]
risk_score = 47
rule_id = "32d3ad0e-6add-11ef-8c7b-f661ea17fbcc"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset:o365.audit and 
    event.provider:AzureActiveDirectory and
    event.action:UserLoggedIn and event.outcome:success and
    o365.audit.Target.Type:(0 or 2 or 3 or 5 or 6 or 10) and
    o365.audit.UserId:(* and not "Not Available") and
    source.geo.country_name:* and
    source.geo.region_name:* and
    o365.audit.ApplicationId:(* and not (
        08e18876-6177-487e-b8b5-cf950c1e598c or
        29d9ed98-a469-4536-ade2-f981bc1d605e or
        38aa3b87-a06d-4817-b275-7a316988d93b or
        3e62f81e-590b-425b-9531-cad6683656cf or
        a809996b-059e-42e2-9866-db24b99a9782 or
        d7b530a4-7680-4c23-a8bf-c52c121d2e87
    )) and
    o365.audit.ExtendedProperties.RequestType:(* and not (
        "Consent:Set" or
        "DeviceAuth:ReprocessTls" or
        "Federation:oauth2claimsprovider" or
        "Federation:oauth2msa" or
        "Kmsi:kmsi" or
        "Login:reprocess" or
        "Login:resume" or
        "MessagePrompt:MessagePrompt" or
        "OrgIdWsFederation:federation" or 
        "PermitSso:PermitSso" or
        "SAS:EndAuth" or
        "SAS:ProcessAuth" or
        "SSPR:end" or
        "Saml2:processrequest" or
        "WsFederation:wsfederation"
    )) and
    not user_agent.original:(*Android* or *PKeyAuth* or *WebView* or *iPad* or *iPhone*)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
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/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "organization.id",
    "o365.audit.UserId",
    "o365.audit.ActorIpAddress",
    "o365.audit.ApplicationId",
    "o365.audit.ExtendedProperties.RequestType",
    "o365.audit.Target.ID",
    "source.geo.country_name",
    "source.geo.region_name",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["o365.audit.UserId", "source.geo.country_name", "source.geo.region_name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[metadata]
bypass_bbr_timing = true
creation_date = "2026/02/20"
integration = ["o365"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies Microsoft 365 Data Loss Prevention (DLP) and Data Lifecycle Management (DLM) signals from Microsoft Purview
across Exchange, SharePoint, OneDrive, and endpoint devices. These events indicate potential data exfiltration attempts,
policy violations involving sensitive data, or unauthorized sharing of classified information. This building block rule
generates security events for correlation, threat hunting, and telemetry collection to support detection of collection
and exfiltration activities.
"""
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Purview DLP Signal"
references = [
    "https://learn.microsoft.com/en-us/purview/dlp-learn-about-dlp",
    "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#enum-auditlogrecordtype---type-edmint32",
]
risk_score = 21
rule_id = "b8f54e38-7a1d-4c9b-9e2f-3a4b5c6d7e8f"
setup = """### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Purview",
    "Data Source: Microsoft Purview DLP",
    "Use Case: Threat Detection",
    "Use Case: Data Protection",
    "Tactic: Collection",
    "Tactic: Exfiltration",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset:o365.audit and
    event.code:(ComplianceDLPSharePoint or ComplianceDLPExchange or ComplianceDLPSharePointClassification or DLPEndpoint or ComplianceDLPExchangeClassification or ComplianceDLMExchange or ComplianceDLMSharePoint)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"

[[rule.threat.technique]]
id = "T1114"
name = "Email Collection"
reference = "https://attack.mitre.org/techniques/T1114/"

[[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]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"

[[rule.threat.technique.subtechnique]]
id = "T1567.002"
name = "Exfiltration to Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1567/002/"

[rule.threat.tactic]
id = "TA0010"
name = "Exfiltration"
reference = "https://attack.mitre.org/tactics/TA0010/"

[metadata]
creation_date = "2025/04/25"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule monitors for manual memory dumping via the proc filesystem. The proc filesystem in Linux provides a virtual filesystem
that contains information about system processes and their memory mappings. Attackers may use this technique to dump the memory
of a process, potentially extracting sensitive information such as credentials or encryption keys.
"""
from = "now-9m"
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 = "Manual Memory 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 Manual Memory Dumping via Proc Filesystem

The proc filesystem in Linux is a virtual interface providing detailed insights into system processes and their memory. Adversaries exploit this by manually dumping memory from processes to extract sensitive data like credentials. The detection rule identifies suspicious activities by monitoring process executions that access memory files within the proc directory, flagging potential credential access attempts.

### Possible investigation steps

- Review the alert details to identify the specific process name and command line that triggered the rule, focusing on processes like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep" accessing "/proc/*/mem".
- Examine the process execution context, including the parent process and user account associated with the suspicious activity, to determine if the activity is expected or potentially malicious.
- Check the system logs and historical data for any previous occurrences of similar activities involving the same process names and command lines to assess if this is part of a pattern or anomaly.
- Investigate the user account's recent activities and permissions to determine if there are any signs of compromise or unauthorized access that could explain the memory dumping attempt.
- Analyze network traffic and connections from the host to identify any potential data exfiltration attempts or communications with known malicious IP addresses or domains.
- If necessary, isolate the affected system to prevent further potential data leakage and conduct a deeper forensic analysis to uncover any additional indicators of compromise.

### False positive analysis

- System administrators or automated scripts may legitimately access the proc filesystem for monitoring or debugging purposes. To handle this, identify and whitelist known scripts or administrative tools that frequently access memory files.
- Security tools or monitoring solutions might access the proc filesystem as part of their regular operations. Review and exclude these processes from the rule to prevent unnecessary alerts.
- Developers or testers might use commands like cat or grep on proc files during application debugging. Establish a list of approved users or groups who are allowed to perform these actions and exclude their activities from triggering alerts.
- Backup or system maintenance processes could involve accessing proc files. Document these processes and create exceptions for them to avoid false positives.
- Regular system health checks might involve accessing memory files. Identify these checks and configure the rule to ignore them by specifying the associated process names or command patterns.

### Response and remediation

- Immediately isolate the affected system to prevent further unauthorized access or data exfiltration. Disconnect the network connection and disable remote access capabilities.
- Terminate any suspicious processes identified by the detection rule, specifically those accessing memory files within the proc directory using commands like "cat", "grep", "tail", "less", "more", "egrep", or "fgrep".
- Conduct a memory analysis on the isolated system to identify any extracted sensitive data, such as credentials or encryption keys, and assess the extent of the compromise.
- Change all potentially compromised credentials and encryption keys immediately, prioritizing those associated with critical systems and services.
- Review and enhance system logging and monitoring configurations to ensure comprehensive visibility into process activities, particularly those involving the proc filesystem.
- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if the threat is part of a larger attack campaign.
- Implement additional security controls, such as restricting access to the proc filesystem and employing application whitelisting, to prevent unauthorized memory dumping activities in the future.
"""
risk_score = 73
rule_id = "6505e02e-28dd-41cd-b18f-64e649caa4e2"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Use Case: Vulnerability",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "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 ("cat", "grep", "tail", "less", "more", "egrep", "fgrep") and process.command_line like "/proc/*/mem"
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

[[rule.threat.technique.subtechnique]]
id = "T1003.007"
name = "Proc Filesystem"
reference = "https://attack.mitre.org/techniques/T1003/007/"

[[rule.threat.technique]]
id = "T1212"
name = "Exploitation for Credential Access"
reference = "https://attack.mitre.org/techniques/T1212/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[rule]
description = """
Identifies unsigned code calling an IOCTL in the TTD Monitor kernel driver to suspend a specific process by PID.
Adversaries may abuse this driver to tamper with endpoint security solutions.
"""
id = "4953d091-dd91-4380-9531-e373a5bfffaf"
license = "Elastic License v2"
name = "Process Suspended via TTD Monitor Driver"
os_list = ["windows"]
reference = [
    "https://www.sentinelone.com/labs/fin7-reboot-cybercrime-gang-enhances-ops-with-new-edr-bypasses-and-automated-attacks/",
]
version = "1.0.3"

query = '''
api where
  process.Ext.api.name == "DeviceIoControl" and
  process.Ext.api.parameters.device : "\\Device\\com_microsoft_idna_ProcLaunchMon" and
  /* IOCTL 0x228034 to suspend a PID */
  process.Ext.api.parameters.io_control_code == 2261044 and
  not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $caller, $caller.trusted == true)
'''

min_endpoint_version = "8.14.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"


[threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"


[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "8.14.0"