mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 01:38:56 -04:00
(cherry picked from commit b01c4bcdb8)
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
This commit is contained in:
Kibana Machine
GitHub
parent
4c9a7d493f
commit
3c95fcd403
75 changed files with 99 additions and 96 deletions
|
|
@ -33,5 +33,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Port Forwarding Rule Addition",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Port Forwarding Rule Addition\n\nNetwork port forwarding is a mechanism to redirect incoming TCP connections (IPv4 or IPv6) from the local TCP port to\nany other port number, or even to a port on a remote computer.\n\nAttackers may configure port forwarding rules to bypass network segmentation restrictions, using the host as a jump box\nto access previously unreachable systems.\n\nThis rule monitors the modifications to the `HKLM\\SYSTEM\\*ControlSet*\\Services\\PortProxy\\v4tov4\\` subkeys.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Identify the target host IP address, verify if connections were made from the host where the modification occurred,\nand check what credentials were used to perform it.\n - Investigate suspicious login activity, such as unauthorized access and logins from outside working hours and unusual locations.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Analysts can dismiss the alert if the Administrator is aware of the activity\nand there are justifications for this configuration.\n- If this activity is expected and noisy in your environment, consider adding exceptions \u2014 preferably with a combination\nof user and command line conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Delete the port forwarding rule.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If potential malware or credential compromise activities were discovered during the alert triage, activate the respective\nincident response plan.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "registry where registry.path : \"HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\PortProxy\\\\v4tov4\\\\*\"\n",
|
||||
"references": [
|
||||
"https://www.fireeye.com/blog/threat-research/2019/01/bypassing-network-restrictions-through-rdp-tunneling.html"
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Potential Remote Desktop Tunneling Detected",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Potential Remote Desktop Tunneling Detected\n\nProtocol Tunneling is a mechanism that involves explicitly encapsulating a protocol within another for various use cases,\nranging from providing an outer layer of encryption (similar to a VPN) to enabling traffic that network appliances would\nfilter to reach their destination.\n\nAttackers may tunnel Remote Desktop Protocol (RDP) traffic through other protocols like Secure Shell (SSH) to bypass network restrictions that block incoming RDP\nconnections but may be more permissive to other protocols.\n\nThis rule looks for command lines involving the `3389` port, which RDP uses by default and options commonly associated\nwith tools that perform tunneling.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Determine if the activity is unique by validating if other machines in the organization have similar entries.\n- Examine network data to determine if the host communicated with external servers using the tunnel.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n- Investigate the command line for the execution of programs that are unrelated to tunneling, like Remote Desktop clients.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Disable the involved accounts, or restrict their ability to log on remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Take actions to disable the tunneling.\n- Investigate the initial attack vector.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n /* RDP port and usual SSH tunneling related switches in command line */\n process.args : \"*:3389\" and\n process.args : (\"-L\", \"-P\", \"-R\", \"-pw\", \"-ssh\")\n",
|
||||
"references": [
|
||||
"https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/"
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote File Download via Desktopimgdownldr Utility",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote File Download via Desktopimgdownldr Utility\n\nAttackers commonly transfer tooling or malware from external systems into a compromised environment using the command\nand control channel. However, they can also abuse signed utilities to drop these files.\n\nThe `Desktopimgdownldr.exe` utility is used to to configure lockscreen/desktop image, and can be abused with the\n`lockscreenurl` argument to download remote files and tools, this rule looks for this behavior.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Determine if the activity is unique by validating if other machines in the organization have similar entries.\n- Check the reputation of the domain or IP address used to host the downloaded file or if the user downloaded the file\nfrom an internal system.\n- Retrieve the file and determine if it is malicious:\n - Identify the file type.\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This activity is unusual but can be done by administrators. Benign true positives (B-TPs) can be added as exceptions\nif necessary.\n- Analysts can dismiss the alert if the downloaded file is a legitimate image.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the IoCs identified.\n- Remove and block malicious artifacts identified on the triage.\n- Disable the involved accounts, or restrict their ability to log on remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Investigate the initial attack vector.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n (process.name : \"desktopimgdownldr.exe\" or process.pe.original_file_name == \"desktopimgdownldr.exe\") and\n process.args : \"/lockscreenurl:http*\"\n",
|
||||
"references": [
|
||||
"https://labs.sentinelone.com/living-off-windows-land-a-new-native-file-downldr/"
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote File Download via MpCmdRun",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote File Download via MpCmdRun\nVerify details such as the parent process, URL reputation, and downloaded file details. Additionally, `MpCmdRun` logs this information in the Appdata Temp folder in `MpCmdRun.log`.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote File Download via MpCmdRun\n\nAttackers commonly transfer tooling or malware from external systems into a compromised environment using the command\nand control channel. However, they can also abuse signed utilities to drop these files.\n\nThe `MpCmdRun.exe` is a command-line tool part of Windows Defender and is used to manage various Microsoft Windows\nDefender Antivirus settings and perform certain tasks. It can also be abused by attackers to download remote files,\nincluding malware and offensive tooling. This rule looks for the patterns used to perform downloads using the utility.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check the reputation of the domain or IP address used to host the downloaded file.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the IoCs identified.\n- Remove and block malicious artifacts identified on the triage.\n- Disable the involved accounts, or restrict their ability to log on remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Investigate the initial attack vector.\nVerify details such as the parent process, URL reputation, and downloaded file details. Additionally, `MpCmdRun` logs this information in the Appdata Temp folder in `MpCmdRun.log`.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type == \"start\" and\n (process.name : \"MpCmdRun.exe\" or process.pe.original_file_name == \"MpCmdRun.exe\") and\n process.args : \"-DownloadFile\" and process.args : \"-url\" and process.args : \"-path\"\n",
|
||||
"references": [
|
||||
"https://twitter.com/mohammadaskar2/status/1301263551638761477",
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote File Download via PowerShell",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote File Download via PowerShell\n\nAttackers commonly transfer tooling or malware from external systems into a compromised environment using the command\nand control channel. However, they can also abuse signed utilities to drop these files.\n\nPowerShell is one of system administrators' main tools for automation, report routines, and other tasks. This makes it\navailable for use in various environments and creates an attractive way for attackers to execute code and perform\nactions. This rule correlates network and file events to detect downloads of executable and script files performed using\nPowerShell.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check the reputation of the domain or IP address used to host the downloaded file.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- Administrators can use PowerShell legitimately to download executable and script files. Analysts can dismiss the alert\nif the Administrator is aware of the activity and the triage has not identified suspicious or malicious files.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the IoCs identified.\n- Remove and block malicious artifacts identified on the triage.\n- Disable the involved accounts, or restrict their ability to log on remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Investigate the initial attack vector.\n",
|
||||
"query": "sequence by host.id, process.entity_id with maxspan=30s\n [network where process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") and network.protocol == \"dns\" and\n not dns.question.name : (\"localhost\", \"*.microsoft.com\", \"*.azureedge.net\", \"*.powershellgallery.com\", \"*.windowsupdate.com\", \"metadata.google.internal\") and \n not user.domain : \"NT AUTHORITY\"]\n [file where process.name : \"powershell.exe\" and event.type == \"creation\" and file.extension : (\"exe\", \"dll\", \"ps1\", \"bat\") and \n not file.name : \"__PSScriptPolicy*.ps1\"]\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "33f306e8-417c-411b-965c-c2812d6d3f4d",
|
||||
|
|
@ -63,5 +64,5 @@
|
|||
}
|
||||
],
|
||||
"type": "eql",
|
||||
"version": 3
|
||||
"version": 4
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote File Download via Script Interpreter",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote File Download via Script Interpreter\n\nThe Windows Script Host (WSH) is a Windows automation technology, which is ideal for non-interactive scripting needs,\nsuch as logon scripting, administrative scripting, and machine automation.\n\nAttackers commonly use WSH scripts as their initial access method, acting like droppers for second stage payloads, but\ncan also use them to download tools and utilities needed to accomplish their goals.\n\nThis rule looks for DLLs and executables downloaded using `cscript.exe` or `wscript.exe`.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Retrieve the script file and the executable involved:\n - Use a sandboxed malware analysis system to perform analysis.\n - Observe attempts to contact external domains and addresses.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n - Manually analyze the script to determine if malicious capabilities are present.\n- Investigate whether the potential malware ran successfully, is active on the host, or was stopped by defenses.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check for similar behavior in other hosts on the environment.\n\n### False positive analysis\n\n- The usage of these script engines by regular users is unlikely. In the case of authorized benign true positives\n(B-TPs), exceptions can be added.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n- Remove and block malicious artifacts identified on the triage.\n- Reimage the host operating system and restore compromised files to clean versions.\n",
|
||||
"query": "sequence by host.id, process.entity_id\n [network where process.name : (\"wscript.exe\", \"cscript.exe\") and network.protocol != \"dns\" and\n network.direction : (\"outgoing\", \"egress\") and network.type == \"ipv4\" and destination.ip != \"127.0.0.1\"\n ]\n [file where event.type == \"creation\" and file.extension : (\"exe\", \"dll\")]\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "1d276579-3380-4095-ad38-e596a01bc64f",
|
||||
|
|
@ -41,5 +42,5 @@
|
|||
}
|
||||
],
|
||||
"type": "eql",
|
||||
"version": 3
|
||||
"version": 4
|
||||
}
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "SUNBURST Command and Control Activity",
|
||||
"note": "## Triage and analysis\n\nThe SUNBURST malware attempts to hide within the Orion Improvement Program (OIP) network traffic. As this rule detects post-exploitation network traffic, investigations into this should be prioritized.",
|
||||
"note": "## Triage and analysis\n\n### Investigating SUNBURST Command and Control Activity\n\nSUNBURST is a trojanized version of a digitally signed SolarWinds Orion plugin called\nSolarWinds.Orion.Core.BusinessLayer.dll. The plugin contains a backdoor that communicates via HTTP to third-party\nservers. After an initial dormant period of up to two weeks, SUNBURST may retrieve and execute commands that instruct\nthe backdoor to transfer files, execute files, profile the system, reboot the system, and disable system services.\nThe malware's network traffic attempts to blend in with legitimate SolarWinds activity by imitating the Orion\nImprovement Program (OIP) protocol, and the malware stores persistent state data within legitimate plugin configuration files. The\nbackdoor uses multiple obfuscated blocklists to identify processes, services, and drivers associated with forensic and\nanti-virus tools.\n\nMore details on SUNBURST can be found on the [Mandiant Report](https://www.mandiant.com/resources/sunburst-additional-technical-details).\n\nThis rule identifies suspicious network connections that attempt to blend in with legitimate SolarWinds activity\nby imitating the Orion Improvement Program (OIP) protocol behavior.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Retrieve the executable involved:\n - Use a sandboxed malware analysis system to perform analysis.\n - Observe attempts to contact external domains and addresses.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n - Manually analyze the executable to determine if malicious capabilities are present.\n- Investigate whether the potential malware ran successfully, is active on the host, or was stopped by defenses.\n- Investigate the network traffic.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check for similar behavior in other hosts on the environment.\n\n### False positive analysis\n\n- False positives are unlikely for this rule.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n- Remove and block malicious artifacts identified on the triage.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Upgrade SolarWinds systems to the latest version.\n",
|
||||
"query": "network where event.type == \"protocol\" and network.protocol == \"http\" and\n process.name : (\"ConfigurationWizard.exe\",\n \"NetFlowService.exe\",\n \"NetflowDatabaseMaintenance.exe\",\n \"SolarWinds.Administration.exe\",\n \"SolarWinds.BusinessLayerHost.exe\",\n \"SolarWinds.BusinessLayerHostx64.exe\",\n \"SolarWinds.Collector.Service.exe\",\n \"SolarwindsDiagnostics.exe\") and\n (http.request.body.content : \"*/swip/Upload.ashx*\" and http.request.body.content : (\"POST*\", \"PUT*\")) or\n (http.request.body.content : (\"*/swip/SystemDescription*\", \"*/swip/Events*\") and http.request.body.content : (\"GET*\", \"HEAD*\")) and\n not http.request.body.content : \"*solarwinds.com*\"\n",
|
||||
"references": [
|
||||
"https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html"
|
||||
|
|
@ -73,5 +73,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 4
|
||||
"version": 5
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote File Copy via TeamViewer",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote File Copy via TeamViewer\n\nAttackers commonly transfer tooling or malware from external systems into a compromised environment using the command\nand control channel. However, they can also abuse legitimate utilities to drop these files.\n\nTeamViewer is a remote access and remote control tool used by helpdesks and system administrators to perform various\nsupport activities. It is also frequently used by attackers and scammers to deploy malware interactively and other\nmalicious activities. This rule looks for the TeamViewer process creating files with suspicious extensions.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Contact the user to gather information about who and why was conducting the remote access.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check whether the company uses TeamViewer for the support activities and if there is a support ticket related to this\naccess.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Analysts can dismiss the alert if the company relies on TeamViewer to conduct\nremote access and the triage has not identified suspicious or malicious files.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the IoCs identified.\n- Remove and block malicious artifacts identified on the triage.\n- Disable the involved accounts, or restrict their ability to log on remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "file where event.type == \"creation\" and process.name : \"TeamViewer.exe\" and\n file.extension : (\"exe\", \"dll\", \"scr\", \"com\", \"bat\", \"ps1\", \"vbs\", \"vbe\", \"js\", \"wsh\", \"hta\")\n",
|
||||
"references": [
|
||||
"https://blog.menasec.net/2019/11/hunting-for-suspicious-use-of.html"
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Potential Credential Access via DCSync",
|
||||
"note": "## Triage and analysis.\n\n### Investigating Active Directory Replication From User Account\n\nActive Directory replication is the process by which the changes that originate on one domain controller are\nautomatically transferred to other domain controllers that store the same data. \n\nActive Directory data takes the form of objects that have properties, or attributes. Each object is an instance\nof an object class, and object classes and their respective attributes are defined in the Active Directory schema.\nThe values of the attributes define the object, and a change to a value of an attribute must be transferred from\nthe domain controller on which it occurs to every other domain controller that stores a replica of that object.\n\nAdversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process\nfrom a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used\nlegitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges\nto succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of\nthe Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused\nto grant controlled objects the right to DCsync/Replicate.\n\nMore details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing).\nand [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync)\n\nThis rule will monitor for Event ID 4662 (Operation was performed on an Active Directory object) and identify events that use the access\nmask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID\n(DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that\nuse computer accounts and also Azure AD Connect MSOL accounts (more details [here](https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028)).\n\n#### Possible investigation steps:\n\n- Identify the account that performed the action.\n- Confirm whether the account owner is aware of the operation.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller (DC) that received\nthe replication request. This will tell you where the AD replication request came from, and if it came from another DC or not.\n- Investigate which credentials were compromised (e.g. All accounts were replicated or a specific account).\n\n### False Positive Analysis\n\n- This activity should not happen legitimately. Any potential B-TP (Benign True Positive) should be mapped and monitored by the security\nteam as replication should be done by Domain Controllers only. Any account that performs this activity can put the domain at risk for not\nhaving the same security standards (Long, complex, random passwords that change frequently) as computer accounts, exposing it to credential\ncracking attacks (Kerberoasting, brute force, etc.).\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If specific credentials were compromised:\n - Reset the password for the accounts.\n- If the entire domain or the `krbtgt` user were compromised:\n - Activate your incident response plan for total Active Directory compromise which should include, but not be limited to, a password\n reset (twice) of the `krbtgt` user.\n\n## Config\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration > \nPolicies > \nWindows Settings > \nSecurity Settings > \nAdvanced Audit Policies Configuration > \nAudit Policies > \nDS Access > \nAudit Directory Service Changes (Success,Failure)\n```\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Potential Credential Access via DCSync\n\nActive Directory replication is the process by which the changes that originate on one domain controller are\nautomatically transferred to other domain controllers that store the same data.\n\nActive Directory data consists of objects that have properties, or attributes. Each object is an instance of an object\nclass, and object classes and their respective attributes are defined in the Active Directory schema. Objects are\ndefined by the values of their attributes, and changes to attribute values must be transferred from the domain\ncontroller on which they occur to every other domain controller that stores a replica of an affected object. \n\nAdversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process\nfrom a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used\nlegitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges\nto succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of\nthe Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused\nto grant controlled objects the right to DCsync/Replicate.\n\nMore details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync).\n\nThis rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that\nuse the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent:\nSchema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set).\nIt also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details [here](https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028)). \n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Correlate security events 4662 and 4624 (Logon Type 3) by their Logon ID (`winlog.logon.id`) on the Domain Controller\n(DC) that received the replication request. This will tell you where the AD replication request came from, and if it\ncame from another DC or not.\n- Investigate which credentials were compromised (for example whether all accounts were replicated, or only a specific account).\n\n### False positive analysis \n\n- This activity should not happen legitimately, since replication should be done by Domain Controllers only. Any\npotential benign true positive (B-TP) should be mapped and monitored by the security team. Any account that performs\nthis activity can put the domain at risk for not having the same security standards as computer accounts (which have\nlong, complex, random passwords that change frequently), exposing it to credential cracking attacks (Kerberoasting,\nbrute force, etc.).\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If specific credentials were compromised:\n - Reset passwords for affected accounts.\n- If the entire domain or the `krbtgt` user were compromised:\n - Activate your incident response plan for total Active Directory compromise which should include, but not be limited\n to, a password reset (twice) of the `krbtgt` user. \n\n## Config\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "any where event.action == \"Directory Service Access\" and\n event.code == \"4662\" and winlog.event_data.Properties : (\n\n /* Control Access Rights/Permissions Symbol */\n\n \"*DS-Replication-Get-Changes*\",\n \"*DS-Replication-Get-Changes-All*\",\n \"*DS-Replication-Get-Changes-In-Filtered-Set*\",\n\n /* Identifying GUID used in ACE */\n\n \"*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*\",\n \"*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*\",\n \"*89e95b76-444d-4c62-991a-0facbeda640c*\") \n \n /* The right to perform an operation controlled by an extended access right. */\n\n and winlog.event_data.AccessMask : \"0x100\" and\n not winlog.event_data.SubjectUserName : (\"*$\", \"MSOL_*\")\n",
|
||||
"references": [
|
||||
"https://threathunterplaybook.com/notebooks/windows/06_credential_access/WIN-180815210510.html",
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "kuery",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Credential Acquisition via Registry Hive Dumping",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Credential Acquisition via Registry Hive Dumping\n\nDumping registry hives is a common way to access credential information as some hives store credential material.\n\nFor example, the SAM hive stores locally cached credentials (SAM Secrets), and the SECURITY hive stores domain cached\ncredentials (LSA secrets).\n\nDumping these hives in combination with the SYSTEM hive enables the attacker to decrypt these secrets.\n\nThis rule identifies the usage of `reg.exe` to dump SECURITY and/or SAM hives, which potentially indicates the\ncompromise of the credentials stored in the host.\n\n#### Possible investigation steps\n\n- Investigate script execution chain (parent process tree).\n- Confirm whether the involved account should perform this kind of operation.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Investigate if the file was exfiltrated or processed locally by other tools.\n- Scope potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target\nhost.\n\n### False positive analysis\n\n- Administrators can export registry hives for backup purposes using command line tools like `reg.exe`. Check whether\nthe user is legitamitely performing this kind of activity.\n\n### Related rules\n\n- Registry Hive File Creation via SMB - a4c7473a-5cb4-4bc1-9d06-e4a75adbc494\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Scope compromised credentials and disable affected accounts.\n- Reset passwords for potentially compromised user and service accounts (Email, services, CRMs, etc.).\n- Reimage the host operating system and restore compromised files to clean versions.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n process.pe.original_file_name == \"reg.exe\" and\n process.args : (\"save\", \"export\") and\n process.args : (\"hklm\\\\sam\", \"hklm\\\\security\")\n",
|
||||
"references": [
|
||||
"https://medium.com/threatpunter/detecting-attempts-to-steal-passwords-from-the-registry-7512674487f8"
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Kerberos Traffic from Unusual Process",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Kerberos Traffic from Unusual Process\n\nKerberos is the default authentication protocol in Active Directory, designed to provide strong authentication for\nclient/server applications by using secret-key cryptography.\n\nDomain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of\ntraffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of\nKerberos tickets.\n\n#### Possible investigation steps\n\n- Investigate script execution chain (parent process tree).\n- Investigate other alerts related to the host and user in the last 48 hours.\n- Check if the Destination IP is related to a Domain Controller.\n- Review event ID 4769 for suspicious ticket requests.\n\n### False positive analysis\n\n- This rule uses a Kerberos-related port but does not identify the protocol used on that port. HTTP traffic on a\nnon-standard port or destination IP address unrelated to Domain controllers can create false positives.\n- Exceptions can be added for noisy/frequent connections.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Scope possible compromised credentials based on ticket requests.\n- Isolate the involved host to prevent further post-compromise behavior.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "network where event.type == \"start\" and network.direction : (\"outgoing\", \"egress\") and\n destination.port == 88 and source.port >= 49152 and\n process.executable != \"C:\\\\Windows\\\\System32\\\\lsass.exe\" and destination.address !=\"127.0.0.1\" and destination.address !=\"::1\" and\n /* insert false positives here */\n not process.name in (\"swi_fc.exe\", \"fsIPcam.exe\", \"IPCamera.exe\", \"MicrosoftEdgeCP.exe\", \"MicrosoftEdge.exe\", \"iexplore.exe\", \"chrome.exe\", \"msedge.exe\", \"opera.exe\", \"firefox.exe\")\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "897dc6b5-b39f-432a-8d75-d3730d50c782",
|
||||
|
|
|
|||
|
|
@ -56,5 +56,5 @@
|
|||
"timeline_title": "Comprehensive File Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 6
|
||||
"version": 7
|
||||
}
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "LSASS Memory Dump Handle Access",
|
||||
"note": "## Triage and analysis.\n\n### Investigating\n\nLocal Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible\nfor enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles\npassword changes, and creates access tokens.\n\nAdversaries may attempt to access credential material stored in the process memory of the LSASS. After a user logs on,\nthe system generates and stores a variety of credential materials in LSASS process memory. This is meant to facilitate\nsingle sign-on (SSO) ensuring a user isn\u2019t prompted each time resource access is requested. These credential materials\ncan be harvested by an adversary using administrative user or SYSTEM privileges to conduct Lateral Movement using\n[Use Alternate Authentication Material](https://attack.mitre.org/techniques/T1550/).\n\n#### Possible investigation steps:\n\n- Validate the correct install path for the process that triggered this detection\n- Confirm that any AV or EDR solutions that trigger this detection have the correct install path\n\n### False Positive Analysis\n\n- There should be very few if any false positives for this rule. However, it may be tripped by AV or EDR solutions.\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage\n- In case of specific credentials were compromised:\n - Reset the password for the accounts\n\n## Config\n\nEnsure advanced audit policies for Windows are enabled, specifically\nObject Access policies [Event ID 4656](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656) (Handle to an Object was Requested)\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nSystem Audit Policies >\nObject Access >\nAudit File System (Success,Failure)\nAudit Handle Manipulation (Success,Failure)\n```\n\nAlso, this event generates only if the object\u2019s [SACL](https://docs.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) has the required ACE to handle the use of specific access rights.\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating LSASS Memory Dump Handle Access\n\nLocal Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible\nfor enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles\npassword changes, and creates access tokens.\n\nAdversaries may attempt to access credential material stored in LSASS process memory. After a user logs on,the system\ngenerates and stores a variety of credential materials in LSASS process memory. This is meant to facilitate single\nsign-on (SSO) ensuring a user isn\u2019t prompted each time resource access is requested. These credential materials can be\nharvested by an adversary using administrative user or SYSTEM privileges to conduct lateral movement using \n[alternate authentication material](https://attack.mitre.org/techniques/T1550/).\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Validate the correct install path for the process that triggered this detection.\n\n### False positive analysis\n\n- There should be very few if any false positives for this rule. However, it may be tripped by antivirus or endpoint detection and response solutions;\ncheck whether these solutions are installed on the correct paths.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Scope compromised credentials and disable the accounts.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n## Config\n\nEnsure advanced audit policies for Windows are enabled, specifically:\nObject Access policies [Event ID 4656](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656) (Handle to an Object was Requested)\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nSystem Audit Policies >\nObject Access >\nAudit File System (Success,Failure)\nAudit Handle Manipulation (Success,Failure)\n```\n\nAlso, this event generates only if the object\u2019s [SACL](https://docs.microsoft.com/en-us/windows/win32/secauthz/access-control-lists) has the required access control entry (ACE) to handle the use of specific access rights.\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "any where event.action == \"File System\" and event.code == \"4656\" and\n\n winlog.event_data.ObjectName : (\n \"?:\\\\Windows\\\\System32\\\\lsass.exe\",\n \"\\\\Device\\\\HarddiskVolume?\\\\Windows\\\\System32\\\\lsass.exe\",\n \"\\\\Device\\\\HarddiskVolume??\\\\Windows\\\\System32\\\\lsass.exe\") and\n\n /* The right to perform an operation controlled by an extended access right. */\n\n (winlog.event_data.AccessMask : (\"0x1fffff\" , \"0x1010\", \"0x120089\", \"0x1F3FFF\") or\n winlog.event_data.AccessMaskDescription : (\"READ_CONTROL\", \"Read from process memory\"))\n\n /* Common Noisy False Positives */\n\n and not winlog.event_data.ProcessName : (\n \"?:\\\\Program Files\\\\*.exe\",\n \"?:\\\\Program Files (x86)\\\\*.exe\",\n \"?:\\\\Windows\\\\system32\\\\wbem\\\\WmiPrvSE.exe\",\n \"?:\\\\Windows\\\\System32\\\\dllhost.exe\",\n \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n \"?:\\\\Windows\\\\System32\\\\msiexec.exe\",\n \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\*.exe\",\n \"?:\\\\Windows\\\\explorer.exe\")\n",
|
||||
"references": [
|
||||
"https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Mimikatz Memssp Log File Detected",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis.\n\n### Investigating Mimikatz Memssp Log File Detected\n\n[Mimikatz](https://github.com/gentilkiwi/mimikatz) is an open-source tool used to collect, decrypt, and/or use cached\ncredentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained\nan initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects\nsuch as tokens/hashes/credentials that can then be used to laterally move and pivot across a network.\n\nThis rule looks for the creation of a file named `mimilsa.log`, which is generated when using the Mimikatz misc::memssp\nmodule, which injects a malicious Windows SSP to collect locally authenticated credentials, which includes the computer\naccount password, running service credentials, and any accounts that logon.\n\n#### Possible investigation steps\n\n- Investigate script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Scope potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target\nhost.\n- Retrieve and inspect the log file contents.\n- By default, the log file is created in the same location as the DLL file.\n- Search for DLL files created in the location, and retrieve any DLLs that are not signed:\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of these files.\n - Search for the existence of these files in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This file name `mimilsa.log` should not legitimately be created.\n\n### Related rules\n\n- Mimikatz Powershell Module Activity - ac96ceb8-4399-4191-af1d-4feeac1f1f46\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- If the host is a Domain Controller (DC):\n - Activate your incident response plan for total Active Directory compromise.\n - Review the permissions of users that can access the DCs.\n- Reset passwords for all compromised accounts.\n- Disable remote login for compromised user accounts.\n- Reboot the host to remove the injected SSP from memory.\n- Reimage the host operating system or restore compromised files to clean versions.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "file where file.name : \"mimilsa.log\" and process.name : \"lsass.exe\"\n",
|
||||
"risk_score": 73,
|
||||
"rule_id": "ebb200e8-adf0-43f8-a0bb-4ee5b5d852c6",
|
||||
|
|
|
|||
|
|
@ -2,14 +2,15 @@
|
|||
"author": [
|
||||
"Elastic"
|
||||
],
|
||||
"description": "Identifies the creation or modification of a medium size registry hive file via the SMB protocol. This may indicate an exfiltration attempt via dumping SAM registry hive in preparation for credential access.",
|
||||
"description": "Identifies the creation or modification of a medium-size registry hive file on an SMB share, which may indicate an exfiltration attempt of a previously dumped SAM registry hive for credential extraction on an attacker-controlled system.",
|
||||
"from": "now-9m",
|
||||
"index": [
|
||||
"logs-endpoint.events.*"
|
||||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Registry Hive File Creation via SMB",
|
||||
"name": "Windows Registry File Creation in SMB Share",
|
||||
"note": "## Triage and analysis\n\n### Investigating Windows Registry File Creation in SMB Share\n\nDumping registry hives is a common way to access credential information. Some hives store credential material, as is the\ncase for the SAM hive, which stores locally cached credentials (SAM Secrets), and the SECURITY hive, which stores domain\ncached credentials (LSA secrets). Dumping these hives in combination with the SYSTEM hive enables the attacker to\ndecrypt these secrets.\n\nAttackers can try to evade detection on the host by transferring this data to a system that is not\nmonitored to be parsed and decrypted. This rule identifies the creation or modification of a medium-size registry hive\nfile on an SMB share, which may indicate this kind of exfiltration attempt.\n\n#### Possible investigation steps\n\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Confirm whether the account owner is aware of the operation.\n- Examine command line logs for the period when the alert was triggered.\n- Capture the registry file(s) to scope the compromised credentials in an eventual Incident Response.\n\n### False positive analysis\n\n- Administrators can export registry hives for backup purposes. Check whether the user should be performing this kind of\nactivity and is aware of it.\n\n### Related rules\n\n- Credential Acquisition via Registry Hive Dumping - a7e7bfa3-088e-4f13-b29e-3986e0e756b8\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Scope compromised credentials and disable associated accounts.\n- Reset passwords for compromised accounts.\n- Reimage the host operating system and restore compromised files to clean versions.\n",
|
||||
"query": "file where event.type == \"creation\" and\n /* regf file header */\n file.Ext.header_bytes : \"72656766*\" and file.size >= 30000 and\n process.pid == 4 and user.id : \"s-1-5-21*\"\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "a4c7473a-5cb4-4bc1-9d06-e4a75adbc494",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Potential Remote Credential Access via Registry",
|
||||
"note": "## Config\n\nThis rule uses Elastic Endpoint file creation and System Integration events for correlation. Both data should be\ncollected from the host for this detection to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Potential Remote Credential Access via Registry\n\nDumping registry hives is a common way to access credential information. Some hives store credential material, \nsuch as the SAM hive, which stores locally cached credentials (SAM Secrets), and the SECURITY hive, which stores domain\ncached credentials (LSA secrets). Dumping these hives in combination with the SYSTEM hive enables the attacker to\ndecrypt these secrets.\n\nAttackers can use tools like secretsdump.py or CrackMapExec to dump the registry hives remotely, and use dumped\ncredentials to access other systems in the domain.\n\n#### Possible investigation steps\n\n- Identify the target host role, involved account, and source host.\n- Determine the privileges assigned to any compromised accounts.\n- Investigate other alerts related to the involved user and source host in the last 48 hours.\n- Scope potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target\nhost.\n\n### False positive analysis\n\n- False positives for this rule are unlikely. Any activity that triggered the alert and is not inherently malicious must\nbe monitored by the security team.\n\n### Related rules\n\n- Credential Acquisition via Registry Hive Dumping - a7e7bfa3-088e-4f13-b29e-3986e0e756b8\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Scope compromised credentials and disable the accounts.\n- Reset the passwords of compromised accounts.\n- Determine if other hosts were compromised.\n\n## Config\n\nThis rule uses Elastic Endpoint file creation and System Integration events for correlation. Both data should be\ncollected from the host for this detection to work.\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "sequence by host.id, user.id with maxspan=1m\n [authentication where\n event.outcome == \"success\" and\n winlog.logon.type == \"Network\" and not user.name == \"ANONYMOUS LOGON\" and\n not user.domain == \"NT AUTHORITY\" and source.ip != \"127.0.0.1\" and source.ip !=\"::1\"]\n [file where event.action == \"creation\" and process.name : \"svchost.exe\" and\n file.Ext.header_bytes : \"72656766*\" and user.id : \"S-1-5-21-*\" and file.size >= 30000]\n",
|
||||
"references": [
|
||||
"https://github.com/SecureAuthCorp/impacket/blob/master/examples/secretsdump.py"
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "kuery",
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "kuery",
|
||||
|
|
@ -52,5 +51,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 1
|
||||
"version": 2
|
||||
}
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
"language": "kuery",
|
||||
"license": "Elastic License v2",
|
||||
"name": "User account exposed to Kerberoasting",
|
||||
"note": "## Triage and analysis.\n\n### Investigating User account exposed to Kerberoasting\n\nService principal names (SPNs) is the name by which a Kerberos client uniquely identifies an instance of a service for a\ngiven Kerberos target computer. \n\nBy default, only computer accounts have SPNs, and there is no significant risk about this, as machine accounts have a\ndefault domain policy that configures these accounts to rotate their passwords every 30 days, and the password is\ncompound of 120 random characters, making them not to be vulnerable to Kerberoasting.\n\nSo, a user account with an SPN assigned is considered a Service Account, making it available to be accessed by the\nentire domain. If any user in the directory requests a TGS, the domain controller will encrypt it with the secret key of\nthe account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as\nthe human-defined password is more likely to be less complex.\n\nFor scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA)\nfeature, which ensures that the account password is robust and changed regularly and automatically. More information can\nbe found [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview).\n\nAttackers can also perform \"Targeted Kerberoasting\", which consists of adding fake SPNs to user accounts that they have\nwrite privileges to, making them potentially vulnerable to Kerberoasting.\n\n#### Possible investigation steps:\n\n- Identify the account that performed the action.\n- Check whether this user should be doing this kind of activity.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate if the target account is a member of Privileged groups (Domain Admins, Enterprise Admins, etc).\n- Investigate if tickets have been requested for the target account.\n- Investigate other alerts related to the user in the last 48 hours.\n\n### False Positive Analysis\n\n- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The\nsecurity team should map and monitor any potential B-TP (Benign True Positive), especially if the account is privileged.\nDomain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same\nsecurity standards (Long, complex, random passwords that change frequently) as computer accounts, exposing them to\ncredential cracking attacks (Kerberoasting, brute force, etc.).\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage\n- Reset the password of the involved accounts. Priority should be given to privileged accounts.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n\n## Config\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration > \nPolicies > \nWindows Settings > \nSecurity Settings > \nAdvanced Audit Policies Configuration > \nAudit Policies > \nDS Access > \nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\nAs this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success\n```\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating User account exposed to Kerberoasting\n\nService Principal Names (SPNs) are names by which Kerberos clients uniquely identify service instances for Kerberos target\ncomputers.\n\nBy default, only computer accounts have SPNs, which creates no significant risk, since machine accounts have a default\ndomain policy that rotates their passwords every 30 days, and the password is composed of 120 random characters, making\nthem invulnerable to Kerberoasting.\n\nA user account with an SPN assigned is considered a Service Account, and is accessible to the entire domain. If any\nuser in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret\nkey of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this\ninformation, as the human-defined password is likely to be less complex.\n\nFor scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA)\nfeature, which ensures that account passwords are robust and changed regularly and automatically. More information can\nbe found [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview).\n\nAttackers can also perform \"Targeted Kerberoasting\", which consists of adding fake SPNs to user accounts that they have\nwrite privileges to, making them potentially vulnerable to Kerberoasting.\n\n#### Possible investigation steps\n\n- Identify the account that performed the action.\n- Check whether this user should be doing this kind of activity.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate if the target account is a member of privileged groups (Domain Admins, Enterprise Admins, etc.).\n- Investigate if tickets have been requested for the target account.\n- Investigate other alerts related to the user in the last 48 hours.\n\n### False positive analysis\n\n- The use of user accounts as service accounts is a bad security practice and should not be allowed in the domain. The\nsecurity team should map and monitor any potential benign true positive (B-TP), especially if the account is privileged.\nDomain Administrators that define this kind of setting can put the domain at risk as user accounts don't have the same\nsecurity standards as computer accounts (which have long, complex, random passwords that change frequently), exposing\nthem to credential cracking attacks (Kerberoasting, brute force, etc.).\n\n### Response and remediation \n\n- Initiate the incident response process based on the outcome of the triage.\n- Reset the passwords of affected accounts, prioritizing privileged accounts.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n\n## Config\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\nAs this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success\n```\n",
|
||||
"query": "event.action:\"Directory Service Changes\" and event.code:5136 and winlog.event_data.ObjectClass:\"user\" \nand winlog.event_data.AttributeLDAPDisplayName:\"servicePrincipalName\"\n",
|
||||
"references": [
|
||||
"https://www.thehacker.recipes/ad/movement/access-controls/targeted-kerberoasting",
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Symbolic Link to Shadow Copy Created",
|
||||
"note": "## Triage and analysis.\n\n### Investigating\n\nShadow copies are backups or snapshots of an endpoints files or volumes at the time of being in use. Adversaries may attempt to discover and create symbolic links to these shadow copies in order to copy sensitive information offline. If Active Directory (AD) is in use, often the ntds.dit file is a target as it contains password hashes but an offline copy is needed to extract these hashes and potentially conduct lateral movement.\n\n#### Possible investigation steps:\n\n- Determine if a volume shadow copy was recently created on this endpoint.\n- Review priviledges of the end user as this requires administrative access.\n- Verify ntds.dit file was successfully copied and the location.\n- Investigate for registry SYSTEM file copies made recently or saved via Reg.exe.\n- Investigate recent deletions of volume shadow copies.\n- Identify other files potentially copied from volume shadow copy paths directly.\n\n### False Positive Analysis\n\n- There should be very little false positive triggers with this rule.\n\n### Related Rules\n- NTDS or SAM Database File Copied - 3bc6deaa-fbd4-433a-ae21-3e892f95624f\n\n### Response and Remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- In case specific credentials were compromised:\n - Reset the password for the accounts\n- Locate and remove static files copied from volume shadow copies.\n- Command-Line tool mklink should require administrative access by default unless in developer mode.\n\n## Config\n\nEnsure advanced audit policies for Windows are enabled, specifically\nObject Access policies [Event ID 4656](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656) (Handle to an Object was Requested)\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nSystem Audit Policies >\nObject Access >\nAudit File System (Success,Failure)\nAudit Handle Manipulation (Success,Failure)\n```\n\nThis event will only trigger if symbolic links are created from a new process spawning for cmd.exe or powershell.exe with the correct arguments.\nDirect access to a shell and calling symbolic link creation tools will not generate an event.\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Symbolic Link to Shadow Copy Created\n\nShadow copies are backups or snapshots of an endpoint's files or volumes while they are in use. Adversaries may attempt\nto discover and create symbolic links to these shadow copies in order to copy sensitive information offline. If Active\nDirectory (AD) is in use, often the ntds.dit file is a target as it contains password hashes, but an offline copy is\nneeded to extract these hashes and potentially conduct lateral movement.\n\n#### Possible investigation steps\n\n- Determine if a volume shadow copy was recently created on this endpoint.\n- Review priviledges of the end user as this requires administrative access.\n- Verify if the ntds.dit file was successfully copied and determine its copy destination.\n- Investigate for registry SYSTEM file copies made recently or saved via Reg.exe.\n- Investigate recent deletions of volume shadow copies.\n- Identify other files potentially copied from volume shadow copy paths directly.\n\n### False positive analysis\n\n- This rule should cause very few false positives. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Related rules \n\n- NTDS or SAM Database File Copied - 3bc6deaa-fbd4-433a-ae21-3e892f95624f\n\n### Response and remediation \n\n- Initiate the incident response process based on the outcome of the triage.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- If the entire domain or the `krbtgt` user was compromised:\n - Activate your incident response plan for total Active Directory compromise which should include, but not be limited\n to, a password reset (twice) of the `krbtgt` user.\n- Locate and remove static files copied from volume shadow copies.\n- Command-Line tool mklink should require administrative access by default unless in developer mode.\n\n## Config\n\nEnsure advanced audit policies for Windows are enabled, specifically:\nObject Access policies [Event ID 4656](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656) (Handle to an Object was Requested) \n \n``` \nComputer Configuration > \nPolicies > \nWindows Settings > \nSecurity Settings > \nAdvanced Audit Policies Configuration > \nSystem Audit Policies > \nObject Access > \nAudit File System (Success,Failure) \nAudit Handle Manipulation (Success,Failure) \n``` \n \nThis event will only trigger if symbolic links are created from a new process spawning cmd.exe or powershell.exe with the correct arguments. \nDirect access to a shell and calling symbolic link creation tools will not generate an event matching this rule. \n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\",\"process_created\") and \n process.pe.original_file_name in (\"Cmd.Exe\",\"PowerShell.EXE\") and \n \n /* Create Symbolic Link to Shadow Copies */\n process.args : (\"*mklink*\", \"*SymbolicLink*\") and process.command_line : (\"*HarddiskVolumeShadowCopy*\")\n",
|
||||
"references": [
|
||||
"https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink",
|
||||
|
|
|
|||
|
|
@ -61,5 +61,5 @@
|
|||
"timeline_title": "Comprehensive Process Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 10
|
||||
"version": 11
|
||||
}
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "kuery",
|
||||
|
|
@ -50,5 +49,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 2
|
||||
"version": 3
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Windows Defender Exclusions Added via PowerShell",
|
||||
"note": "## Triage and analysis\n\n### Investigating Windows Defender Exclusions\n\nMicrosoft Windows Defender is an anti-virus product built-in within Microsoft Windows. Since this software product is\nused to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration\nsettings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of the more\nnotable [examples](https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/) was observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defense to avoid detection.\n\n#### Possible investigation steps:\n- With this specific rule, it's completely possible to trigger detections on network administrative activity or benign users\nusing scripting and PowerShell to configure the different exclusions for Windows Defender. Therefore, it's important to\nidentify the source of the activity first and determine if there is any mal-intent behind the events.\n- The actual exclusion such as the process, the file or directory should be reviewed in order to determine the original\nintent behind the exclusion. Is the excluded file or process malicious in nature or is it related to software that needs\nto be legitimately allowlisted from Windows Defender?\n\n### False Positive Analysis\n- This rule has a higher chance to produce false positives based on the nature around configuring exclusions by possibly\na network administrator. In order to validate the activity further, review the specific exclusion and its intent. There\nare many legitimate reasons for exclusions, so it's important to gain context.\n\n### Related Rules\n- Windows Defender Disabled via Registry Modification\n- Disabling Windows Defender Security Settings via PowerShell\n\n### Response and Remediation\n- Since this is related to post-exploitation activity, take immediate action to review, investigate and\npotentially isolate further activity.\n- If further analysis showed malicious intent was behind the Defender exclusions, administrators should remove\nthe exclusion and ensure antimalware capability has not been disabled or deleted.\n- Exclusion lists for antimalware capabilities should always be routinely monitored for review.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Windows Defender Exclusions Added via PowerShell\n\nMicrosoft Windows Defender is an antivirus product built into Microsoft Windows. Since this software product is\nused to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration\nsettings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of\nthe more notable [examples](https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/)\nwas observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defender to avoid detection. \n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Examine the exclusion in order to determine the intent behind it.\n- Check for similar behavior in other hosts on the environment.\n- If the exclusion specifies a suspicious file, retrieve it and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This rule has a high chance to produce false positives due to how often network administrators legitimately configure\nexclusions. In order to validate the activity further, review the specific exclusion and its intent. There are many\nlegitimate reasons for exclusions, so it's important to gain context.\n\n### Related rules\n\n- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb\n- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the identified indicators of compromise (IoCs).\n - Remove and block malicious artifacts identified on the triage.\n- Exclusion lists for antimalware capabilities should always be routinely monitored for review.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type == \"start\" and\n (process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") or process.pe.original_file_name in (\"powershell.exe\", \"pwsh.dll\", \"powershell_ise.exe\")) and\n process.args : (\"*Add-MpPreference*\", \"*Set-MpPreference*\") and\n process.args : (\"*-Exclusion*\")\n",
|
||||
"references": [
|
||||
"https://www.bitdefender.com/files/News/CaseStudies/study/400/Bitdefender-PR-Whitepaper-MosaicLoader-creat5540-en-EN.pdf"
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "PowerShell Script Block Logging Disabled",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating PowerShell Script Block Logging Disabled\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making\nit available in various environments and creating an attractive way for attackers to execute code.\n\nPowerShell Script Block Logging is a feature of PowerShell that records the content of all script blocks that it\nprocesses, giving defenders visibility of PowerShell scripts and sequences of executed commands.\n\n#### Possible investigation steps\n\n- Identify the user account which performed the action.\n- Check whether the account should perform this kind of action.\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check whether it makes sense for the user to use PowerShell to complete its tasks.\n- Investigate if PowerShell scripts were run after logging was disabled.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Related rules\n\n- PowerShell Suspicious Discovery Related Windows API Functions - 61ac3638-40a3-44b2-855a-985636ca985e\n- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889\n- PowerShell Suspicious Script with Audio Capture Capabilities - 2f2f4939-0b34-40c2-a0a3-844eb7889f43\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- PowerShell Reflection Assembly Load - e26f042e-c590-4e82-8e05-41e81bd822ad\n- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a\n- PowerShell Suspicious Script with Screenshot Capabilities - 959a7353-1129-4aa7-9084-30746b256a70\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Quarantine the involved host to prevent further post-compromise behavior.\n- Review the implicated user account's privileges.\n- Configure AppLocker or equivalent software to restrict access to PowerShell for regular users.\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be configured (Enable).\n\nSteps to implement the logging policy with with Advanced Audit Configuration:\n\n```\nComputer Configuration > \nAdministrative Templates > \nWindows PowerShell > \nTurn on PowerShell Script Block Logging (Enable)\n```\n\nSteps to implement the logging policy via registry:\n\n```\nreg add \"hklm\\SOFTWARE\\Policies\\Microsoft\\Windows\\PowerShell\\ScriptBlockLogging\" /v EnableScriptBlockLogging /t REG_DWORD /d 1\n```\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "registry where event.type == \"change\" and\n registry.path : \n \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows\\\\PowerShell\\\\ScriptBlockLogging\\\\EnableScriptBlockLogging\"\n and registry.data.strings : (\"0\", \"0x00000000\")\n",
|
||||
"references": [
|
||||
"https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.PowerShell::EnableScriptBlockLogging"
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Disable Windows Firewall Rules via Netsh",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Disable Windows Firewall Rules via Netsh\n\nThe Windows Defender Firewall is a native component which provides host-based, two-way network traffic filtering for a\ndevice, and blocks unauthorized network traffic flowing into or out of the local device.\n\nAttackers can disable firewall rules which are intended to prevent lateral movement and command and control traffic to\nenable their operations.\n\nThis rule identifies patterns related to disabling firewall rules using the `netsh.exe` utility.\n\n#### Possible investigation steps\n\n- Identify the user account which performed the action and whether it should perform this kind of action.\n- Contact the user to check if they are aware of the operation.\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Analyze the executed command to determine what it allowed.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Check whether the user is legitimately performing this kind of activity.\n- Assess the need to disable the modification of the rule, and whether these actions expose the environment to\nunnecessary risks.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Quarantine the involved host to prevent further post-compromise behavior.\n- Evaluate exceptions that can be added to the firewall rule and re-enable the rule.\n- Review the implicated account's privileges.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n process.name : \"netsh.exe\" and\n (process.args : \"disable\" and process.args : \"firewall\" and process.args : \"set\") or\n (process.args : \"advfirewall\" and process.args : \"off\" and process.args : \"state\")\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "4b438734-3793-4fda-bd42-ceeada0be8f9",
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@
|
|||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote Desktop Enabled in Windows Firewall",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"name": "Remote Desktop Enabled in Windows Firewall by Netsh",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote Desktop Enabled in Windows Firewall by Netsh\n\nMicrosoft Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol that enables remote connections to other\ncomputers, typically over TCP port 3389.\n\nAttackers can use RDP to conduct their actions interactively. Ransomware operators frequently use RDP to access\nvictim servers, often using privileged accounts.\n\nThis rule detects the creation of a Windows Firewall inbound rule that would allow inbound RDP traffic using the\n`netsh.exe` utility.\n\n#### Possible investigation steps\n\n- Identify the user account which performed the action and whether it should perform this kind of action.\n- Contact the user to check if they are aware of the operation.\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check whether it makes sense to enable RDP to this host, given its role in the environment.\n- Check if the host is directly exposed to the internet.\n- Check whether privileged accounts accessed the host shortly after the modification.\n\n### False positive analysis\n\n- The `netsh.exe` utility can be used legitimately. Check whether the user should be performing this kind of activity, whether the user is aware\nof it, whether RDP should be open, and whether the action exposes the environment to unnecessary risks.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If RDP is needed, make sure to secure it:\n - Allowlist RDP traffic to specific trusted hosts.\n - Restrict RDP logins to authorized non-administrator accounts, where possible.\n- Quarantine the implicated host to prevent further post-compromise behavior.\n- Review the implicated account's privileges.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n (process.name : \"netsh.exe\" or process.pe.original_file_name == \"netsh.exe\") and\n process.args : (\"localport=3389\", \"RemoteDesktop\", \"group=\\\"remote desktop\\\"\") and\n process.args : (\"action=allow\", \"enable=Yes\", \"enable\")\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "074464f9-f30d-4029-8c03-0ed237fffec7",
|
||||
|
|
|
|||
|
|
@ -48,5 +48,5 @@
|
|||
"timeline_title": "Comprehensive Process Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 4
|
||||
"version": 5
|
||||
}
|
||||
|
|
|
|||
|
|
@ -52,5 +52,5 @@
|
|||
"timeline_title": "Comprehensive Process Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 11
|
||||
"version": 12
|
||||
}
|
||||
|
|
|
|||
|
|
@ -40,5 +40,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 7
|
||||
"version": 8
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Signed Proxy Execution via MS WorkFolders",
|
||||
"note": "## Triage and analysis\n\n### Investigating control.exe Execution via Work Folders in Current Working Directory\n\nWork Folders is a role service for file servers running Windows Server that provides a consistent way for users to access their work files from their PCs and devices. This allows for users to store work files and access them from anywhere. When called, Work Folders will automatically execute any Portable Executable (PE) named `control.exe` as an argument before accessing the synced share.\n\nUsing Work Folders to execute a masqueraded control.exe could allow an adversary to bypass application controls and increase privileges.\n\n#### Possible investigation steps:\n- Investigate the process tree starting with parent process WorkFolders.exe and child process control.exe to determine if other child processes spawned during execution.\n- Trace the activity related to the `control.exe` binary to determine continued intrusion activity on the host.\n- Examine the location of the WorkFolders.exe binary to determine if it was copied to the location of the control.exe binary as it resides in the System32 directory by default.\n- Review the control.exe binary executed with Work Folders to determine maliciousness such as additional host activity or network traffic generated\n- Determine if control.exe was synced to sync share, indicating potential lateral movement.\n- Review where control.exe originated from on the host in terms of delivery such as email, web download or written to disk from a seperate binary.\n\n### False Positive Analysis\n- Windows Work Folders are used legitimately by end users and administrators for file sharing and syncing but not in the instance where a suspicious `control.exe` is passed as an argument.\n\n### Response and Remediation\n- If identified as a compromise, engage incident response processes and policies.\n- Take immediate action to review, investigate and potentially isolate activity to prevent further post-compromise\nbehavior.\n- Review the Work Folders synced share to determine if the 'control.exe' was shared and if so remove it.\n- If no lateral movement was identified during investigation, take the effected host offline if possible and remove the control.exe binary as well as any additional artifacts identified during investigation.\n- Review integrating Windows Information Protection (WIP) to enforce data protection by encrypting the data on PCs using Work Folders.\n- Confirm with user whether this was expected or not and reset their password.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Signed Proxy Execution via MS WorkFolders\n\nWork Folders is a role service for file servers running Windows Server that provides a consistent way for users to access\ntheir work files from their PCs and devices. This allows users to store work files and access them from anywhere. When\ncalled, Work Folders will automatically execute any Portable Executable (PE) named `control.exe` as an argument before\naccessing the synced share.\n\nUsing Work Folders to execute a masqueraded control.exe could allow an adversary to bypass application controls and\nincrease privileges.\n \n#### Possible investigation steps\n\n- Investigate the process tree starting with parent process WorkFolders.exe and child process control.exe to determine\nif other child processes spawned during execution.\n- Trace the activity related to the `control.exe` binary to identify any continuing intrusion activity on the host.\n- Examine the location of the WorkFolders.exe binary to determine if it was copied to the location of the control.exe\nbinary. It resides in the System32 directory by default.\n- Review the control.exe binary executed with Work Folders to determine maliciousness such as additional host activity\nor network traffic.\n- Determine if control.exe was synced to sync share, indicating potential lateral movement.\n- Review how control.exe was originally delivered on the host, such as emailed, downloaded from the web, or written to\ndisk from a separate binary.\n \n### False positive analysis \n\n- Windows Work Folders are used legitimately by end users and administrators for file sharing and syncing but not in the\ninstance where a suspicious `control.exe` is passed as an argument.\n\n### Response and remediation \n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Review the Work Folders synced share to determine if the 'control.exe' was shared and if so remove it.\n- If no lateral movement was identified during investigation, take the effected host offline if possible and remove the\ncontrol.exe binary as well as any additional artifacts identified during investigation.\n- Review integrating Windows Information Protection (WIP) to enforce data protection by encrypting the data on PCs using\nWork Folders.\n- Confirm with the user whether this was expected or not, and reset their password.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\",\"process_started\")\n and process.name : \"control.exe\" and process.parent.name : \"WorkFolders.exe\"\n and not process.executable : (\"?:\\\\Windows\\\\System32\\\\control.exe\", \"?:\\\\Windows\\\\SysWOW64\\\\control.exe\")\n",
|
||||
"references": [
|
||||
"https://docs.microsoft.com/en-us/windows-server/storage/work-folders/work-folders-overview",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "AdFind Command Activity",
|
||||
"note": "## Triage and analysis\n\n### Investigating AdFind Command Activity\n\n[AdFind](http://www.joeware.net/freetools/tools/adfind/) is a freely available command-line tool used to retrieve information from\nActive Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways\nthey are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and\nunderstand subnets and domain information. There are many [examples](https://thedfirreport.com/category/adfind/)\nobserved where this tool has been adopted by ransomware and criminal groups and used in compromises.\n\n#### Possible investigation steps:\n- `AdFind` is a legitimate Active Directory enumeration tool used by network administrators, it's important to understand\nthe source of the activity. This could involve identifying the account using `AdFind` and determining based on the command-lines\nwhat information was retrieved, then further determining if these actions are in scope of that user's traditional responsibilities.\n- In multiple public references, `AdFind` is leveraged after initial access is achieved. Review previous activity on impacted\nmachines for suspicious indicators such as previous anti-virus/EDR alerts, phishing emails received, or network traffic\nto suspicious infrastructure.\n\n### False Positive Analysis\n- This rule has a high chance to produce false positives as it is a legitimate tool used by network administrators. One\noption could be allowlisting specific users or groups who use the tool as part of their daily responsibilities. This can\nbe done by leveraging the exception workflow in the Kibana Security App or Elasticsearch API to tune this rule to your environment.\n- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in\nisolation, so reviewing previous logs/activity from impacted machines can be very telling.\n\n### Related Rules\n- Windows Network Enumeration\n- Enumeration of Administrator Accounts\n- Enumeration Command Spawned via WMIPrvSE\n\n### Response and Remediation\n- Take immediate action to validate activity, investigate and potentially isolate activity to prevent further\npost-compromise behavior.\n- It's important to understand that `AdFind` is an Active Directory enumeration tool and can be used for malicious or legitimate\npurposes, so understanding the intent behind the activity will help determine the appropropriate response.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating AdFind Command Activity\n\n[AdFind](http://www.joeware.net/freetools/tools/adfind/) is a freely available command-line tool used to retrieve information\nfrom Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same\nways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects\nand understand subnets and domain information. There are many [examples](https://thedfirreport.com/category/adfind/) of\nthis tool being adopted by ransomware and criminal groups and used in compromises.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Examine the command line to determine what information was retrieved by the tool.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n\n### False positive analysis\n\n- This rule has a high chance to produce false positives as it is a legitimate tool used by network administrators. One\noption could be allowlisting specific users or groups who use the tool as part of their daily responsibilities. This can\nbe done by leveraging the exception workflow in the Kibana Security App or Elasticsearch API to tune this rule to your environment.\n- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in\nisolation, so reviewing previous logs/activity from impacted machines can be very telling.\n\n### Related rules\n\n- Windows Network Enumeration - 7b8bfc26-81d2-435e-965c-d722ee397ef1\n- Enumeration of Administrator Accounts - 871ea072-1b71-4def-b016-6278b505138d\n- Enumeration Command Spawned via WMIPrvSE - 770e0c4d-b998-41e5-a62e-c7901fd7f470\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Determine the initial infection vector.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and \n (process.name : \"AdFind.exe\" or process.pe.original_file_name == \"AdFind.exe\") and \n process.args : (\"objectcategory=computer\", \"(objectcategory=computer)\", \n \"objectcategory=person\", \"(objectcategory=person)\",\n \"objectcategory=subnet\", \"(objectcategory=subnet)\",\n \"objectcategory=group\", \"(objectcategory=group)\", \n \"objectcategory=organizationalunit\", \"(objectcategory=organizationalunit)\",\n \"objectcategory=attributeschema\", \"(objectcategory=attributeschema)\",\n \"domainlist\", \"dcmodes\", \"adinfo\", \"dclist\", \"computers_pwnotreqd\", \"trustdmp\")\n",
|
||||
"references": [
|
||||
"http://www.joeware.net/freetools/tools/adfind/",
|
||||
|
|
|
|||
|
|
@ -11,9 +11,9 @@
|
|||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Net command via SYSTEM account",
|
||||
"name": "Account Discovery Command via SYSTEM Account",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and \n (?process.Ext.token.integrity_level_name : \"System\" or\n ?winlog.event_data.IntegrityLevel : \"System\") and\n process.name : \"whoami.exe\" or\n (process.name : \"net1.exe\" and not process.parent.name : \"net.exe\")\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and \n (?process.Ext.token.integrity_level_name : \"System\" or\n ?winlog.event_data.IntegrityLevel : \"System\") and\n (process.name : \"whoami.exe\" or\n (process.name : \"net1.exe\" and not process.parent.name : \"net.exe\"))\n",
|
||||
"risk_score": 21,
|
||||
"rule_id": "2856446a-34e6-435b-9fb5-f8f040bfa7ed",
|
||||
"severity": "low",
|
||||
|
|
@ -43,5 +43,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 10
|
||||
"version": 11
|
||||
}
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*"
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
|
|
|
|||
|
|
@ -33,5 +33,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -45,5 +45,5 @@
|
|||
"timeline_title": "Comprehensive Process Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 9
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -33,5 +33,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -33,5 +33,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 9
|
||||
"version": 11
|
||||
}
|
||||
|
|
|
|||
|
|
@ -30,5 +30,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 9
|
||||
"version": 11
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Deleting Backup Catalogs with Wbadmin",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Deleting Backup Catalogs with Wbadmin\n\nWindows Server Backup stores the details about your backups (what volumes are backed up and where the backups are\nlocated) in a file called a backup catalog, which ransomware victims can use to recover corrupted backup files.\nDeleting these files is a common step in threat actor playbooks.\n\nThis rule identifies the deletion of the backup catalog using the `wbadmin.exe` utility.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Confirm whether the account owner is aware of the operation.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Check if any files on the host machine have been encrypted.\n\n### False positive analysis\n\n- Administrators can use this command to delete corrupted catalogs, but overall the activity is unlikely to be legitimate.\n\n### Related rules\n\n- Third-party Backup Files Deleted via Unexpected Process - 11ea6bec-ebde-4d71-a8e9-784948f8e3e9\n- Volume Shadow Copy Deleted or Resized via VssAdmin - b5ea4bfe-a1b2-421f-9d47-22a75a6f2921\n- Volume Shadow Copy Deletion via PowerShell - d99a037b-c8e2-47a5-97b9-170d076827c4\n- Volume Shadow Copy Deletion via WMIC - dc9c1f74-dac3-48e3-b47f-eb79db358f57\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent destructive behavior, which is commonly associated with this activity.\n- Reset the password of the involved accounts.\n- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look\nfor ransomware preparation and execution activities.\n- If any backups were affected:\n - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n (process.name : \"wbadmin.exe\" or process.pe.original_file_name == \"WBADMIN.EXE\") and\n process.args : \"catalog\" and process.args : \"delete\"\n",
|
||||
"risk_score": 21,
|
||||
"rule_id": "581add16-df76-42bb-af8e-c979bfb39a59",
|
||||
|
|
|
|||
|
|
@ -58,5 +58,5 @@
|
|||
"timeline_title": "Comprehensive File Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 7
|
||||
"version": 8
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Modification of Boot Configuration",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Modification of Boot Configuration\n\nBoot entry parameters, or boot parameters, are optional, system-specific settings that represent configuration options.\nThese are stored in a boot configuration data (BCD) store, and administrators can use utilities like `bcdedit.exe` to\nconfigure these.\n\nThis rule identifies the usage of `bcdedit.exe` to:\n\n- Disable Windows Error Recovery (recoveryenabled).\n- Ignore errors if there is a failed boot, failed shutdown, or failed checkpoint (bootstatuspolicy ignoreallfailures).\n\nThese are common steps in destructive attacks by adversaries leveraging ransomware.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Confirm whether the account owner is aware of the operation.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Check if any files on the host machine have been encrypted.\n\n### False positive analysis\n\n- The usage of these options is not inherently malicious. Administrators can modify these configurations to force a\nmachine to boot for troubleshooting or data recovery purposes.\n\n### Related rules\n\n- Deleting Backup Catalogs with Wbadmin - 581add16-df76-42bb-af8e-c979bfb39a59\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent destructive behavior, which is commonly associated with this activity.\n- Reset the password of the involved accounts.\n- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look\nfor ransomware preparation and execution activities.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n (process.name : \"bcdedit.exe\" or process.pe.original_file_name == \"bcdedit.exe\") and\n (process.args : \"/set\" and process.args : \"bootstatuspolicy\" and process.args : \"ignoreallfailures\") or\n (process.args : \"no\" and process.args : \"recoveryenabled\")\n",
|
||||
"risk_score": 21,
|
||||
"rule_id": "69c251fb-a5d6-4035-b5ec-40438bd829ff",
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
"author": [
|
||||
"Elastic"
|
||||
],
|
||||
"description": "Identifies the deletion of an Amazon Relational Database Service (RDS) Aurora database cluster or global database cluster.",
|
||||
"description": "Identifies the deletion of an Amazon Relational Database Service (RDS) Aurora database cluster, global database cluster, or database instance.",
|
||||
"false_positives": [
|
||||
"Clusters may be deleted by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Cluster deletions by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule."
|
||||
"Clusters or instances may be deleted by a system administrator. Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Cluster or instance deletions by unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule."
|
||||
],
|
||||
"from": "now-60m",
|
||||
"index": [
|
||||
|
|
@ -14,14 +14,16 @@
|
|||
"interval": "10m",
|
||||
"language": "kuery",
|
||||
"license": "Elastic License v2",
|
||||
"name": "AWS RDS Cluster Deletion",
|
||||
"name": "AWS Deletion of RDS Instance or Cluster",
|
||||
"note": "## Config\n\nThe AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
|
||||
"query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(DeleteDBCluster or DeleteGlobalCluster) and event.outcome:success\n",
|
||||
"query": "event.dataset:aws.cloudtrail and event.provider:rds.amazonaws.com and event.action:(DeleteDBCluster or DeleteGlobalCluster or DeleteDBInstance) \nand event.outcome:success\n",
|
||||
"references": [
|
||||
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-db-cluster.html",
|
||||
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html",
|
||||
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-global-cluster.html",
|
||||
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html"
|
||||
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteGlobalCluster.html",
|
||||
"https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/delete-db-instance.html",
|
||||
"https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html"
|
||||
],
|
||||
"risk_score": 47,
|
||||
"rule_id": "9055ece6-2689-4224-a0e0-b04881e1f8ad",
|
||||
|
|
@ -53,5 +55,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 6
|
||||
"version": 7
|
||||
}
|
||||
|
|
@ -12,6 +12,7 @@
|
|||
"language": "kuery",
|
||||
"license": "Elastic License v2",
|
||||
"name": "High Number of Process and/or Service Terminations",
|
||||
"note": "## Triage and analysis\n\n### Investigating High Number of Process and/or Service Terminations\n\nAttackers can stop services and kill processes for a variety of purposes. For example, they can stop services associated\nwith business applications and databases to release the lock on files used by these applications so they may be encrypted,\nor stop security and backup solutions, etc.\n\nThis rule identifies a high number (10) of service and/or process terminations (stop, delete, or suspend) from the same\nhost within a short time period.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Confirm whether the account owner is aware of the operation, and why it was performed.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Check if any files on the host machine have been encrypted.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further destructive behavior, which is commonly associated with this activity.\n- Reset the password of the involved accounts.\n- Reimage the host operating system or restore it to the operational state.\n- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look\nfor ransomware preparation and execution activities.\n",
|
||||
"query": "event.category:process and event.type:start and process.name:(net.exe or sc.exe or taskkill.exe) and\n process.args:(stop or pause or delete or \"/PID\" or \"/IM\" or \"/T\" or \"/F\" or \"/t\" or \"/f\" or \"/im\" or \"/pid\")\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "035889c4-2686-4583-a7df-67f89c292f2c",
|
||||
|
|
@ -47,5 +48,5 @@
|
|||
"value": 10
|
||||
},
|
||||
"type": "threshold",
|
||||
"version": 3
|
||||
"version": 4
|
||||
}
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ import rule147 from './defense_evasion_waf_acl_deletion.json';
|
|||
import rule148 from './impact_attempt_to_revoke_okta_api_token.json';
|
||||
import rule149 from './impact_iam_group_deletion.json';
|
||||
import rule150 from './impact_possible_okta_dos_attack.json';
|
||||
import rule151 from './impact_rds_cluster_deletion.json';
|
||||
import rule151 from './impact_rds_instance_cluster_deletion.json';
|
||||
import rule152 from './initial_access_suspicious_activity_reported_by_okta_user.json';
|
||||
import rule153 from './okta_attempt_to_deactivate_okta_policy.json';
|
||||
import rule154 from './okta_attempt_to_deactivate_okta_policy_rule.json';
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Windows Script Executing PowerShell",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Windows Script Executing PowerShell\n\nThe Windows Script Host (WSH) is an Windows automation technology, which is ideal for non-interactive scripting needs,\nsuch as logon scripting, administrative scripting, and machine automation.\n\nAttackers commonly use WSH scripts as their initial access method, acting like droppers for second stage payloads, but\ncan also use them to download tools and utilities needed to accomplish their goals.\n\nThis rule looks for the spawn of the `powershell.exe` process with `cscript.exe` or `wscript.exe` as its parent process.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Investigate commands executed by the spawned PowerShell process.\n- Retrieve the script file(s) involved:\n - Use a sandboxed malware analysis system to perform analysis.\n - Observe attempts to contact external domains and addresses.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n - Manually analyze the script to determine if malicious capabilities are present.\n- Determine how the script file was delivered (email attachment, dropped by other processes, etc.).\n- Investigate other alerts related to the user/host in the last 48 hours.\n\n### False positive analysis\n\n- The usage of these script engines by regular users is unlikely. In the case of authorized benign true positives\n(B-TPs), exceptions can be added.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the identified indicators of compromise (IoCs).\n- Remove and block malicious artifacts identified on the triage.\n- If the malicious file was delivered via phishing:\n - Block the email sender from sending future emails.\n - Block the malicious web pages.\n - Remove emails from the sender from mailboxes.\n- Reimage the host operating system and restore compromised files to clean versions.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n process.parent.name : (\"cscript.exe\", \"wscript.exe\") and process.name : \"powershell.exe\"\n",
|
||||
"risk_score": 21,
|
||||
"rule_id": "f545ff26-3c94-4fd0-bd33-3c7f95a3a0fc",
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
"language": "kuery",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Abnormally Large DNS Response",
|
||||
"note": "## Triage and analysis\n\n### Investigating Large DNS Responses\nDetection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS\nserver. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350)\nalso known as [SigRed](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020.\n\n#### Possible investigation steps:\n- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate\nthe source of the incoming traffic and determine if this activity has been observed previously within an environment.\n- Activity can be further investigated and validated by reviewing available corresponding Intrusion Detection Signatures (IDS) alerts associated with activity.\n- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data.\n- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale Internet vulnerability scanning.\n- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment.\n\n#### False Positive Analysis\n- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes\nand related to legitimate behavior. In packet capture files received by the [SANS Internet Storm Center](https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/), byte responses\nwere all observed as greater than 65k bytes.\n- This activity can be triggered by compliance/vulnerability scanning or compromise assessment, it's\nimportant to determine the source of the activity and potentially allowlist the source host.\n\n\n### Related Rules\n- Unusual Child Process of dns.exe\n- Unusual File Modification by dns.exe\n\n### Response and Remediation\n- Review and implement the above detection logic within your environment using technology such as Endpoint security, Winlogbeat, Packetbeat, or network security monitoring (NSM) platforms such as Zeek or Suricata.\n- Ensure that you have deployed the latest Microsoft [Security Update](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350) (Monthly Rollup or Security Only) and restart the\npatched machines. If unable to patch immediately: Microsoft [released](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability) a registry-based workaround that doesn\u2019t require a\nrestart. This can be used as a temporary solution before the patch is applied.\n- Maintain backups of your critical systems to aid in quick recovery.\n- Perform routine vulnerability scans of your systems, monitor [CISA advisories](https://us-cert.cisa.gov/ncas/current-activity) and patch identified vulnerabilities.\n- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Abnormally Large DNS Response\n\nDetection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS\nserver. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350)\nalso known as [SigRed](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020.\n\n#### Possible investigation steps\n\n- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate\nthe source of the incoming traffic and determine if this activity has been observed previously within an environment.\n- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts.\n- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as\nZeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data. \n- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale\ninternet vulnerability scanning.\n- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment.\n\n#### False positive analysis\n\n- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes\nand related to legitimate behavior. In packet capture files received by the [SANS Internet Storm Center](https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/), byte responses\nwere all observed as greater than 65k bytes.\n- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to\ndetermine the source of the activity and potentially allowlist the source host.\n\n### Related rules\n\n- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45\n- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Ensure that you have deployed the latest Microsoft [Security Update](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350)\n(Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft [released](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability)\na registry-based workaround that doesn\u2019t require a restart. This can be used as a temporary solution before the patch is applied. \n- Maintain backups of your critical systems to aid in quick recovery.\n- Perform routine vulnerability scans of your systems, monitor [CISA advisories](https://us-cert.cisa.gov/ncas/current-activity) and patch identified vulnerabilities.\n- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior.\n",
|
||||
"query": "event.category:(network or network_traffic) and destination.port:53 and\n (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes > 60000\n",
|
||||
"references": [
|
||||
"https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "RDP Enabled via Registry",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating RDP Enabled via Registry\n\nMicrosoft Remote Desktop Protocol (RDP) is a proprietary Microsoft protocol that enables remote connections to other\ncomputers, typically over TCP port 3389.\n\nAttackers can use RDP to conduct their actions interactively. Ransomware operators frequently use RDP to access\nvictim servers, often using privileged accounts.\n\nThis rule detects modification of the fDenyTSConnections registry key to the value `0`, which specifies that remote\ndesktop connections are enabled. Attackers can abuse remote registry, use psexec, etc., to enable RDP and move laterally.\n\n#### Possible investigation steps\n\n- Identify the user account which performed the action and whether it should perform this kind of action.\n- Contact the user to check if they are aware of the operation.\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check whether it makes sense to enable RDP to this host, given its role in the environment.\n- Check if the host is directly exposed to the internet.\n- Check whether privileged accounts accessed the host shortly after the modification.\n- Review network events within a short timespan of this alert for incoming RDP connection attempts.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Check whether the user should be performing this kind of activity, whether they are aware\nof it, whether RDP should be open, and whether the action exposes the environment to unnecessary risks.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If RDP is needed, make sure to secure it using firewall rules:\n - Allowlist RDP traffic to specific trusted hosts.\n - Restrict RDP logins to authorized non-administrator accounts, where possible.\n- Quarantine the involved host to prevent further post-compromise behavior.\n- Review the implicated account's privileges.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "registry where event.type in (\"creation\", \"change\") and\n registry.path : \"HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Terminal Server\\\\fDenyTSConnections\" and\n registry.data.strings : (\"0\", \"0x00000000\") and not (process.name : \"svchost.exe\" and user.domain == \"NT AUTHORITY\") and\n not process.executable : \"C:\\\\Windows\\\\System32\\\\SystemPropertiesRemote.exe\"\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "58aa72ca-d968-4f34-b9f7-bea51d75eb50",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Remote Scheduled Task Creation",
|
||||
"note": "## Triage and analysis\n\n### Investigating Creation of Remote Scheduled Tasks\n\n[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great\nmechanism for persistence and program execution. These features can\nbe used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries.\nWhen investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the\noriginal intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind\nof network administrator work. One objective for these alerts is to understand the configured action within the scheduled\ntask. This is captured within the registry event data for this rule and can be base64 decoded to view the value.\n\n#### Possible investigation steps:\n- Review the base64 encoded tasks actions registry value to investigate the task configured action.\n- Determine if task is related to legitimate or benign behavior based on the corresponding process or program tied to the\nscheduled task.\n- Further examination should include both the source and target machines where host-based artifacts and network logs\nshould be reviewed further around the time window of the creation of the scheduled task.\n\n### False Positive Analysis\n- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature\nwithin Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to\nfurther understand the source of the activity and determine the intent based on the scheduled task contents.\n\n### Related Rules\n- Service Command Lateral Movement\n- Remotely Started Services via RPC\n\n### Response and Remediation\n- This behavior represents post-exploitation actions such as persistence or lateral movement, immediately review and\ninvestigate the activity and potentially isolate involved machines to prevent further post-compromise\nbehavior.\n- Remove scheduled task and any other related artifacts to the activity.\n- Review privileged account management and user account management settings such as implementing GPO policies to further\nrestrict activity or configure settings that only allow Administrators to create remote scheduled tasks.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Remote Scheduled Task Creation\n\n[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism\nfor persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at\nthe same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the\nfirst steps should be to determine the original intent behind the configuration and to verify if the activity is tied to\nbenign behavior such as software installation or any kind of network administrator work. One objective for these alerts\nis to understand the configured action within the scheduled task. This is captured within the registry event data for\nthis rule and can be base64 decoded to view the value.\n\n#### Possible investigation steps\n\n- Review the base64 encoded tasks actions registry value to investigate the task configured action.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software\ninstallations.\n- Further examination should include review of host-based artifacts and network logs from around when the scheduled task\nwas created, on both the source and target machines.\n\n### False positive analysis\n\n- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature\nwithin Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to\nfurther understand the source of the activity and determine the intent based on the scheduled task's contents.\n\n### Related rules\n\n- Service Command Lateral Movement - d61cbcf8-1bc1-4cff-85ba-e7b21c5beedc\n- Remotely Started Services via RPC - aa9a274d-6b53-424d-ac5e-cb8ca4251650\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Remove scheduled task and any other related artifacts.\n- Review privileged account management and user account management settings. Consider implementing group policy object (GPO) policies to further\nrestrict activity, or configuring settings that only allow administrators to create remote scheduled tasks.\n",
|
||||
"query": "/* Task Scheduler service incoming connection followed by TaskCache registry modification */\n\nsequence by host.id, process.entity_id with maxspan = 1m\n [network where process.name : \"svchost.exe\" and\n network.direction : (\"incoming\", \"ingress\") and source.port >= 49152 and destination.port >= 49152 and\n source.ip != \"127.0.0.1\" and source.ip != \"::1\"\n ]\n [registry where registry.path : \"HKLM\\\\SOFTWARE\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Schedule\\\\TaskCache\\\\Tasks\\\\*\\\\Actions\"]\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "954ee7c8-5437-49ae-b2d6-2960883898e9",
|
||||
|
|
@ -64,5 +64,5 @@
|
|||
}
|
||||
],
|
||||
"type": "eql",
|
||||
"version": 7
|
||||
"version": 8
|
||||
}
|
||||
|
|
|
|||
|
|
@ -30,5 +30,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 9
|
||||
"version": 11
|
||||
}
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "kuery",
|
||||
|
|
@ -41,5 +40,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 1
|
||||
"version": 2
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,8 +12,11 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Adobe Hijack Persistence",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Adobe Hijack Persistence\n\nAttackers can replace the `RdrCEF.exe` executable with their own to maintain their access, which will be launched\nwhenever Adobe Acrobat Reader is executed.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the IoCs identified.\n- Remove and block malicious artifacts identified on the triage.\n- Disable the involved accounts, or restrict their ability to log on remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "file where event.type == \"creation\" and\n file.path : (\"?:\\\\Program Files (x86)\\\\Adobe\\\\Acrobat Reader DC\\\\Reader\\\\AcroCEF\\\\RdrCEF.exe\",\n \"?:\\\\Program Files\\\\Adobe\\\\Acrobat Reader DC\\\\Reader\\\\AcroCEF\\\\RdrCEF.exe\") and\n not process.name : \"msiexec.exe\"\n",
|
||||
"references": [
|
||||
"https://twitter.com/pabraeken/status/997997818362155008"
|
||||
],
|
||||
"risk_score": 21,
|
||||
"rule_id": "2bf78aa2-9c56-48de-b139-f169bf99cf86",
|
||||
"severity": "low",
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@
|
|||
"license": "Elastic License v2",
|
||||
"name": "AWS Security Group Configuration Change Detection",
|
||||
"note": "## Config\n\nThe AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
|
||||
"query": "event.dataset:aws.cloudtrail and event.provider:iam.amazonaws.com and event.action:(AuthorizeSecurityGroupEgress or \nCreateSecurityGroup or ModifyInstanceAttribute or ModifySecurityGroupRules or RevokeSecurityGroupEgress or \nRevokeSecurityGroupIngress) and event.outcome:success\n",
|
||||
"query": "event.dataset:aws.cloudtrail and event.provider:ec2.amazonaws.com and event.action:(AuthorizeSecurityGroupEgress or \nCreateSecurityGroup or ModifyInstanceAttribute or ModifySecurityGroupRules or RevokeSecurityGroupEgress or \nRevokeSecurityGroupIngress) and event.outcome:success\n",
|
||||
"references": [
|
||||
"https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-security-groups.html"
|
||||
],
|
||||
|
|
@ -67,5 +67,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 3
|
||||
"version": 4
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Creation of a Hidden Local User Account",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Creation of a Hidden Local User Account\n\nAttackers can create accounts ending with a `$` symbol to make the account hidden to user enumeration utilities and\nbypass detections that identify computer accounts by this pattern to apply filters.\n\nThis rule uses registry events to identify the creation of local hidden accounts.\n\n#### Possible investigation steps\n\n- Identify the user account which performed the action and whether it should perform this kind of action.\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n\n### False positive analysis\n\n- This activity is unlikely to happen legitimately. Benign true positive (B-TPs) can be added as exceptions if necessary.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Quarantine the involved host to prevent further post-compromise behavior.\n- Delete the hidden account.\n- Review the privileges of the involved accounts.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "registry where registry.path : \"HKLM\\\\SAM\\\\SAM\\\\Domains\\\\Account\\\\Users\\\\Names\\\\*$\\\\\"\n",
|
||||
"references": [
|
||||
"https://blog.menasec.net/2019/02/threat-hunting-6-hiding-in-plain-sights_8.html",
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Suspicious Startup Shell Folder Modification",
|
||||
"note": "## Triage and analysis\n\n### Investigating Suspicious Startup Shell Activity\n\nTechniques used within malware and by adversaries often leverage the Windows registry to store malicious programs for\npersistence. Startup shell folders are often targeted as they are not as prevalent as normal Startup folder paths so this\nbehavior may evade existing AV/EDR solutions. These programs may also run with higher privileges which can be ideal for\nan attacker.\n\n#### Possible investigation steps:\n- Review the source process and related file tied to the Windows Registry entry.\n- Validate the activity is not related to planned patches, updates, network administrator activity or legitimate software\ninstallations.\n- Determine if activity is unique by validating if other machines in same organization have similar entry.\n\n### False Positive Analysis\n- There is a high possibility of benign legitimate programs being added to Shell folders. This activity could be based\non new software installations, patches, or any kind of network administrator related activity. Before entering further\ninvestigation, it should be verified that this activity is not benign.\n\n### Related Rules\n- Startup or Run Key Registry Modification\n- Persistent Scripts in the Startup Directory\n\n### Response and Remediation\n- Activity should first be validated as a true positive event if so then take immediate action to review,\ninvestigate and potentially isolate activity to prevent further post-compromise behavior.\n- The respective binary or program tied to this persistence method should be further analyzed and reviewed to understand\nits behavior and capabilities.\n- Since this activity is considered post-exploitation behavior, it's important to understand how the behavior was first\ninitialized such as through a macro-enabled document that was attached in a phishing email. By understanding the source\nof the attack, this information can then be used to search for similar indicators on other machines in the same environment.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Suspicious Startup Shell Folder Modification\n\nTechniques used within malware and by adversaries often leverage the Windows registry to store malicious programs for\npersistence. Startup shell folders are often targeted as they are not as prevalent as normal Startup folder paths so this\nbehavior may evade existing AV/EDR solutions. These programs may also run with higher privileges which can be ideal for\nan attacker.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Review the source process and related file tied to the Windows Registry entry.\n- Validate the activity is not related to planned patches, updates, network administrator activity or legitimate software\ninstallations.\n- Determine if activity is unique by validating if other machines in the same organization have similar entries.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- There is a high possibility of benign legitimate programs being added to shell folders. This activity could be based\non new software installations, patches, or other network administrator activity. Before entering further investigation,\nit should be verified that this activity is not benign.\n\n### Related rules\n\n- Startup or Run Key Registry Modification - 97fc44d3-8dae-4019-ae83-298c3015600f\n- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Since this activity is considered post-exploitation behavior, it's important to understand how the behavior was first\ninitialized such as through a macro-enabled document that was attached in a phishing email. After understanding the source\nof the attack, you can use this information to search for similar indicators on other machines in the same environment.\n",
|
||||
"query": "registry where\n registry.path : (\n \"HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\User Shell Folders\\\\Common Startup\",\n \"HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\Shell Folders\\\\Common Startup\",\n \"HKEY_USERS\\\\*\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\User Shell Folders\\\\Startup\",\n \"HKEY_USERS\\\\*\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\Shell Folders\\\\Startup\"\n ) and\n registry.data.strings != null and\n /* Normal Startup Folder Paths */\n not registry.data.strings : (\n \"C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\",\n \"%ProgramData%\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\",\n \"%USERPROFILE%\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\",\n \"C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\"\n )\n",
|
||||
"risk_score": 73,
|
||||
"rule_id": "c8b150f0-0164-475b-a75e-74b47800a9ff",
|
||||
|
|
|
|||
|
|
@ -50,5 +50,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -50,5 +50,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -50,5 +50,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -50,5 +50,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 8
|
||||
"version": 10
|
||||
}
|
||||
|
|
|
|||
|
|
@ -51,5 +51,5 @@
|
|||
}
|
||||
],
|
||||
"type": "eql",
|
||||
"version": 11
|
||||
"version": 12
|
||||
}
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "kuery",
|
||||
|
|
@ -63,5 +62,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "query",
|
||||
"version": 1
|
||||
"version": 2
|
||||
}
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Potential Modification of Accessibility Binaries",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Potential Modification of Accessibility Binaries\n\nAdversaries may establish persistence and/or elevate privileges by executing malicious content triggered by\naccessibility features. Windows contains accessibility features that may be launched with a key combination before a\nuser has logged in (ex: when the user is on the Windows logon screen). An adversary can modify the way these programs\nare launched to get a command prompt or backdoor without logging in to the system.\n\nMore details can be found [here](https://attack.mitre.org/techniques/T1546/008/).\n\nThis rule looks for the execution of supposed accessibility binaries that don't match any of the accessibility features\nbinaries' original file names, which is likely a custom binary deployed by the attacker.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This activity should not happen legitimately. The security team should address any potential benign true positive\n(B-TP), as this configuration can put the user and the domain at risk.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the IoCs identified.\n- Remove and block malicious artifacts identified on the triage.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\", \"info\") and\n process.parent.name : (\"Utilman.exe\", \"winlogon.exe\") and user.name == \"SYSTEM\" and\n process.args :\n (\n \"C:\\\\Windows\\\\System32\\\\osk.exe\",\n \"C:\\\\Windows\\\\System32\\\\Magnify.exe\",\n \"C:\\\\Windows\\\\System32\\\\Narrator.exe\",\n \"C:\\\\Windows\\\\System32\\\\Sethc.exe\",\n \"utilman.exe\",\n \"ATBroker.exe\",\n \"DisplaySwitch.exe\",\n \"sethc.exe\"\n )\n and not process.pe.original_file_name in\n (\n \"osk.exe\",\n \"sethc.exe\",\n \"utilman2.exe\",\n \"DisplaySwitch.exe\",\n \"ATBroker.exe\",\n \"ScreenMagnifier.exe\",\n \"SR.exe\",\n \"Narrator.exe\",\n \"magnify.exe\",\n \"MAGNIFY.EXE\"\n )\n\n/* uncomment once in winlogbeat to avoid bypass with rogue process with matching pe original file name */\n/* and process.code_signature.subject_name == \"Microsoft Windows\" and process.code_signature.status == \"trusted\" */\n",
|
||||
"references": [
|
||||
"https://www.elastic.co/blog/practical-security-engineering-stateful-detection"
|
||||
|
|
|
|||
|
|
@ -67,5 +67,5 @@
|
|||
"timeline_title": "Comprehensive Registry Timeline",
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 6
|
||||
"version": 7
|
||||
}
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*"
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "AdminSDHolder SDProp Exclusion Added",
|
||||
"note": "## Triage and analysis.\n\n### Investigating AdminSDHolder SDProp Exclusion Added\n\nThe SDProp process compares the permissions on protected objects with those defined on the AdminSDHolder object. If the\npermissions on any of the protected accounts and groups do not match, it resets the permissions on the protected\naccounts and groups to match those defined in the domain AdminSDHolder object.\n\nThe dSHeuristics is a Unicode string attribute, in which each character in the string represents a heuristic that is\nused to determine the behavior of Active Directory.\n\nAdministrators can use the dSHeuristics attribute to exclude privilege groups from the SDProp process by setting the\n16th bit (dwAdminSDExMask) of the string to a certain value, which represents the group(s):\n\n* For example, to exclude the Account Operators group, an administrator would modify the string, so the 16th character\nis set to 1 (i.e., 0000000001000001). \n\nThe usage of this exclusion can leave the accounts unprotected and facilitate the misconfigurations of privilege on the\nexcluded groups, leaving a gap for attackers to add accounts to these groups to maintain long-term persistence with high\nprivileges.\n\nThis rule will monitor changes on the dsHeuristics object where the 16th bit is set to a value other than zero.\n\n#### Possible investigation steps:\n\n- Identify the account that performed the action\n- Confirm whether the account owner is aware of the operation\n- Investigate other alerts related to the user in the last 48 hours.\n- Check the value assigned to the 16th bit of the string on the `winlog.event_data.AttributeValue` field:\n - Account Operators eq 1\n - Server Operators eq 2\n - Print Operators eq 4\n - Backup Operators eq 8\n The field value can range from 0 to f (15). If more than one group is specified, the values will be summed together;\n for example, Backup Operators and Print Operators will set the `c` value on the bit.\n\n### False Positive Analysis\n\n- While this modification can be done legitimately, it is not best practice. Any potential B-TP (Benign True Positive)\nshould be mapped and reviewed by the security team for alternatives as this weakens the security of the privileged group.\n\n### Response and Remediation\n\n- The change can be reverted by setting the dwAdminSDExMask (16th bit) to 0 in dSHeuristics.\n\n## Config\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration > \nPolicies > \nWindows Settings > \nSecurity Settings > \nAdvanced Audit Policies Configuration > \nAudit Policies > \nDS Access > \nAudit Directory Service Changes (Success)\n```\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating AdminSDHolder SDProp Exclusion Added\n\nThe SDProp process compares the permissions on protected objects with those defined on the AdminSDHolder object. If the\npermissions on any of the protected accounts and groups do not match, it resets the permissions on the protected\naccounts and groups to match those defined in the domain AdminSDHolder object.\n\nThe dSHeuristics is a Unicode string attribute, in which each character in the string represents a heuristic that is\nused to determine the behavior of Active Directory.\n\nAdministrators can use the dSHeuristics attribute to exclude privilege groups from the SDProp process by setting the\n16th bit (dwAdminSDExMask) of the string to a certain value, which represents the group(s):\n\n* For example, to exclude the Account Operators group, an administrator would modify the string, so the 16th character\nis set to 1 (i.e., 0000000001000001).\n\nThe usage of this exclusion can leave the accounts unprotected and facilitate the misconfiguration of privileges for the\nexcluded groups, enabling attackers to add accounts to these groups to maintain long-term persistence with high\nprivileges.\n\nThis rule matches changes of the dsHeuristics object where the 16th bit is set to a value other than zero.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check the value assigned to the 16th bit of the string on the `winlog.event_data.AttributeValue` field:\n - Account Operators eq 1\n - Server Operators eq 2\n - Print Operators eq 4\n - Backup Operators eq 8\n The field value can range from 0 to f (15). If more than one group is specified, the values will be summed together;\n for example, Backup Operators and Print Operators will set the `c` value on the bit.\n\n### False positive analysis\n\n- While this modification can be done legitimately, it is not best practice. Any potential benign true positive (B-TP)\nshould be mapped and reviewed by the security team for alternatives as this weakens the security of the privileged group.\n\n### Response and remediation\n\n- The change can be reverted by setting the dwAdminSDExMask (16th bit) to 0 in dSHeuristics.\n\n## Config\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration > \nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success)\n```\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "any where event.action == \"Directory Service Changes\" and\n event.code == \"5136\" and\n length(winlog.event_data.AttributeValue) > 15 and\n winlog.event_data.AttributeValue regex~ \"[0-9]{15}([1-9a-f]).*\"\n",
|
||||
"references": [
|
||||
"https://www.cert.ssi.gouv.fr/uploads/guide-ad.html#dsheuristics_bad",
|
||||
|
|
|
|||
|
|
@ -11,8 +11,8 @@
|
|||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Shortcut File Written or Modified for Persistence",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"name": "Startup Persistence by a Suspicious Process",
|
||||
"note": "## Triage and analysis\n\n### Investigating Startup Persistence by a Suspicious Process\n\nThe Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account\nlogon, without user interaction, providing an excellent way for attackers to maintain persistence.\n\nThis rule monitors for commonly abused processes writing to the Startup folder locations.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate\nsoftware installations.\n- Determine if activity is unique by validating if other machines in the organization have similar entries.\n- Retrieve the file:\n - Use a sandboxed malware analysis system to perform analysis.\n - Observe attempts to contact external domains and addresses.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- Administrators may add programs to this mechanism via command-line shells. Before the further investigation, \nverify that this activity is not benign.\n\n### Related rules\n\n- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff\n- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the identified indicators of compromise (IoCs).\n- Remove malicious artifacts identified on the triage.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "file where event.type != \"deletion\" and\n user.domain != \"NT AUTHORITY\" and\n file.path : (\"C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*\", \n \"C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\StartUp\\\\*\") and\n process.name : (\"cmd.exe\",\n \"powershell.exe\",\n \"wmic.exe\",\n \"mshta.exe\",\n \"pwsh.exe\",\n \"cscript.exe\",\n \"wscript.exe\",\n \"regsvr32.exe\",\n \"RegAsm.exe\",\n \"rundll32.exe\",\n \"EQNEDT32.EXE\",\n \"WINWORD.EXE\",\n \"EXCEL.EXE\",\n \"POWERPNT.EXE\",\n \"MSPUB.EXE\",\n \"MSACCESS.EXE\",\n \"iexplore.exe\",\n \"InstallUtil.exe\")\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "440e2db4-bc7f-4c96-a068-65b78da59bde",
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Startup Folder Persistence via Unsigned Process",
|
||||
"note": "## Triage and analysis\n\n### Investigating Startup Folder Persistence via Unsigned Process\n\nThe Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account\nlogon, without user interaction, providing an excellent way for attackers to maintain persistence.\n\nThis rule looks for unsigned processes writing to the Startup folder locations.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate\nsoftware installations.\n- Determine if activity is unique by validating if other machines in the organization have similar entries.\n- Retrieve the file:\n - Use a sandboxed malware analysis system to perform analysis.\n - Observe attempts to contact external domains and addresses.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- There is a high possibility of benign legitimate programs being added to Startup folders. This activity could be based\non new software installations, patches, or any kind of network administrator related activity. Before entering further\ninvestigation, verify that this activity is not benign.\n\n### Related rules\n\n- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff\n- Persistent Scripts in the Startup Directory - f7c4dc5a-a58d-491d-9f14-9b66507121c0\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the identified indicators of compromise (IoCs).\n- Remove malicious artifacts identified on the triage.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n",
|
||||
"query": "sequence by host.id, process.entity_id with maxspan=5s\n [process where event.type in (\"start\", \"process_started\") and process.code_signature.trusted == false and\n /* suspicious paths can be added here */\n process.executable : (\"C:\\\\Users\\\\*.exe\", \n \"C:\\\\ProgramData\\\\*.exe\", \n \"C:\\\\Windows\\\\Temp\\\\*.exe\", \n \"C:\\\\Windows\\\\Tasks\\\\*.exe\", \n \"C:\\\\Intel\\\\*.exe\", \n \"C:\\\\PerfLogs\\\\*.exe\")\n ]\n [file where event.type != \"deletion\" and user.domain != \"NT AUTHORITY\" and\n file.path : (\"C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*\", \n \"C:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\StartUp\\\\*\")\n ]\n",
|
||||
"risk_score": 41,
|
||||
"rule_id": "2fba96c0-ade5-4bce-b92f-a5df2509da3f",
|
||||
|
|
@ -46,5 +47,5 @@
|
|||
}
|
||||
],
|
||||
"type": "eql",
|
||||
"version": 2
|
||||
"version": 3
|
||||
}
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"author": [
|
||||
"Elastic"
|
||||
],
|
||||
"description": "Identifies script engines creating files in the startup folder, or the creation of script files in the startup folder.",
|
||||
"description": "Identifies script engines creating files in the Startup folder, or the creation of script files in the Startup folder. Adversaries may abuse this technique to maintain persistence in an environment.",
|
||||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Persistent Scripts in the Startup Directory",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Persistent Scripts in the Startup Directory\n\nThe Windows Startup folder is a special folder in Windows. Programs added to this folder are executed during account\nlogon, without user interaction, providing an excellent way for attackers to maintain persistence.\n\nThis rule looks for shortcuts created by wscript.exe or cscript.exe, or js/vbs scripts created by any process.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate\nsoftware installations.\n- Determine if activity is unique by validating if other machines in the organization have similar entries.\n- Retrieve the script file:\n - Use a sandboxed malware analysis system to perform analysis.\n - Observe attempts to contact external domains and addresses.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- There is a low possibility of benign legitimate scripts being added to Startup folders. Validate whether this activity\nis benign.\n\n\n### Related rules\n\n- Suspicious Startup Shell Folder Modification - c8b150f0-0164-475b-a75e-74b47800a9ff\n- Startup Folder Persistence via Unsigned Process - 2fba96c0-ade5-4bce-b92f-a5df2509da3f\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the identified indicators of compromise (IoCs).\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "file where event.type != \"deletion\" and user.domain != \"NT AUTHORITY\" and\n \n /* detect shortcuts created by wscript.exe or cscript.exe */\n (file.path : \"C:\\\\*\\\\Programs\\\\Startup\\\\*.lnk\" and\n process.name : (\"wscript.exe\", \"cscript.exe\")) or\n\n /* detect vbs or js files created by any process */\n file.path : (\"C:\\\\*\\\\Programs\\\\Startup\\\\*.vbs\", \n \"C:\\\\*\\\\Programs\\\\Startup\\\\*.vbe\", \n \"C:\\\\*\\\\Programs\\\\Startup\\\\*.wsh\", \n \"C:\\\\*\\\\Programs\\\\Startup\\\\*.wsf\", \n \"C:\\\\*\\\\Programs\\\\Startup\\\\*.js\")\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "f7c4dc5a-a58d-491d-9f14-9b66507121c0",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "System Shells via Services",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating System Shells via Services\n\nAttackers may configure existing services or create new ones to execute system shells to elevate their privileges from\nadministrator to SYSTEM. They can also configure services to execute these shells with persistence payloads.\n\nThis rule looks for system shells being spawned by `services.exe`, which is compatible with the above behavior.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify how the service was created or modified. Look for registry changes events or Windows events related to\nservice activities (for example, 4697 and/or 7045).\n - Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Check for commands executed under the spawned shell.\n\n### False positive analysis\n\n- This activity should not happen legitimately. The security team should address any potential benign true positive\n(B-TP), as this configuration can put the user and the domain at risk.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Delete the service or restore it to the original configuration.\n- Investigate the initial attack vector.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n process.parent.name : \"services.exe\" and\n process.name : (\"cmd.exe\", \"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") and\n \n /* Third party FP's */\n not process.args : \"NVDisplay.ContainerLocalSystem\"\n",
|
||||
"risk_score": 47,
|
||||
"rule_id": "0022d47d-39c7-4f69-a232-4fe9dc7a3acd",
|
||||
|
|
|
|||
|
|
@ -7,13 +7,12 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*",
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "User Added to Privileged Group in Active Directory",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating User Added to Privileged Group in Active Directory\n\nPrivileged accounts and groups in Active Directory are those to which powerful rights, privileges, and permissions are\ngranted that allow them to perform nearly any action in Active Directory and on domain-joined systems.\n\nAttackers can add users to privileged groups to maintain a level of access if their other privileged accounts are\nuncovered by the security team. This allows them to keep operating after the security team discovers abused accounts.\n\nThis rule monitors events related to a user being added to a privileged group.\n\n#### Possible investigation steps\n\n- Identify the user account that performed the action and whether it should manage members of this group.\n- Contact the account owner and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user during the past 48 hours.\n\n### False positive analysis\n\n- This attack abuses a legitimate Active Directory mechanism, so it is important to determine whether the activity is\nlegitimate, if the administrator is authorized to perform this operation, and if there is a need to grant the account\nthis level of privilege.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If the admin is not aware of the operation, activate your Active Directory incident response plan.\n- If the user does not need the administrator privileges, remove the account from the privileged group.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "iam where event.action == \"added-member-to-group\" and\n group.name : (\"Admin*\",\n \"Local Administrators\",\n \"Domain Admins\",\n \"Enterprise Admins\",\n \"Backup Admins\",\n \"Schema Admins\",\n \"DnsAdmins\",\n \"Exchange Organization Administrators\")\n",
|
||||
"references": [
|
||||
"https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory"
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
"author": [
|
||||
"Elastic"
|
||||
],
|
||||
"description": "Identifies attempts to create new local users. This is sometimes done by attackers to increase access to a system or domain.",
|
||||
"description": "Identifies attempts to create new users. This is sometimes done by attackers to increase access or establish persistence on a system or domain.",
|
||||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "User Account Creation",
|
||||
"note": "## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating User Account Creation\n\nAttackers may create new accounts (both local and domain) to maintain access to victim systems.\n\nThis rule identifies the usage of `net.exe` to create new accounts.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree).\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Identify if the account was added to privileged groups or assigned special privileges after creation.\n- Investigate other alerts related to the user/host in the last 48 hours.\n\n### False positive analysis\n\n- Account creation is a common administrative task, so there is a high chance of the activity being legitimate. Before\ninvestigating further, verify that this activity is not benign.\n\n### Related rules\n\n- Creation of a Hidden Local User Account - 2edc8076-291e-41e9-81e4-e3fcbc97ae5e\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Delete the created account.\n- Reset the password for the user account leveraged to create the new account.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "process where event.type in (\"start\", \"process_started\") and\n process.name : (\"net.exe\", \"net1.exe\") and\n not process.parent.name : \"net.exe\" and\n (process.args : \"user\" and process.args : (\"/ad\", \"/add\"))\n",
|
||||
"risk_score": 21,
|
||||
"rule_id": "1aa9181a-492b-4c01-8b16-fa0735786b2b",
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
"name": "Potential Privilege Escalation via InstallerFileTakeOver",
|
||||
"note": "## Triage and analysis.\n\n### Investigating Potential Priivilege Escalation via InstallerFileTakeOver\n\nInstallerFileTakeOver is a weaponized EoP PoC to the CVE-2021-41379 vulnerability. Upon successful exploitation,\nan unprivileged user will escalate privileges to SYSTEM/NT AUTHORITY.\n\nThis rule detects the default execution of the PoC, which overwrites the `elevation_service.exe` DACL and copies itself\nto the location to escalate privileges. An attacker is able to still take over any file that is not in use (locked), which is outside the scope of this rule.\n\n#### Possible investigation steps:\n\n- Check for the digital signature of the executable.\n- Look for additional processes spawned by the process, command lines, and network communications.\n- Look for additional alerts involving the host and the user.\n\n### False Positive Analysis\n\n- Verify whether the digital signature exists in the executable, and if it is valid.\n\n### Related Rules\n\n- Suspicious DLL Loaded for Persistence or Privilege Escalation - bfeaf89b-a2a7-48a3-817f-e41829dc61ee\n\n### Response and Remediation\n\n- Immediate response steps should be taken to validate, investigate, and potentially contain the activity to prevent\nfurther post-compromise behavior.\n\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"note": "## Triage and analysis\n\n### Investigating Potential Privilege Escalation via InstallerFileTakeOver\n\nInstallerFileTakeOver is a weaponized escalation of privilege proof of concept (EoP PoC) to the CVE-2021-41379 vulnerability. Upon successful exploitation, an\nunprivileged user will escalate privileges to SYSTEM/NT AUTHORITY.\n\nThis rule detects the default execution of the PoC, which overwrites the `elevation_service.exe` DACL and copies itself\nto the location to escalate privileges. An attacker is able to still take over any file that is not in use (locked),\nwhich is outside the scope of this rule.\n\n#### Possible investigation steps:\n\n- Check the executable's digital signature.\n- Look for additional processes spawned by the process, command lines, and network communications.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check for similar behavior in other hosts on the environment.\n- Retrieve the file and determine if it is malicious:\n - Use a private sandboxed malware analysis system to perform analysis.\n - Observe and collect information about the following activities:\n - Attempts to contact external domains and addresses.\n - File and registry access, modification, and creation activities.\n - Service creation and launch activities.\n - Scheduled tasks creation.\n - Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n - Search for the existence and reputation of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- Verify whether a digital signature exists in the executable, and if it is valid.\n\n### Related rules\n\n- Suspicious DLL Loaded for Persistence or Privilege Escalation - bfeaf89b-a2a7-48a3-817f-e41829dc61ee\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Isolate the involved host to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n - Implement any temporary network rules, procedures, and segmentation required to contain the malware.\n - Immediately block the identified indicators of compromise (IoCs).\n- Remove and block malicious artifacts identified on the triage.\n- Disable user account\u2019s ability to log in remotely.\n- Reset passwords for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Determine the initial infection vector.\n\n## Config\n\nIf 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 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.\n",
|
||||
"query": "/* This rule is compatible with both Sysmon and Elastic Endpoint */\n\nprocess where event.type == \"start\" and \n (?process.Ext.token.integrity_level_name : \"System\" or\n ?winlog.event_data.IntegrityLevel : \"System\") and\n (\n (process.name : \"elevation_service.exe\" and \n not process.pe.original_file_name == \"elevation_service.exe\") or\n\n (process.parent.name : \"elevation_service.exe\" and \n process.name : (\"rundll32.exe\", \"cmd.exe\", \"powershell.exe\")) \n )\n",
|
||||
"references": [
|
||||
"https://github.com/klinix5/InstallerFileTakeOver"
|
||||
|
|
@ -46,5 +46,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 3
|
||||
"version": 4
|
||||
}
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
"from": "now-9m",
|
||||
"index": [
|
||||
"winlogbeat-*",
|
||||
"logs-windows.*"
|
||||
"logs-system.*"
|
||||
],
|
||||
"language": "eql",
|
||||
"license": "Elastic License v2",
|
||||
|
|
|
|||
|
|
@ -50,5 +50,5 @@
|
|||
],
|
||||
"timestamp_override": "event.ingested",
|
||||
"type": "eql",
|
||||
"version": 4
|
||||
"version": 5
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue