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

nldcsc_elastic_rules/rules/cross-platform/discovery_security_software_grep.toml

@@ -0,0 +1,140 @@
+[metadata]
+creation_date = "2020/12/20"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2024/10/18"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the use of the grep command to discover known third-party macOS and Linux security tools, such as Antivirus
+or Host Firewall details.
+"""
+false_positives = ["Endpoint Security installers, updaters and post installation verification scripts."]
+from = "now-9m"
+index = ["logs-endpoint.events.*", "auditbeat-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Security Software Discovery via Grep"
+note = """## Triage and analysis
+
+### Investigating Security Software Discovery via Grep
+
+After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software.
+
+This rule looks for the execution of the `grep` utility with arguments compatible to the enumeration of the security software installed on the host. Attackers can use this information to decide whether or not to infect a system, disable protections, use bypasses, etc.
+
+#### Possible investigation steps
+
+- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.
+- Investigate any abnormal behavior by the subject process such as network connections, file modifications, and any spawned child processes.
+- Inspect the host for suspicious or abnormal behavior in the alert timeframe.
+- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
+
+### False positive analysis
+
+- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Isolate the involved hosts to prevent further post-compromise behavior.
+- 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 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).
+"""
+risk_score = 47
+rule_id = "870aecc0-cea4-4110-af3f-e02e9b373655"
+setup = """## Setup
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: macOS",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Resources: Investigation Guide",
+    "Data Source: Elastic Defend",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where event.type == "start" and
+process.name : "grep" and user.id != "0" and
+ not process.parent.executable : ("/Library/Application Support/*", "/opt/McAfee/agent/scripts/ma") and
+   process.args :
+         ("Little Snitch*",
+          "Avast*",
+          "Avira*",
+          "ESET*",
+          "BlockBlock*",
+          "360Sec*",
+          "LuLu*",
+          "KnockKnock*",
+          "kav",
+          "KIS",
+          "RTProtectionDaemon*",
+          "Malware*",
+          "VShieldScanner*",
+          "WebProtection*",
+          "webinspectord*",
+          "McAfee*",
+          "isecespd*",
+          "macmnsvc*",
+          "masvc*",
+          "kesl*",
+          "avscan*",
+          "guard*",
+          "rtvscand*",
+          "symcfgd*",
+          "scmdaemon*",
+          "symantec*",
+          "sophos*",
+          "osquery*",
+          "elastic-endpoint*"
+          ) and
+   not (
+     (process.args : "Avast" and process.args : "Passwords") or
+     (process.args == "osquery.conf") or 
+     (process.parent.args : "/opt/McAfee/agent/scripts/ma" and process.parent.args : "checkhealth") or
+     (process.command_line : (
+       "grep ESET Command-line scanner, version %s -A2",
+       "grep -i McAfee Web Gateway Core version:",
+       "grep --color=auto ESET Command-line scanner, version %s -A2"
+       )
+     ) or
+     (process.parent.command_line : (
+       """sh -c printf "command_start_%s"*; perl -pe 's/[^ -~]/\n/g' < /opt/eset/esets/sbin/esets_scan | grep 'ESET Command-line scanner, version %s' -A2 | tail -1; printf "command_done_%s*""",
+       """bash -c perl -pe 's/[^ -~]/\n/g' < /opt/eset/esets/sbin/esets_scan | grep 'ESET Command-line scanner, version %s' -A2 | tail -1"""
+       )
+     )
+    )
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1518"
+name = "Software Discovery"
+reference = "https://attack.mitre.org/techniques/T1518/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1518.001"
+name = "Security Software Discovery"
+reference = "https://attack.mitre.org/techniques/T1518/001/"
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"

nldcsc_elastic_rules/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml

@@ -0,0 +1,102 @@
+[metadata]
+creation_date = "2021/09/29"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+An adversary may attempt to get detailed information about the operating system and hardware. This rule identifies
+common locations used to discover virtual machine hardware by a non-root user. This technique has been used by the Pupy
+RAT and other malware.
+"""
+false_positives = [
+    """
+    Certain tools or automated software may enumerate hardware information. These tools can be exempted via user name or
+    process arguments to eliminate potential noise.
+    """,
+]
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Virtual Machine Fingerprinting via Grep"
+references = ["https://objective-see.com/blog/blog_0x4F.html"]
+risk_score = 47
+rule_id = "c85eb82c-d2c8-485c-a36f-534f914b7663"
+setup = """## Setup
+
+If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2,
+events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2.
+Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate
+`event.ingested` to @timestamp.
+For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: macOS",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Discovery",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where event.type == "start" and
+ process.name in ("grep", "egrep") and user.id != "0" and
+ process.args : ("parallels*", "vmware*", "virtualbox*") and process.args : "Manufacturer*" and
+ not process.parent.executable in ("/Applications/Docker.app/Contents/MacOS/Docker", "/usr/libexec/kcare/virt-what")
+'''
+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 Virtual Machine Fingerprinting via Grep
+
+Virtual machine fingerprinting involves identifying virtualized environments by querying system details. Adversaries exploit tools like `grep` to extract information about virtual machine hardware, aiding in evasion or targeting. The detection rule identifies non-root users executing `grep` with arguments linked to virtual machine identifiers, flagging potential reconnaissance activities while excluding benign processes.
+
+### Possible investigation steps
+
+- Review the process execution details to confirm the non-root user who initiated the `grep` or `egrep` command and assess their typical behavior and access rights.
+- Examine the command-line arguments used with `grep` to identify specific virtual machine identifiers such as "parallels", "vmware", or "virtualbox" and determine if these align with known reconnaissance patterns.
+- Investigate the parent process of the `grep` command to understand the context in which it was executed, ensuring it is not a benign process like Docker or kcare.
+- Check for any additional suspicious activities or commands executed by the same user around the same time to identify potential lateral movement or further reconnaissance.
+- Correlate this event with other security alerts or logs to determine if it is part of a broader attack pattern or campaign, particularly looking for connections to known malware like Pupy RAT.
+
+### False positive analysis
+
+- Non-root users running legitimate scripts or applications that query virtual machine identifiers for system management or inventory purposes may trigger the rule. To handle this, identify and whitelist these specific scripts or applications by excluding their parent executable paths.
+- Developers or IT personnel using grep to troubleshoot or gather system information on virtual machines might be flagged. Create exceptions for known user accounts or specific directories where these activities are expected.
+- Automated monitoring tools that check virtual machine environments for compliance or performance metrics could cause false positives. Exclude these tools by adding their process names or parent executables to the exception list.
+- Some virtualization management software might use grep internally to gather system information. Identify these applications and exclude their processes to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further reconnaissance or data exfiltration by the adversary.
+- Terminate any suspicious processes identified by the alert, specifically those involving `grep` or `egrep` with arguments related to virtual machine identifiers.
+- Conduct a thorough review of the affected system's user accounts and permissions, focusing on non-root users, to identify any unauthorized access or privilege escalation.
+- Analyze system logs and network traffic for any signs of lateral movement or additional compromise, paying close attention to connections initiated by the affected system.
+- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise.
+- Implement stricter access controls and monitoring for systems running virtual machines, including enhanced logging and alerting for similar reconnaissance activities.
+- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1082"
+name = "System Information Discovery"
+reference = "https://attack.mitre.org/techniques/T1082/"
+
+
+[rule.threat.tactic]
+id = "TA0007"
+name = "Discovery"
+reference = "https://attack.mitre.org/tactics/TA0007/"
+

nldcsc_elastic_rules/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml

@@ -0,0 +1,166 @@
+[metadata]
+creation_date = "2022/09/03"
+integration = ["endpoint", "auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the use of the AWS Systems Manager (SSM) `SendCommand` API with the either `AWS-RunShellScript` or
+`AWS-RunPowerShellScript` parameters. The `SendCommand` API call allows users to execute commands on EC2 instances using
+the SSM service. Adversaries may use this technique to execute commands on EC2 instances without the need for SSH or RDP
+access. This behavior may indicate an adversary attempting to execute commands on an EC2 instance for malicious
+purposes. This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags
+when this behavior is observed for the first time on a host in the last 7 days.
+"""
+false_positives = [
+    """
+    Legitimate use of the `SendCommand` API call to execute commands on EC2 instances using the SSM service may be done
+    by system administrators or DevOps engineers for legitimate purposes.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "AWS SSM `SendCommand` with Run Shell Command Parameters"
+references = [
+    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc",
+    "https://securitycafe.ro/2023/01/17/aws-post-explitation-with-ssm-sendcommand/",
+]
+risk_score = 47
+rule_id = "c371e9fc-6a10-11ef-a0ac-f661ea17fbcc"
+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: Endpoint",
+    "Domain: Cloud",
+    "OS: Linux",
+    "OS: macOS",
+    "OS: Windows",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.category: "process" and event.type: "start" and process.name: "aws"
+and (
+    host.os.type: ("windows" or "macos")
+    or (
+        host.os.type: "linux"
+        and event.action: ("exec" or "exec_event" or "executed" or "process_started")
+    )
+)
+and process.args: (
+    "send-command" and "--parameters" and commands=*
+    and ("AWS-RunShellScript" or "AWS-RunPowerShellScript")
+)
+'''
+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 AWS SSM `SendCommand` with Run Shell Command Parameters
+
+AWS Systems Manager (SSM) allows remote command execution on EC2 instances via the `SendCommand` API, using scripts like `AWS-RunShellScript` or `AWS-RunPowerShellScript`. Adversaries may exploit this to execute unauthorized commands without direct access. The detection rule identifies unusual command executions by monitoring process activities, flagging first-time occurrences within a week to spot potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific EC2 instance and the user account associated with the `SendCommand` API call.
+- Check the AWS CloudTrail logs for the `SendCommand` event to gather additional context, such as the source IP address, user agent, and any associated IAM roles or policies.
+- Investigate the command parameters used in the `SendCommand` API call, focusing on the `commands` field to determine the nature and intent of the executed script.
+- Examine the process execution history on the affected host to identify any unusual or unauthorized processes that may have been initiated as a result of the command.
+- Assess the recent activity of the user account involved in the alert to identify any other suspicious actions or deviations from normal behavior.
+- Verify the integrity and security posture of the affected EC2 instance, checking for any signs of compromise or unauthorized changes.
+
+### False positive analysis
+
+- Routine administrative tasks using AWS SSM SendCommand may trigger alerts. Identify and document regular maintenance scripts and exclude them from detection to reduce noise.
+- Automated deployment processes often use AWS-RunShellScript or AWS-RunPowerShellScript. Review deployment logs and whitelist these processes if they are verified as non-threatening.
+- Monitoring or compliance checks that utilize SSM for gathering system information can be mistaken for malicious activity. Confirm these activities with the relevant teams and create exceptions for known benign operations.
+- Scheduled tasks or cron jobs that execute commands via SSM should be reviewed. If they are part of standard operations, consider excluding them from the rule to prevent false positives.
+- Development and testing environments frequently use SSM for testing scripts. Ensure these environments are well-documented and apply exceptions to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution and potential lateral movement.
+- Review the AWS CloudTrail logs to identify the source of the `SendCommand` API call, including the IAM user or role that initiated the command, and assess whether the access was legitimate or compromised.
+- Revoke or rotate the credentials of the IAM user or role involved in the suspicious activity to prevent further unauthorized access.
+- Conduct a thorough examination of the affected EC2 instance to identify any unauthorized changes or installed malware, and restore the instance from a known good backup if necessary.
+- Implement stricter IAM policies and permissions to limit the use of the `SendCommand` API to only trusted users and roles, ensuring the principle of least privilege is enforced.
+- Enable multi-factor authentication (MFA) for all IAM users with permissions to execute commands on EC2 instances to add an additional layer of security.
+- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised."""
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "process.user.name",
+    "process.entry_leader.group.name",
+    "process.entry_leader.real_user.name",
+    "event.action",
+    "event.type",
+    "host.os.type",
+    "host.os.kernel",
+    "process.entry_leader.executable",
+    "process.entry_leader.working_directory",
+    "process.parent.executable",
+    "process.executable",
+    "process.hash.sha256",
+    "process.parent.command_line",
+    "process.command_line",
+    "process.args"
+]
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1651"
+name = "Cloud Administration Command"
+reference = "https://attack.mitre.org/techniques/T1651/"
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["host.id"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/cross-platform/execution_git_exploit_cve_2025_48384.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2025/11/12"
+integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/11/12"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects potential exploitation of CVE-2025-48384 via Git. This vulnerability allows attackers to execute arbitrary code
+by leveraging Git's recursive clone feature to fetch and execute malicious scripts from a remote repository.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "logs-crowdstrike.fdr*",
+    "logs-auditd_manager.auditd-*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Git CVE-2025-48384 Exploitation"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Potential Git CVE-2025-48384 Exploitation
+
+This rule flags a Git recursive clone from an HTTP(S) remote followed moments later by a shell spawned by Git—clear evidence of CVE-2025-48384 abuse enabling arbitrary code execution on Linux or macOS. An attacker ships a repository whose submodules or hooks pull and run a bash script during --recursive clone, causing Git to invoke a shell and execute their payload on a developer endpoint.
+
+### Possible investigation steps
+
+- Extract the remote URL and parameters from the git invocation and review .gitmodules to enumerate submodules, then assess the domain/account reputation and recent commits for signs of a malicious repo or takeover.
+- Inspect the cloned repository for hook execution vectors by reviewing .git/hooks and any core.hooksPath overrides for newly created or modified executables (post-checkout/post-merge/post-update), noting contents and timestamps.
+- Analyze the spawned shell’s lineage, command line, working directory, and any script or binary launched to identify the payload, compute hashes, and correlate with concurrent outbound connections or file writes.
+- Pivot on the repo URL, hooks filenames, and payload hash across hosts to identify other impacted endpoints, and verify whether this activity aligns with expected developer workflows or CI jobs to rule out benign use.
+- Examine the endpoint for follow-on changes suggesting execution or persistence (new cron/LaunchAgents entries, modified shell profiles, new SSH keys or credentials files, unusual PATH or gitconfig changes), and collect artifacts for forensic review.
+
+### False positive analysis
+
+- Legitimate organization-wide or user-level Git hooks installed via core.hooksPath or templates run a post-checkout bootstrap shell script after a recursive HTTP or HTTPS clone, causing git to spawn a shell as a child process.
+- During a recursive HTTP or HTTPS clone, Git invokes a credential or askpass helper implemented as a shell script for authentication, resulting in a benign sh/bash child of the git process.
+
+### Response and remediation
+
+- Immediately isolate any host where git clone --recursive from an HTTP(S) URL spawned a shell, terminate the git process tree (bash/sh and curl/wget/python children) launched from the cloned path, and block the repository domain on your proxy and Git hosting.
+- Quarantine the cloned directory and its .git folder, preserve .gitmodules, .git/hooks, and any core.hooksPath target for forensics, then remove executable hooks (post-checkout/post-merge/post-update) and delete the repository and downloaded payload scripts.
+- Rotate credentials available to the user (replace ~/.ssh keys and clear ~/.git-credentials/osxkeychain/libsecret), and eradicate persistence by removing new cron entries, LaunchAgents/LaunchDaemons, modified shell profiles (~/.bashrc, ~/.zshrc), and unexpected PATH or gitconfig changes.
+- Scope and recover by hunting for the same remote URL, hook names, and payload hashes across endpoints and CI runners, reimaging or restoring clean baselines before returning systems to service.
+- Escalate to incident command if multiple hosts show a git->shell chain from the same repository, if the payload invoked sudo or wrote to /etc/cron* or /Library/LaunchDaemons, or if outbound transfers occur to the repo’s domain or newly contacted IPs.
+- Upgrade Git to a patched release for CVE-2025-48384, enforce core.hooksPath to a read-only allowlisted directory, disable recursive submodule cloning by default (submodule.recurse=false), restrict protocols (protocol.file.allow=never; allow only https/ssh), and block clones from untrusted domains in developer and CI environments.
+"""
+references = [
+  "https://www.kucoin.com/zh-hant/blog/en-breaking-lazarus-group-apt38-targets-crypto-sector-with-sophisticated-phishing-campaign",
+  "https://securitylabs.datadoghq.com/articles/git-arbitrary-file-write/",
+  "https://github.com/acheong08/CVE-2025-48384"
+]
+risk_score = 73
+rule_id = "640f0535-f784-4010-b999-39db99d2daeb"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Data Source: Auditd Manager",
+    "Data Source: SentinelOne",
+    "Data Source: Crowdstrike",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+sequence by host.id with maxspan=1m
+  [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and
+   process.name == "git" and process.args == "clone" and process.args == "--recursive" and process.args like~ "http*"] by process.entity_id
+  [process where host.os.type in ("linux", "macos") and event.type == "start" and event.action in ("exec", "executed", "process_started", "start", "ProcessRollup2") and
+   process.name in (
+    "dash", "sh", "static-sh", "bash", "bash-static", "zsh", "ash", "csh", "ksh", "tcsh", "busybox", "fish", "ksh93", "rksh",
+    "rksh93", "lksh", "mksh", "mksh-static", "csharp", "posh", "rc", "sash", "yash", "zsh5", "zsh5-static"
+   )] by process.parent.entity_id
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+  [rule.threat.tactic]
+  name = "Execution"
+  id = "TA0002"
+  reference = "https://attack.mitre.org/tactics/TA0002/"
+
+  [[rule.threat.technique]]
+  name = "Exploitation for Client Execution"
+  id = "T1203"
+  reference = "https://attack.mitre.org/techniques/T1203/"

nldcsc_elastic_rules/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml

@@ -0,0 +1,87 @@
+[metadata]
+creation_date = "2021/01/12"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = "Identifies the execution of and EggShell Backdoor. EggShell is a known post exploitation tool for macOS and Linux."
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "EggShell Backdoor Execution"
+references = ["https://github.com/neoneggplant/EggShell"]
+risk_score = 73
+rule_id = "41824afb-d68c-4d0e-bfee-474dac1fa56e"
+severity = "high"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "OS: macOS",
+    "Use Case: Threat Detection",
+    "Tactic: Execution",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.category:process and event.type:(process_started or start) and process.name:espl and process.args:eyJkZWJ1ZyI6*
+'''
+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 EggShell Backdoor Execution
+
+EggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands and scripts remotely. It leverages command and scripting interpreters to gain control over compromised systems. Attackers exploit this by executing malicious payloads, maintaining persistence, and exfiltrating data. The detection rule identifies suspicious process activities, specifically targeting the execution patterns and arguments associated with EggShell, to alert analysts of potential backdoor usage.
+
+### Possible investigation steps
+
+- Review the alert details to confirm the presence of the process name 'espl' and check if the process arguments start with 'eyJkZWJ1ZyI6', which indicates potential EggShell activity.
+- Investigate the parent process of 'espl' to understand how it was initiated and identify any associated suspicious activities or processes.
+- Examine the user account under which the 'espl' process was executed to determine if it aligns with expected behavior or if it indicates a compromised account.
+- Check for any network connections or data exfiltration attempts associated with the 'espl' process to assess if data has been sent to an external source.
+- Review system logs and other security alerts around the time of the 'espl' process execution to identify any correlated events or anomalies.
+- Assess the persistence mechanisms on the affected system to determine if the EggShell backdoor has established any means to survive reboots or user logouts.
+
+### False positive analysis
+
+- Legitimate administrative scripts or tools that use similar command patterns to EggShell may trigger false positives. Review the process arguments and context to determine if the activity is expected and authorized.
+- Development or testing environments where EggShell or similar tools are used for legitimate purposes can cause alerts. Implement exceptions for these environments by excluding specific user accounts or process paths.
+- Automated scripts or monitoring tools that mimic EggShell's execution patterns might be flagged. Identify these scripts and create exceptions based on their unique identifiers or execution context.
+- Regularly update the detection rule to refine the criteria based on observed false positives, ensuring that legitimate activities are not continuously flagged.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further command execution and data exfiltration.
+- Terminate any suspicious processes associated with the EggShell backdoor, specifically those matching the process name 'espl' and arguments starting with 'eyJkZWJ1ZyI6'.
+- Conduct a thorough examination of the system to identify any additional malicious payloads or persistence mechanisms that may have been deployed by the attacker.
+- Remove any unauthorized user accounts or access credentials that may have been created or compromised during the exploitation.
+- Restore the system from a known good backup to ensure all traces of the backdoor and any associated malware are eradicated.
+- Update and patch all software and systems to close any vulnerabilities that may have been exploited by the attacker.
+- Enhance monitoring and detection capabilities to identify similar threats in the future, focusing on command and scripting interpreter activities as outlined in MITRE ATT&CK technique T1059."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+[[rule.threat.technique.subtechnique]]
+id = "T1059.006"
+name = "Python"
+reference = "https://attack.mitre.org/techniques/T1059/006/"
+
+
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+