[Detection Rules] Add 8.3 rules (#133845) (#133948)

(cherry picked from commit 4cb3f601fd)

Co-authored-by: Justin Ibarra <brokensound77@users.noreply.github.com>

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/application_added_to_google_workspace_domain.json

@@ -33,5 +33,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 10
+  "version": 12
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/collection_email_powershell_exchange_mailbox.json

@@ -15,7 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Exporting Exchange Mailbox via 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 Exporting Exchange Mailbox via PowerShell\n\nThe `New-MailBoxExportRequest` cmdlet is used to begin the process of exporting contents of a primary mailbox or archive\nto a .pst file. Note that this is done on a per-mailbox basis and this cmdlet is available only in on-premises Exchange.\n\nAttackers can abuse this functionality in preparation for exfiltrating contents, which is likely to contain sensitive\nand strategic data.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate the export operation:\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  - Check if this operation is done under change management and approved according to the organization's policy.\n  - Retrieve the operation status and use the `Get-MailboxExportRequest` cmdlet to review previous requests.\n  - By default, no group in Exchange has the privilege to import or export mailboxes. Investigate administrators that\n  assigned the \"Mailbox Import Export\" privilege for abnormal activity.\n- Investigate if there is a significant quantity of export requests in the alert timeframe. This operation is done on\na per-mailbox basis and can be part of a mass export.\n- If the operation was completed successfully:\n  - Check if the file is on the path specified in the command.\n  - Investigate if the file was compressed, archived, or retrieved by the attacker for exfiltration.\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 it is done with proper approval.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If the involved host is not the Exchange server, isolate the host to prevent further post-compromise behavior.\n- Use the `Remove-MailboxExportRequest` cmdlet to remove fully or partially completed export requests.\n- Prioritize cases that involve personally identifiable information (PII) or other classified data.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Review the privileges of users with the \"Mailbox Import Export\" privilege to ensure that the least privilege principle\nis being followed.\n- Run a full scan using the antimalware tool in place. This scan can reveal additional artifacts left in the system,\npersistence mechanisms, and malware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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: (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") and process.args : \"New-MailboxExportRequest*\"\n",
   "references": [
     "https://www.volexity.com/blog/2020/12/14/dark-halo-leverages-solarwinds-compromise-to-breach-organizations/",
@@ -62,5 +62,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/collection_microsoft_365_new_inbox_rule.json

@@ -17,7 +17,7 @@
   "license": "Elastic License v2",
   "name": "Microsoft 365 Inbox Forwarding Rule Created",
   "note": "## Config\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
-  "query": "event.dataset:o365.audit and event.provider:Exchange and\nevent.category:web and event.action:\"New-InboxRule\" and\n    (\n        o365audit.Parameters.ForwardTo:* or\n        o365audit.Parameters.ForwardAsAttachmentTo:* or\n        o365audit.Parameters.RedirectTo:*\n    ) \n    and event.outcome:success\n",
+  "query": "event.dataset:o365.audit and event.provider:Exchange and\nevent.category:web and event.action:\"New-InboxRule\" and\n    (\n        o365.audit.Parameters.ForwardTo:* or\n        o365.audit.Parameters.ForwardAsAttachmentTo:* or\n        o365.audit.Parameters.RedirectTo:*\n    ) \n    and event.outcome:success\n",
   "references": [
     "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account?view=o365-worldwide",
     "https://docs.microsoft.com/en-us/powershell/module/exchange/new-inboxrule?view=exchange-ps",
@@ -61,5 +61,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/collection_posh_audio_capture.json

@@ -11,7 +11,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell Suspicious Script with Audio Capture Capabilities",
-  "note": "## Triage and analysis.\n\n### Investigating PowerShell Suspicious Script with Audio Capture Capabilities\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use PowerShell to interact with the Windows API with the intent of capturing audio from input devices\nconnected to the victim's computer.\n\n#### Possible investigation steps\n\n- Examine script content that triggered the detection. \n- Investigate the script execution chain (parent process tree).\n- Inspect any file or network events from the suspicious PowerShell host process instance.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Investigate if the script stores the recorded data locally and determine if anything was recorded.\n- Investigate if the script contains exfiltration capabilities and the destination of this exfiltration.\n- Assess network data to determine if the host communicated with the exfiltration server.\n- Determine if the user credentials were compromised and if the attacker used them to perform unauthorized access to the\nlinked email account.\n\n### False positive analysis\n\n- Regular users should not need scripts to capture audio, which makes false positives unlikely. In the case of\nauthorized benign true positives (B-TPs), exceptions can be added.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- The response must be prioritized if this alert involves key executives or potentially valuable targets for espionage.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n- Configure AppLocker or equivalent software to restrict access to PowerShell for regular users.\n- Review GPOs to add additional restrictions for PowerShell usage by users.\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
+  "note": "## Triage and analysis\n\n### Investigating PowerShell Suspicious Script with Audio Capture Capabilities\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use PowerShell to interact with the Windows API with the intent of capturing audio from input devices\nconnected to the victim's computer.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate if the script stores the recorded data locally and determine if anything was recorded.\n- Investigate if the script contains exfiltration capabilities and the destination of this exfiltration.\n- Assess network data to determine if the host communicated with the exfiltration server.\n\n### False positive analysis\n\n- Regular users should not need scripts to capture audio, which makes false positives unlikely. In the case of\nauthorized benign true positives (B-TPs), exceptions can be added.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\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- The response must be prioritized if this alert involves key executives or potentially valuable targets for espionage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n    \"Get-MicrophoneAudio\" or (waveInGetNumDevs and mciSendStringA)\n  )\n",
   "references": [
     "https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-MicrophoneAudio.ps1"
@@ -67,5 +67,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/collection_posh_keylogger.json

@@ -11,7 +11,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell Keylogging Script",
-  "note": "## Triage and analysis.\n\n### Investigating PowerShell Keylogging Script\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can abuse PowerShell capabilities to capture user keystrokes with the goal of stealing credentials and other\nvaluable information as credit card data and confidential conversations.\n\n#### Possible investigation steps:\n\n- Examine script content that triggered the detection. \n- Investigate the script execution chain (parent process tree).\n- Inspect any file or network events from the suspicious PowerShell host process instance.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Investigate if the script stores the captured data locally.\n- Investigate if the script contains exfiltration capabilities and the destination of this exfiltration.\n- Assess network data to determine if the host communicated with the exfiltration server.\n\n### False positive analysis\n\n- Regular users do not have a business justification for using scripting utilities to capture keystrokes, making\nfalse positives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- The response must be prioritized if this alert involves key executives or potentially valuable targets for espionage.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n- Configure AppLocker or equivalent software to restrict access to PowerShell for regular users.\n- Reset the password for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
+  "note": "## Triage and analysis\n\n### Investigating PowerShell Keylogging Script\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can abuse PowerShell capabilities to capture user keystrokes with the goal of stealing credentials and other\nvaluable information as credit card data and confidential conversations.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate if the script stores the captured data locally.\n- Investigate if the script contains exfiltration capabilities and the destination of this exfiltration.\n- Assess network data to determine if the host communicated with the exfiltration server.\n\n### False positive analysis\n\n- Regular users do not have a business justification for using scripting utilities to capture keystrokes, making\nfalse positives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\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- The response must be prioritized if this alert involves key executives or potentially valuable targets for espionage.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  ( \n   powershell.file.script_block_text : (GetAsyncKeyState or NtUserGetAsyncKeyState or GetKeyboardState or \"Get-Keystrokes\") or \n   powershell.file.script_block_text : (\n        (SetWindowsHookA or SetWindowsHookW or SetWindowsHookEx or SetWindowsHookExA or NtUserSetWindowsHookEx) and\n        (GetForegroundWindow or GetWindowTextA or GetWindowTextW or \"WM_KEYBOARD_LL\")\n   )\n   )\n",
   "references": [
     "https://github.com/EmpireProject/Empire/blob/master/data/module_source/collection/Get-Keystrokes.ps1",
@@ -75,5 +75,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/collection_posh_screen_grabber.json

@@ -11,7 +11,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell Suspicious Script with Screenshot Capabilities",
-  "note": "## Triage and analysis\n\n### Investigating PowerShell Suspicious Script with Screenshot Capabilities\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, which makes\nit available for use in various environments and creates an attractive way for attackers to execute code.\n\nAttackers can abuse PowerShell capabilities and take screen captures of desktops to gather information over the course\nof an operation.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection. \n- Investigate the script execution chain (parent process tree).\n- Inspect file or network events from the suspicious PowerShell host process instance.\n- Investigate other alerts associated with the user or host in the past 48 hours.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Investigate if the script stores the captured data locally.\n- Investigate if the script contains exfiltration capabilities and the destination of this exfiltration.\n- Examine network data to determine if the host communicated with the exfiltration server.\n\n### False positive analysis\n\n- Regular users do not have a business justification for using scripting utilities to take screenshots, which makes false\npositives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added.\n\n### Related rules\n\n- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n- Configure AppLocker or equivalent software to restrict access to PowerShell for regular users.\n- Reset the password for the user account.\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
+  "note": "## Triage and analysis\n\n### Investigating PowerShell Suspicious Script with Screenshot Capabilities\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, which makes\nit available for use in various environments and creates an attractive way for attackers to execute code.\n\nAttackers can abuse PowerShell capabilities and take screen captures of desktops to gather information over the course\nof an operation.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate if the script stores the captured data locally.\n- Investigate if the script contains exfiltration capabilities and the destination of this exfiltration.\n- Assess network data to determine if the host communicated with the exfiltration server.\n\n### False positive analysis\n\n- Regular users do not have a business justification for using scripting utilities to take screenshots, which makes false\npositives unlikely. In the case of authorized benign true positives (B-TPs), exceptions can be added.\n\n### Related rules\n\n- PowerShell Keylogging Script - bd2c86a0-8b61-4457-ab38-96943984e889\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- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n    CopyFromScreen and\n    (\"System.Drawing.Bitmap\" or \"Drawing.Bitmap\")\n  )\n",
   "references": [
     "https://docs.microsoft.com/en-us/dotnet/api/system.drawing.graphics.copyfromscreen"
@@ -67,5 +67,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/collection_winrar_encryption.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Encrypting Files with WinRar or 7z",
-  "note": "## Triage and analysis\n\n### Investigating Encrypting Files with WinRar or 7z\n\nAttackers may compress and/or encrypt data collected before exfiltration. Compressing the data can help obfuscate the\ncollected data and minimize the amount of data sent over the network. Encryption can be used to hide information that is\nbeing exfiltrated from detection or make exfiltration less apparent upon inspection by a defender.\n\nThese steps are usually done in preparation for exfiltration, meaning the attack may be in its final stages.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Retrieve the encrypted file.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Check if the password used in the encryption was included in the command line.\n- Decrypt the `.rar`/`.zip` and check if the information is sensitive.\n- If the password is not available, and the format is `.zip` or the option used in WinRAR is not the `-hp`, list the\nfile names included in the encrypted file.\n- Investigate if the file was transferred to an attacker-controlled server.\n\n### False positive analysis\n\n- Backup software can use these utilities. Check the `process.parent.executable` and\n`process.parent.command_line` fields to determine what triggered the encryption.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- If personally identifiable information (PII) or other classified data is involved, investigations into this should be prioritized.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n- Reset the passwords of the involved accounts.\n- Safeguard critical assets to prevent further harm or theft of data.\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 Encrypting Files with WinRar or 7z\n\nAttackers may compress and/or encrypt data collected before exfiltration. Compressing the data can help obfuscate the\ncollected data and minimize the amount of data sent over the network. Encryption can be used to hide information that is\nbeing exfiltrated from detection or make exfiltration less apparent upon inspection by a defender.\n\nThese steps are usually done in preparation for exfiltration, meaning the attack may be in its final stages.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Retrieve the encrypted file.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check if the password used in the encryption was included in the command line.\n- Decrypt the `.rar`/`.zip` and check if the information is sensitive.\n- If the password is not available, and the format is `.zip` or the option used in WinRAR is not the `-hp`, list the\nfile names included in the encrypted file.\n- Investigate if the file was transferred to an attacker-controlled server.\n\n### False positive analysis\n\n- Backup software can use these utilities. Check the `process.parent.executable` and\n`process.parent.command_line` fields to determine what triggered the encryption.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Prioritize cases that involve personally identifiable information (PII) or other classified data.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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:\"rar.exe\" or process.code_signature.subject_name == \"win.rar GmbH\" or\n      process.pe.original_file_name == \"Command line RAR\") and\n    process.args == \"a\" and process.args : (\"-hp*\", \"-p*\", \"-dw\", \"-tb\", \"-ta\", \"/hp*\", \"/p*\", \"/dw\", \"/tb\", \"/ta\"))\n\n  or\n  (process.pe.original_file_name in (\"7z.exe\", \"7za.exe\") and\n     process.args == \"a\" and process.args : (\"-p*\", \"-sdel\"))\n\n  /* uncomment if noisy for backup software related FPs */\n  /* not process.parent.executable : (\"C:\\\\Program Files\\\\*.exe\", \"C:\\\\Program Files (x86)\\\\*.exe\") */\n",
   "references": [
     "https://www.welivesecurity.com/2020/12/02/turla-crutch-keeping-back-door-open/"
@@ -53,5 +53,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_certutil_network_connection.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Network Connection via Certutil",
-  "note": "## Triage and analysis\n\n### Investigating Network Connection via Certutil\n\nAttackers can abuse `certutil.exe` to download malware, offensive security tools, and certificates from external sources\nin order to take the next steps in a compromised environment.\n\nThis rule looks for network events where `certutil.exe` contacts IP ranges other than the ones specified in\n[IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Investigate if the downloaded file was executed.\n- Determine the context in which `certutil.exe` and the file were run.\n- Retrieve the file downloaded and:\n  - Use a sandboxed malware analysis system to perform analysis.\n    - Observe attempts of contacting 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 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. If trusted software uses this command and the triage has not identified\nanything suspicious, this alert can be closed as a false positive.\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- 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",
+  "note": "## Triage and analysis\n\n### Investigating Network Connection via Certutil\n\nAttackers can abuse `certutil.exe` to download malware, offensive security tools, and certificates from external sources\nin order to take the next steps in a compromised environment.\n\nThis rule looks for network events where `certutil.exe` contacts IP ranges other than the ones specified in\n[IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate if the downloaded file was executed.\n- Determine the context in which `certutil.exe` and the file were run.\n- Retrieve the downloaded 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. If trusted software uses this command and the triage has not identified\nanything suspicious, this alert can be closed as a false positive.\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- 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n",
   "query": "sequence by process.entity_id\n  [process where process.name : \"certutil.exe\" and event.type == \"start\"]\n  [network where process.name : \"certutil.exe\" and\n    not cidrmatch(destination.ip, \"10.0.0.0/8\", \"127.0.0.0/8\", \"169.254.0.0/16\", \"172.16.0.0/12\", \"192.0.0.0/24\",\n                                  \"192.0.0.0/29\", \"192.0.0.8/32\", \"192.0.0.9/32\", \"192.0.0.10/32\", \"192.0.0.170/32\",\n                                  \"192.0.0.171/32\", \"192.0.2.0/24\", \"192.31.196.0/24\", \"192.52.193.0/24\",\n                                  \"192.168.0.0/16\", \"192.88.99.0/24\", \"224.0.0.0/4\", \"100.64.0.0/10\", \"192.175.48.0/24\",\n                                  \"198.18.0.0/15\", \"198.51.100.0/24\", \"203.0.113.0/24\", \"240.0.0.0/4\", \"::1\",\n                                  \"FE80::/10\", \"FF00::/8\")]\n",
   "references": [
     "https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml",
@@ -46,5 +46,5 @@
     }
   ],
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_common_webservices.json

@@ -10,8 +10,8 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Connection to Commonly Abused Web Services",
-  "note": "## Triage and analysis\n\n### Investigating Connection to Commonly Abused Web Services\n\nAdversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised\nsystem. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the\nlikelihood that hosts within a network are already communicating with them prior to a compromise.\n\nThis rule looks for processes outside known legitimate program locations communicating with a list of services that can\nbe abused for exfiltration or command and control.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Verify whether the digital signature exists in the executable.\n- Identify the kind of the operation (upload, download, tunneling, etc.).\n- Use a sandboxed malware analysis system to perform analysis on the executable.\n- Use the PowerShell Get-FileHash cmdlet to get the SHA-256 hash value of the file.\n  - Search for the existence 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 because it detects communication with legitimate services. Noisy\nfalse positives can be added as exceptions.\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",
-  "query": "network where network.protocol == \"dns\" and\n    process.name != null and user.id not in (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\") and\n    /* Add new WebSvc domains here */\n    dns.question.name :\n    (\n        \"raw.githubusercontent.*\",\n        \"*.pastebin.*\",\n        \"*drive.google.*\",\n        \"*docs.live.*\",\n        \"*api.dropboxapi.*\",\n        \"*dropboxusercontent.*\",\n        \"*onedrive.*\",\n        \"*4shared.*\",\n        \"*.file.io\",\n        \"*filebin.net\",\n        \"*slack-files.com\",\n        \"*ghostbin.*\",\n        \"*ngrok.*\",\n        \"*portmap.*\",\n        \"*serveo.net\",\n        \"*localtunnel.me\",\n        \"*pagekite.me\",\n        \"*localxpose.io\",\n        \"*notabug.org\",\n        \"rawcdn.githack.*\",\n        \"paste.nrecom.net\",\n        \"zerobin.net\",\n        \"controlc.com\",\n        \"requestbin.net\",\n        \"cdn.discordapp.com\",\n        \"discordapp.com\",\n        \"discord.com\"\n    ) and\n    /* Insert noisy false positives here */\n    not process.executable :\n    (\n      \"?:\\\\Program Files\\\\*.exe\",\n      \"?:\\\\Program Files (x86)\\\\*.exe\",\n      \"?:\\\\Windows\\\\System32\\\\WWAHost.exe\",\n      \"?:\\\\Windows\\\\System32\\\\smartscreen.exe\",\n      \"?:\\\\Windows\\\\System32\\\\MicrosoftEdgeCP.exe\",\n      \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Fiddler\\\\Fiddler.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Microsoft VS Code\\\\Code.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Microsoft\\\\OneDrive\\\\OneDrive.exe\",\n      \"?:\\\\Windows\\\\system32\\\\mobsync.exe\",\n      \"?:\\\\Windows\\\\SysWOW64\\\\mobsync.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Discord\\\\-*\\\\Discord.exe\"\n    )\n",
+  "note": "## Triage and analysis\n\n### Investigating Connection to Commonly Abused Web Services\n\nAdversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised\nsystem. Popular websites and social media acting as a mechanism for C2 may give a significant amount of cover due to the\nlikelihood that hosts within a network are already communicating with them prior to a compromise.\n\nThis rule looks for processes outside known legitimate program locations communicating with a list of services that can\nbe abused for exfiltration or command and control.\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Verify whether the digital signature exists in the executable.\n- Identify the operation type (upload, download, tunneling, etc.).\n- Retrieve the process executable 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 because it detects communication with legitimate services. Noisy\nfalse positives can be added as exceptions.\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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n",
+  "query": "network where network.protocol == \"dns\" and\n    process.name != null and user.id not in (\"S-1-5-18\", \"S-1-5-19\", \"S-1-5-20\") and\n    /* Add new WebSvc domains here */\n    dns.question.name :\n    (\n        \"raw.githubusercontent.*\",\n        \"*.pastebin.*\",\n        \"*drive.google.*\",\n        \"*docs.live.*\",\n        \"*api.dropboxapi.*\",\n        \"*dropboxusercontent.*\",\n        \"*onedrive.*\",\n        \"*4shared.*\",\n        \"*.file.io\",\n        \"*filebin.net\",\n        \"*slack-files.com\",\n        \"*ghostbin.*\",\n        \"*ngrok.*\",\n        \"*portmap.*\",\n        \"*serveo.net\",\n        \"*localtunnel.me\",\n        \"*pagekite.me\",\n        \"*localxpose.io\",\n        \"*notabug.org\",\n        \"rawcdn.githack.*\",\n        \"paste.nrecom.net\",\n        \"zerobin.net\",\n        \"controlc.com\",\n        \"requestbin.net\",\n        \"cdn.discordapp.com\",\n        \"discordapp.com\",\n        \"discord.com\"\n    ) and\n    /* Insert noisy false positives here */\n    not process.executable :\n    (\n      \"?:\\\\Program Files\\\\*.exe\",\n      \"?:\\\\Program Files (x86)\\\\*.exe\",\n      \"?:\\\\Windows\\\\System32\\\\WWAHost.exe\",\n      \"?:\\\\Windows\\\\System32\\\\smartscreen.exe\",\n      \"?:\\\\Windows\\\\System32\\\\MicrosoftEdgeCP.exe\",\n      \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Fiddler\\\\Fiddler.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Microsoft VS Code\\\\Code.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Microsoft\\\\OneDrive\\\\OneDrive.exe\",\n      \"?:\\\\Windows\\\\system32\\\\mobsync.exe\",\n      \"?:\\\\Windows\\\\SysWOW64\\\\mobsync.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Discord\\\\app-*\\\\Discord.exe\"\n    )\n",
   "risk_score": 21,
   "rule_id": "66883649-f908-4a5b-a1e0-54090a1d3a32",
   "severity": "low",
@@ -68,5 +68,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 8
+  "version": 9
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_connection_attempt_by_non_ssh_root_session.json

@@ -0,0 +1,74 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Identifies an outbound network connection attempt followed by a session id change as the root user by the same process entity. This particular instantiation of a network connection is abnormal and should be investigated as it may indicate a potential reverse shell activity via a privileged process.",
+  "false_positives": [
+    "False-Positives (FP) can appear if another remote terminal service is being used to connect to it's listener but typically SSH is used in these scenarios."
+  ],
+  "from": "now-9m",
+  "index": [
+    "logs-endpoint.events.*"
+  ],
+  "language": "eql",
+  "license": "Elastic License v2",
+  "name": "Suspicious Network Connection Attempt by Root",
+  "note": "## Triage and analysis\n### Investigating Connection Attempt by Non-SSH Root Session\nDetection alerts from this rule indicate a strange or abnormal outbound connection attempt by a privileged process.  Here are some possible avenues of investigation:\n- Examine unusual and active sessions using commands such as 'last -a', 'netstat -a', and 'w -a'.\n- Analyze processes and command line arguments to detect anomalous process execution that may be acting as a listener.\n- Analyze anomalies in the use of files that do not normally initiate connections.\n- Examine processes utilizing the network that do not normally have network communication.\n",
+  "query": "sequence by process.entity_id with maxspan=1m\n[network where event.type == \"start\" and event.action == \"connection_attempted\" and user.id == \"0\" and \n    not process.executable : (\"/bin/ssh\", \"/sbin/ssh\", \"/usr/lib/systemd/systemd\")]\n[process where event.action == \"session_id_change\" and user.id == \"0\"]\n",
+  "references": [
+    "https://www.sandflysecurity.com/blog/linux-file-masquerading-and-malicious-pids-sandfly-1-2-6-update/",
+    "https://twitter.com/GossiTheDog/status/1522964028284411907",
+    "https://exatrack.com/public/Tricephalic_Hellkeeper.pdf"
+  ],
+  "risk_score": 43,
+  "rule_id": "eb6a3790-d52d-11ec-8ce9-f661ea17fbce",
+  "severity": "medium",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Linux",
+    "Threat Detection",
+    "Command and Control"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0011",
+        "name": "Command and Control",
+        "reference": "https://attack.mitre.org/tactics/TA0011/"
+      },
+      "technique": [
+        {
+          "id": "T1095",
+          "name": "Non-Application Layer Protocol",
+          "reference": "https://attack.mitre.org/techniques/T1095/"
+        }
+      ]
+    },
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0004",
+        "name": "Privilege Escalation",
+        "reference": "https://attack.mitre.org/tactics/TA0004/"
+      },
+      "technique": [
+        {
+          "id": "T1548",
+          "name": "Abuse Elevation Control Mechanism",
+          "reference": "https://attack.mitre.org/techniques/T1548/",
+          "subtechnique": [
+            {
+              "id": "T1548.003",
+              "name": "Sudo and Sudo Caching",
+              "reference": "https://attack.mitre.org/techniques/T1548/003/"
+            }
+          ]
+        }
+      ]
+    }
+  ],
+  "type": "eql",
+  "version": 1
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_dns_tunneling_nslookup.json

@@ -12,7 +12,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "Potential DNS Tunneling via NsLookup",
-  "note": "## Triage and analysis\n\n### Investigating Potential DNS Tunneling via NsLookup\n\nAttackers can abuse existing network rules that allow DNS communication with external resources to use the protocol as\ntheir command and control and/or exfiltration channel.\n\nDNS queries can be used to infiltrate data such as commands to be run, malicious files, etc., and also for exfiltration,\nsince queries can be used to send data to the attacker-controlled DNS server. This process is commonly known as DNS tunneling.\n\nMore information on how tunneling works and how it can be abused can be found on\n[Palo Alto Unit42 Research](https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors).\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Inspect the DNS query and identify the information sent.\n- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially compromised hosts.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. If the parent process is trusted and the data sent is not sensitive nor\ncommand and control related, this alert can be closed.\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- Immediately block the IoCs identified on the triage.\n- Implement any temporary network rules, procedures, and segmentation required to contain the attack.\n- Capture forensic images to preserve evidence.\n- Reset the password for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Update firewall rules to be more restrictive.\n- Reimage affected systems.\n",
+  "note": "## Triage and analysis\n\n### Investigating Potential DNS Tunneling via NsLookup\n\nAttackers can abuse existing network rules that allow DNS communication with external resources to use the protocol as\ntheir command and control and/or exfiltration channel.\n\nDNS queries can be used to infiltrate data such as commands to be run, malicious files, etc., and also for exfiltration,\nsince queries can be used to send data to the attacker-controlled DNS server. This process is commonly known as DNS tunneling.\n\nMore information on how tunneling works and how it can be abused can be found on\n[Palo Alto Unit42 Research](https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors).\n\n#### Possible investigation steps\n\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Inspect the DNS query and identify the information sent.\n- Extract this communication's indicators of compromise (IoCs) and use traffic logs to search for other potentially\ncompromised hosts.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. If the parent process is trusted and the data sent is not sensitive nor\ncommand and control related, this alert can be closed.\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- Immediately block the identified indicators of compromise (IoCs).\n- Implement any temporary network rules, procedures, and segmentation required to contain the attack.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Update firewall rules to be more restrictive.\n- Reimage the host operating system or restore the compromised files to clean versions.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n",
   "query": "event.category:process and event.type:start and process.name:nslookup.exe and process.args:(-querytype=* or -qt=* or -q=* or -type=*)\n",
   "references": [
     "https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/"
@@ -58,5 +58,5 @@
     "value": 15
   },
   "type": "threshold",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_port_forwarding_added_registry.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Port Forwarding Rule Addition",
-  "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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account and system owners and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n- Identify the target host IP address, check the connections originating from the host where the modification occurred,\nand inspect the credentials used.\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 the triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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"
@@ -46,5 +46,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_rdp_remote_desktop_protocol_from_the_internet.json

@@ -76,5 +76,5 @@
   "timeline_title": "Comprehensive Network Timeline",
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 12
+  "version": 14
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_rdp_tunnel_plink.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Potential Remote Desktop Tunneling Detected",
-  "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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the account and system owners and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\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- Take the necessary actions to disable the tunneling, which can be a process kill, service deletion, registry key\nmodification, etc. Inspect the host to learn which method was used and to determine a response for the case.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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/"
@@ -46,5 +46,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_remote_file_copy_desktopimgdownldr.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Remote File Download via Desktopimgdownldr Utility",
-  "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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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/"
@@ -46,5 +46,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_remote_file_copy_mpcmdrun.json

@@ -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\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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -47,5 +47,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_remote_file_copy_powershell.json

@@ -12,7 +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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Evaluate whether the user needs to use PowerShell to complete 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -64,5 +64,5 @@
     }
   ],
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_remote_file_copy_scripts.json

@@ -12,7 +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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Retrieve the script file and the executable involved and determine if they are 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 associated with the user/host during the past 48 hours.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -42,5 +42,5 @@
     }
   ],
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_sunburst_c2_activity_detected.json

@@ -10,7 +10,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "SUNBURST Command and Control Activity",
-  "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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Retrieve the executable involved:\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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\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 associated with the user/host during the past 48 hours.\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 environment 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Upgrade SolarWinds systems to the latest version to eradicate the chance of reinfection by abusing the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_teamviewer_remote_file_copy.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Remote File Copy via TeamViewer",
-  "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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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"
@@ -51,5 +51,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/command_and_control_telnet_port_activity.json

@@ -73,5 +73,5 @@
   "timeline_title": "Comprehensive Network Timeline",
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 10
+  "version": 12
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_disable_kerberos_preauth.json

@@ -11,10 +11,10 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "Kerberos Pre-authentication Disabled for User",
-  "note": "## Triage and analysis\n\n### Investigating Kerberos Pre-authentication Disabled for User\n\nKerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting\naccess to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request\n(AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to\nsuccessfully decrypt the timestamp with the hash of the user\u2019s password, it will then send an Authentication Server\nResponse (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is\nsigned with the user\u2019s password. Microsoft's security monitoring [recommendations](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738) state that `'Don't Require Preauth' \u2013 Enabled` should not be enabled for user accounts because it weakens security for the account\u2019s Kerberos authentication.\n\nAS-REP roasting is an attack against Kerberos for user accounts that do not require pre-authentication, which means that\nif the target user has pre-authentication disabled, an attacker can request authentication data for it and get a TGT that\ncan be brute-forced offline, similarly 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- Investigate if the target account is privileged.\n- Contact the account owner and confirm whether they are aware of this activity.\n\n### False positive analysis\n\n- Disabling pre-authentication is a bad security practice and should not be allowed in the domain. The security team\nshould map and monitor any potential benign true positives (B-TPs), especially if the target account is privileged.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Reset the target account's password if there is any risk of TGTs having been retrieved.\n- Reset the password of the origin user if the activity was not recognized by the account owner.\n- Re-enable the preauthentication option for the account.\n\n## Config\n\nThe 'Audit User Account Management' 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 > \nAccount Management > \nAudit User Account Management (Success,Failure)\n```\n",
+  "note": "## Triage and analysis\n\n### Investigating Kerberos Pre-authentication Disabled for User\n\nKerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting\naccess to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request\n(AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to\nsuccessfully decrypt the timestamp with the hash of the user\u2019s password, it will then send an Authentication Server\nResponse (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is\nsigned with the user\u2019s password. Microsoft's security monitoring [recommendations](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738) state that `'Don't Require Preauth' \u2013 Enabled` should not be enabled for user accounts because it weakens security for the account\u2019s Kerberos authentication.\n\nAS-REP roasting is an attack against Kerberos for user accounts that do not require pre-authentication, which means that\nif the target user has pre-authentication disabled, an attacker can request authentication data for it and get a TGT that\ncan be brute-forced offline, similarly to Kerberoasting.\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- Determine if the target account is sensitive or privileged.\n- Inspect the account activities for suspicious or abnormal behaviors in the alert timeframe.\n\n### False positive analysis\n\n- Disabling pre-authentication is a bad security practice and should not be allowed in the domain. The security team\nshould map and monitor any potential benign true positives (B-TPs), especially if the target account is privileged.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Reset the target account's password if there is any risk of TGTs having been retrieved.\n- Re-enable the preauthentication option or disable the target account.\n- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'Audit User Account Management' 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 > \nAccount Management > \nAudit User Account Management (Success,Failure)\n```\n",
   "query": "event.code:4738 and message:\"'Don't Require Preauth' - Enabled\"\n",
   "references": [
-    "https://www.harmj0y.net/blog/activedirectory/roasting-as-reps",
+    "https://harmj0y.medium.com/roasting-as-reps-e6179a65216b",
     "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738",
     "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md"
   ],
@@ -54,5 +54,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_domain_backup_dpapi_private_keys.json

@@ -16,7 +16,7 @@
   "query": "file where event.type != \"deletion\" and file.name : (\"ntds_capi_*.pfx\", \"ntds_capi_*.pvk\")\n",
   "references": [
     "https://www.dsinternals.com/en/retrieving-dpapi-backup-keys-from-active-directory/",
-    "https://www.harmj0y.net/blog/redteaming/operational-guidance-for-offensive-user-dpapi-abuse/"
+    "https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107"
   ],
   "risk_score": 73,
   "rule_id": "b83a7e96-2eb3-4edf-8346-427b6858d3bd",
@@ -59,5 +59,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_dump_registry_hives.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Credential Acquisition via Registry Hive Dumping",
-  "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",
+  "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 the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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- Investigate if the credential material was exfiltrated or processed locally by other tools.\n- Investigate 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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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"
@@ -58,5 +58,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_kerberoasting_unusual_process.json

@@ -15,7 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Kerberos Traffic from Unusual Process",
-  "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",
+  "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 the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check if the Destination IP is related to a Domain Controller.\n- Review event ID 4769 for suspicious ticket requests.\n- Retrieve the process executable 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\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- Isolate the involved host to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n  - Ticket requests can be used to investigate potentially compromised accounts.\n- If the triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -46,5 +46,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_lsass_memdump_file_created.json

@@ -56,5 +56,5 @@
   "timeline_title": "Comprehensive File Timeline",
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 9
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_lsass_memdump_handle_access.json

@@ -11,7 +11,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "LSASS Memory Dump Handle Access",
-  "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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Retrieve the process executable 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### False positive analysis\n\n- There should be very few or no false positives for this rule. If this activity is expected or noisy in your environment,\nconsider adding exceptions \u2014 preferably with a combination of user and command line conditions.\n- If the process is related to antivirus or endpoint detection and response solutions, validate that it is installed on\nthe correct path and signed with the company's valid digital signature.\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- If the triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -56,5 +56,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_microsoft_365_brute_force_user_account_attempt.json

@@ -17,7 +17,7 @@
   "license": "Elastic License v2",
   "name": "Attempts to Brute Force a Microsoft 365 User Account",
   "note": "## Config\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
-  "query": "event.dataset:o365.audit and event.provider:(AzureActiveDirectory or Exchange) and\n  event.category:authentication and event.action:(UserLoginFailed or PasswordLogonInitialAuthUsingPassword) and\n  not o365.audit.LogonError:(UserAccountNotFound or EntitlementGrantsNotFound or UserStrongAuthEnrollmentRequired or\n                             UserStrongAuthClientAuthNRequired or InvalidReplyTo) and event.outcome:success\n",
+  "query": "event.dataset:o365.audit and event.provider:(AzureActiveDirectory or Exchange) and\n  event.category:authentication and event.action:(UserLoginFailed or PasswordLogonInitialAuthUsingPassword) and\n  not o365.audit.LogonError:(UserAccountNotFound or EntitlementGrantsNotFound or UserStrongAuthEnrollmentRequired or\n                             UserStrongAuthClientAuthNRequired or InvalidReplyTo)\n",
   "references": [
     "https://blueteamblog.com/7-ways-to-monitor-your-office-365-logs-using-siem"
   ],
@@ -56,5 +56,5 @@
     "value": 10
   },
   "type": "threshold",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_microsoft_365_potential_password_spraying_attack.json

@@ -15,7 +15,7 @@
   "license": "Elastic License v2",
   "name": "Potential Password Spraying of Microsoft 365 User Accounts",
   "note": "## Config\n\nThe Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.",
-  "query": "event.dataset:o365.audit and event.provider:(Exchange or AzureActiveDirectory) and event.category:authentication and \nevent.action:(\"UserLoginFailed\" or \"PasswordLogonInitialAuthUsingPassword\") and event.outcome:success\n",
+  "query": "event.dataset:o365.audit and event.provider:(Exchange or AzureActiveDirectory) and event.category:authentication and \nevent.action:(\"UserLoginFailed\" or \"PasswordLogonInitialAuthUsingPassword\")\n",
   "risk_score": 73,
   "rule_id": "3efee4f0-182a-40a8-a835-102c68a4175d",
   "severity": "high",
@@ -51,5 +51,5 @@
     "value": 25
   },
   "type": "threshold",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_mimikatz_memssp_default_logs.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Mimikatz Memssp Log File Detected",
-  "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",
+  "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 the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate 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- Search for DLL files created in the same location as the log file, and retrieve unsigned DLLs.\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  - Identify the process that created the DLL using file creation events.\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 privileges assigned to users that can access the DCs to ensure that the least privilege principle is\n  being followed and reduce the attack surface.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\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- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -43,5 +43,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_mimikatz_powershell_module.json

@@ -0,0 +1,57 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks. This rule detects Invoke-Mimikatz PowerShell script and alike.",
+  "from": "now-9m",
+  "index": [
+    "winlogbeat-*",
+    "logs-windows.*"
+  ],
+  "language": "kuery",
+  "license": "Elastic License v2",
+  "name": "Potential Invoke-Mimikatz PowerShell Script",
+  "note": "## Triage and analysis\n\n### Investigating Mimikatz PowerShell Activity\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 move laterally and pivot across a network.\n\nThis rule looks for PowerShell scripts that load mimikatz in memory, like Invoke-Mimikataz, which are used to dump\ncredentials from the Local Security Authority Subsystem Service (LSASS). Any activity triggered from this rule should be\ntreated with high priority as it typically represents an active adversary.\n\nMore information about Mimikatz components and how to detect/prevent them can be found on [ADSecurity](https://adsecurity.org/?page_id=1821).\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n  - Invoke-Mimitakz and alike scripts heavily use other capabilities covered by other detections described in the\n  \"Related Rules\" section.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the\ntarget host.\n  - Examine network and security events in the environment to identify potential lateral movement using compromised credentials.\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 PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad\n- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- Mimikatz Memssp Log File Detected - ebb200e8-adf0-43f8-a0bb-4ee5b5d852c6\n- Modification of WDigest Security Provider - d703a5af-d5b0-43bd-8ddb-7a5d500b7da5\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Validate that cleartext passwords are disabled in memory for use with `WDigest`.\n- Look into preventing access to `LSASS` using capabilities such as LSA protection or antivirus/EDR tools that provide\nthis capability.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
+  "query": "event.category:process and\npowershell.file.script_block_text:(\n  (DumpCreds and\n  DumpCerts) or\n  \"sekurlsa::logonpasswords\" or\n  (\"crypto::certificates\" and\n  \"CERT_SYSTEM_STORE_LOCAL_MACHINE\")\n)\n",
+  "references": [
+    "https://attack.mitre.org/software/S0002/",
+    "https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1"
+  ],
+  "risk_score": 73,
+  "rule_id": "ac96ceb8-4399-4191-af1d-4feeac1f1f46",
+  "severity": "high",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Windows",
+    "Threat Detection",
+    "Credential Access"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0006",
+        "name": "Credential Access",
+        "reference": "https://attack.mitre.org/tactics/TA0006/"
+      },
+      "technique": [
+        {
+          "id": "T1003",
+          "name": "OS Credential Dumping",
+          "reference": "https://attack.mitre.org/techniques/T1003/",
+          "subtechnique": [
+            {
+              "id": "T1003.001",
+              "name": "LSASS Memory",
+              "reference": "https://attack.mitre.org/techniques/T1003/001/"
+            }
+          ]
+        }
+      ]
+    }
+  ],
+  "timestamp_override": "event.ingested",
+  "type": "query",
+  "version": 1
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_mod_wdigest_security_provider.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Modification of WDigest Security Provider",
-  "note": "## Triage and analysis.\n\n### Investigating Modification of WDigest Security Provider\n\nIn Windows XP, Microsoft added support for a protocol known as WDigest. The WDigest protocol allows clients to send\ncleartext credentials to Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) applications\nbased on RFC 2617 and 2831. Windows versions up to 8 and 2012 store logon credentials in memory in plaintext by default,\nwhich is no longer the case with newer Windows versions.\n\nStill, attackers can force WDigest to store the passwords insecurely on the memory by modifying the\n`HKLM\\SYSTEM\\*ControlSet*\\Control\\SecurityProviders\\WDigest\\UseLogonCredential` registry key. This activity is\ncommonly related to the execution of credential dumping tools.\n\n#### Possible investigation steps\n\n- It is unlikely that the monitored registry key was modified legitimately in newer versions of Windows. Analysts should\ntreat any activity triggered from this rule with high priority as it typically represents an active adversary.\n- Investigate the script execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Determine if credential dumping tools were run on the host and if any suspicious tool is found:\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 of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Use process name, command line, and file hash to search for other compromised hosts.\n- Scope potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target\nhost after the registry modification.\n\n### False positive analysis\n\n- This modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and\nmonitored by the security team, as these modifications expose the entire domain to credential compromises and\nconsequently unauthorized access.\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- Disable user account\u2019s ability to log in remotely.\n- Reset the password for the user account and other potentially compromised accounts (email, services, CRMs, etc.).\n- Reimage the host operating system and restore compromised files to clean versions.\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 Modification of WDigest Security Provider\n\nIn Windows XP, Microsoft added support for a protocol known as WDigest. The WDigest protocol allows clients to send\ncleartext credentials to Hypertext Transfer Protocol (HTTP) and Simple Authentication Security Layer (SASL) applications\nbased on RFC 2617 and 2831. Windows versions up to 8 and 2012 store logon credentials in memory in plaintext by default,\nwhich is no longer the case with newer Windows versions.\n\nStill, attackers can force WDigest to store the passwords insecurely on the memory by modifying the\n`HKLM\\SYSTEM\\*ControlSet*\\Control\\SecurityProviders\\WDigest\\UseLogonCredential` registry key. This activity is\ncommonly related to the execution of credential dumping tools.\n\n#### Possible investigation steps\n\n- It is unlikely that the monitored registry key was modified legitimately in newer versions of Windows. Analysts should\ntreat any activity triggered from this rule with high priority as it typically represents an active adversary.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Determine if credential dumping tools were run on the host, and retrieve and analyze suspicious executables:\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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Use process name, command line, and file hash to search for occurrences on other hosts.\n- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the target\nhost after the registry modification.\n\n### False positive analysis\n\n- This modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and\nmonitored by the security team, as these modifications expose the entire domain to credential compromises and\nconsequently unauthorized access.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 : (\"creation\", \"change\") and\n    registry.path : \n        \"HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\SecurityProviders\\\\WDigest\\\\UseLogonCredential\"\n    and registry.data.strings : (\"1\", \"0x00000001\")\n",
   "references": [
     "https://www.csoonline.com/article/3438824/how-to-detect-and-halt-credential-theft-via-windows-wdigest.html",
@@ -55,5 +55,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_moving_registry_hive_via_smb.json

@@ -2,7 +2,7 @@
   "author": [
     "Elastic"
   ],
-  "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.",
+  "description": "Identifies the creation or modification of a medium-size registry hive file on a Server Message Block (SMB) share, which may indicate an exfiltration attempt of a previously dumped Security Account Manager (SAM) registry hive for credential extraction on an attacker-controlled system.",
   "from": "now-9m",
   "index": [
     "logs-endpoint.events.*"
@@ -10,7 +10,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "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",
+  "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 associated with the user/source host during the past 48 hours.\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- Inspect the source host for suspicious or abnormal behaviors in the alert timeframe.\n- Capture the registry file(s) to determine the extent of the credential compromise 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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Reimage the host operating system and restore compromised files to clean versions.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -71,5 +71,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_posh_minidump.json

@@ -14,7 +14,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell MiniDump Script",
-  "note": "## Triage and analysis.\n\n### Investigating PowerShell MiniDump Script\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can abuse Process Memory Dump capabilities to extract credentials from LSASS or to obtain other\nprivileged information stored in the process memory.\n\n#### Possible investigation steps\n\n- Examine script content that triggered the detection. \n- Investigate the script execution chain (parent process tree).\n- Inspect any file or network events from the suspicious PowerShell host process instance.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Check if the imported function was executed and which process it targeted.\n\n### False positive analysis\n\n- Regular users do not have a business justification for using scripting utilities to dump process memory, making false\npositives unlikely.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n- Configure AppLocker or equivalent software to restrict access to PowerShell for regular users.\n- Reset the password for the user account.\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
+  "note": "## Triage and analysis\n\n### Investigating PowerShell MiniDump Script\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can abuse Process Memory Dump capabilities to extract credentials from LSASS or to obtain other\nprivileged information stored in the process memory.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Check if the imported function was executed and which process it targeted.\n\n### False positive analysis\n\n- Regular users do not have a business justification for using scripting utilities to dump process memory, making false\npositives unlikely.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\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- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and powershell.file.script_block_text:(MiniDumpWriteDump or MiniDumpWithFullMemory or pmuDetirWpmuDiniM)\n",
   "references": [
     "https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Out-Minidump.ps1",
@@ -79,5 +79,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 6
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_posh_request_ticket.json

@@ -11,7 +11,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell Kerberos Ticket Request",
-  "note": "## Triage and analysis\n\n### Investigating Explicit PowerShell Kerberos Ticket Request\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making\nit available for use in various environments, creating an attractive way for attackers to execute code.\n\nAccounts associated with a service principal name (SPN) are viable targets for Kerberoasting attacks, which use brute\nforce to crack the user password, which is used to encrypt a Kerberos TGS ticket.\n\nAttackers can use PowerShell to request these Kerberos tickets, with the intent of extracting them from memory to\nperform Kerberoasting.\n\n#### Possible investigation steps\n\n- Retrieve the script contents.\n- Investigate the script execution chain (parent process tree).\n- Investigate if the script was executed, and if so, which account was targeted.\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- Check if the script has any other functionality that can be potentially malicious.\n- Investigate other alerts related to the host and user in the last 48 hours.\n- Review event ID [4769](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769)\nrelated to this account and service name for additional information.\n\n### False positive analysis\n\n- A possible false positive can be identified if the script content is not malicious/harmful or does not request\nKerberos tickets for user accounts, as computer accounts are not vulnerable to Kerberoasting due to complex password\nrequirements and policy.\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",
+  "note": "## Triage and analysis\n\n### Investigating Explicit PowerShell Kerberos Ticket Request\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks, making\nit available for use in various environments, creating an attractive way for attackers to execute code.\n\nAccounts associated with a service principal name (SPN) are viable targets for Kerberoasting attacks, which use brute\nforce to crack the user password, which is used to encrypt a Kerberos TGS ticket.\n\nAttackers can use PowerShell to request these Kerberos tickets, with the intent of extracting them from memory to\nperform Kerberoasting.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate if the script was executed, and if so, which account was targeted.\n- Validate if the account has an SPN associated with it.\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- Check if the script has any other functionality that can be potentially malicious.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Review event ID [4769](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769)\nrelated to this account and service name for additional information.\n\n### False positive analysis\n\n- A possible false positive can be identified if the script content is not malicious/harmful or does not request\nKerberos tickets for user accounts, as computer accounts are not vulnerable to Kerberoasting due to complex password\nrequirements and policy.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services. Prioritize privileged accounts.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n    KerberosRequestorSecurityToken\n  )\n",
   "references": [
     "https://cobalt.io/blog/kerberoast-attack-techniques",
@@ -80,5 +80,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_relay_ntlm_auth_via_http_spoolss.json

@@ -0,0 +1,50 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Identifies attempt to coerce a local NTLM authentication via HTTP using the Windows Printer Spooler service as a target. An adversary may use this primitive in combination with other techniques to elevate privileges on a compromised system.",
+  "from": "now-9m",
+  "index": [
+    "winlogbeat-*",
+    "logs-endpoint.events.*",
+    "logs-windows.*"
+  ],
+  "language": "eql",
+  "license": "Elastic License v2",
+  "name": "Potential Local NTLM Relay via HTTP",
+  "query": "process where event.type in (\"start\", \"process_started\") and\n  process.name : \"rundll32.exe\" and\n  \n  /* Rundll32 WbeDav Client  */\n  process.args : (\"?:\\\\Windows\\\\System32\\\\davclnt.dll,DavSetCookie\", \"?:\\\\Windows\\\\SysWOW64\\\\davclnt.dll,DavSetCookie\") and \n  \n  /* Access to named pipe via http */\n  process.args : (\"http*/print/pipe/*\", \"http*/pipe/spoolss\", \"http*/pipe/srvsvc\")\n",
+  "references": [
+    "https://github.com/med0x2e/NTLMRelay2Self",
+    "https://github.com/topotam/PetitPotam",
+    "https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py"
+  ],
+  "risk_score": 73,
+  "rule_id": "4682fd2c-cfae-47ed-a543-9bed37657aa6",
+  "severity": "high",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Windows",
+    "Threat Detection",
+    "Credential Access"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0006",
+        "name": "Credential Access",
+        "reference": "https://attack.mitre.org/tactics/TA0006/"
+      },
+      "technique": [
+        {
+          "id": "T1212",
+          "name": "Exploitation for Credential Access",
+          "reference": "https://attack.mitre.org/techniques/T1212/"
+        }
+      ]
+    }
+  ],
+  "type": "eql",
+  "version": 1
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_remote_sam_secretsdump.json

@@ -2,7 +2,7 @@
   "author": [
     "Elastic"
   ],
-  "description": "Identifies remote access to the registry to potentially dump credential data from the SAM registry hive in preparation for credential access and privileges elevation.",
+  "description": "Identifies remote access to the registry to potentially dump credential data from the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation.",
   "from": "now-9m",
   "index": [
     "winlogbeat-*",
@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Potential Remote Credential Access via Registry",
-  "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",
+  "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 specifics of the involved assets, such as their role, criticality, and associated users.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Determine the privileges of the compromised accounts.\n- Investigate other alerts associated with the user/source host during the past 48 hours.\n- Investigate 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- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious\nmust be 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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Determine if other hosts were compromised.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Reimage the host operating system or restore the compromised files to clean versions.\n- Ensure that the machine has the latest security updates and is not running unsupported Windows versions.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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"
@@ -68,5 +68,5 @@
     }
   ],
   "type": "eql",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_saved_creds_vaultcmd.json

@@ -16,7 +16,7 @@
   "query": "process where event.type in (\"start\", \"process_started\") and\n  (process.pe.original_file_name:\"vaultcmd.exe\" or process.name:\"vaultcmd.exe\") and\n  process.args:\"/list*\"\n",
   "references": [
     "https://medium.com/threatpunter/detecting-adversary-tradecraft-with-image-load-event-logging-and-eql-8de93338c16",
-    "https://rastamouse.me/blog/rdp-jump-boxes/"
+    "https://web.archive.org/web/20201004080456/https://rastamouse.me/blog/rdp-jump-boxes/"
   ],
   "risk_score": 47,
   "rule_id": "be8afaed-4bcd-4e0a-b5f9-5562003dde81",
@@ -59,5 +59,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_seenabledelegationprivilege_assigned_to_user.json

@@ -11,7 +11,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "Sensitive Privilege SeEnableDelegationPrivilege assigned to a User",
-  "note": "## Triage and analysis\n\n### Investigating Sensitive Privilege SeEnableDelegationPrivilege assigned to a User\n\nKerberos delegation is an Active Directory feature that allows user and computer accounts to impersonate other accounts,\nact on their behalf, and use their privileges. Delegation (constrained and unconstrained) can be configured\nfor user and computer objects.\n\nEnabling unconstrained delegation for a computer causes the computer to store the ticket-granting ticket\n(TGT) in memory at any time an account connects to the computer, so it can be used by the computer for impersonation\nwhen needed. Risk is heightened if an attacker compromises computers with unconstrained delegation enabled, as they\ncould extract TGTs from memory and then replay them to move laterally on the domain. If the attacker coerces a privileged\nuser to connect to the server, or if the user does so routinely, the account will be compromised and the attacker will\nbe able to pass-the-ticket to privileged assets.\n\nSeEnableDelegationPrivilege is a user right that is controlled within the Local Security Policy of a domain controller\nand is managed through Group Policy. This setting is named **Enable computer and user accounts to be trusted for\ndelegation**.\n\nIt is critical to control the assignment of this privilege. A user with this privilege and write access to a computer\ncan control delegation settings, perform the attacks described above, and harvest TGTs from any user that connects to\nthe system. \n\n#### Possible investigation steps\n\n- Investigate how the privilege was assigned to the user and who assigned it.\n- Investigate other potentially malicious activity that was performed by the user that assigned the privileges using the\n`user.id` and `winlog.activity_id` fields as a filter during the past 48 hours.\n- Investigate other alerts associated with the involved accounts during the past 48 hours.\n\n### False positive analysis\n\n- The SeEnableDelegationPrivilege privilege should not be assigned to users. If this rule is triggered in your\nenvironment legitimately, the security team should notify the administrators about the risks of using it.\n\n### Related rules\n\n- KRBTGT Delegation Backdoor - e052c845-48d0-4f46-8a13-7d0aba05df82\n\n### Response and remediation\n\n- Immediate response should be taken to validate, investigate, and potentially contain the activity to prevent further\npost-compromise behavior.\n\n## Config\n\nThe 'Audit Authorization Policy Change' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policy Configuration >\nAudit Policies >\nPolicy Change >\nAudit Authorization Policy Change (Success,Failure)\n```\n",
+  "note": "## Triage and analysis\n\n### Investigating Sensitive Privilege SeEnableDelegationPrivilege assigned to a User\n\nKerberos delegation is an Active Directory feature that allows user and computer accounts to impersonate other accounts,\nact on their behalf, and use their privileges. Delegation (constrained and unconstrained) can be configured\nfor user and computer objects.\n\nEnabling unconstrained delegation for a computer causes the computer to store the ticket-granting ticket\n(TGT) in memory at any time an account connects to the computer, so it can be used by the computer for impersonation\nwhen needed. Risk is heightened if an attacker compromises computers with unconstrained delegation enabled, as they\ncould extract TGTs from memory and then replay them to move laterally on the domain. If the attacker coerces a privileged\nuser to connect to the server, or if the user does so routinely, the account will be compromised and the attacker will\nbe able to pass-the-ticket to privileged assets.\n\nSeEnableDelegationPrivilege is a user right that is controlled within the Local Security Policy of a domain controller\nand is managed through Group Policy. This setting is named **Enable computer and user accounts to be trusted for\ndelegation**.\n\nIt is critical to control the assignment of this privilege. A user with this privilege and write access to a computer\ncan control delegation settings, perform the attacks described above, and harvest TGTs from any user that connects to\nthe system. \n\n#### Possible investigation steps\n\n- Investigate how the privilege was assigned to the user and who assigned it.\n- Investigate other potentially malicious activity that was performed by the user that assigned the privileges using the\n`user.id` and `winlog.activity_id` fields as a filter during the past 48 hours.\n- Investigate other alerts associated with the users/host during the past 48 hours.\n\n### False positive analysis\n\n- The SeEnableDelegationPrivilege privilege should not be assigned to users. If this rule is triggered in your\nenvironment legitimately, the security team should notify the administrators about the risks of using it.\n\n### Related rules\n\n- KRBTGT Delegation Backdoor - e052c845-48d0-4f46-8a13-7d0aba05df82\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Remove the privilege from the account.\n- Review the privileges of the administrator account that performed the action.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'Audit Authorization Policy Change' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policy Configuration >\nAudit Policies >\nPolicy Change >\nAudit Authorization Policy Change (Success,Failure)\n```\n",
   "query": "event.action: \"Authorization Policy Change\" and event.code:4704 and winlog.event_data.PrivilegeList:\"SeEnableDelegationPrivilege\"\n",
   "references": [
     "https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/",
@@ -53,5 +53,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_spn_attribute_modified.json

@@ -2,7 +2,7 @@
   "author": [
     "Elastic"
   ],
-  "description": "Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure SPNs so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting.",
+  "description": "Detects when a user account has the servicePrincipalName attribute modified. Attackers can abuse write privileges over a user to configure Service Principle Names (SPNs) so that they can perform Kerberoasting. Administrators can also configure this for legitimate purposes, exposing the account to Kerberoasting.",
   "from": "now-9m",
   "index": [
     "winlogbeat-*",
@@ -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) 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",
+  "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 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 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 associated with the user/host during the past 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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services. Prioritize privileged accounts.\n- Isolate the involved hosts to prevent further post-compromise behavior.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 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",
@@ -58,5 +58,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_suspicious_winreg_access_via_sebackup_priv.json

@@ -2,7 +2,7 @@
   "author": [
     "Elastic"
   ],
-  "description": "Identifies remote access to the registry via an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials via dumping the SAM registry hive in preparation for credential access and privileges elevation.",
+  "description": "Identifies remote access to the registry using an account with Backup Operators group membership. This may indicate an attempt to exfiltrate credentials by dumping the Security Account Manager (SAM) registry hive in preparation for credential access and privileges elevation.",
   "from": "now-9m",
   "index": [
     "winlogbeat-*",
@@ -68,5 +68,5 @@
     }
   ],
   "type": "eql",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/credential_access_symbolic_link_to_shadow_copy_created.json

@@ -16,7 +16,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Symbolic Link to Shadow Copy Created",
-  "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",
+  "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- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Determine if a volume shadow copy was recently created on this endpoint.\n- Review privileges 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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\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- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -53,5 +53,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_adding_the_hidden_file_attribute_with_via_attribexe.json

@@ -61,5 +61,5 @@
   "timeline_title": "Comprehensive Process Timeline",
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 11
+  "version": 13
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_amsienable_key_mod.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Modification of AmsiEnable Registry Key",
-  "note": "## Triage and analysis\n\n### Investigating Modification of AmsiEnable Registry Key\n\nThe Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and\nservices to integrate with any antimalware product that's present on a machine. AMSI provides integration with multiple\nWindows components, ranging from User Account Control (UAC) to VBA Macros.\n\nSince AMSI is widely used across security products for increased visibility, attackers can disable it to evade\ndetections that rely on it.\n\nThis rule monitors the modifications to the Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable registry key.\n\n#### Possible investigation steps\n\n- Identify the user that performed the action.\n- Check whether this user should be doing this kind of activity.\n- Investigate program execution chain (parent process tree).\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Investigate the execution of scripts and macros after the registry modification.\n- Retrieve script/office files:\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 of this file in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Use process name, command line, and file hash to search for occurrences on other hosts.\n\n### False positive analysis\n\n- This modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and\nmonitored by the security team, as these modifications expose the host to malware infections.\n\n### Related rules\n\n- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3\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 malware was found, implement temporary network rules, procedures, and segmentation required to contain it.\n- Delete or set the key to its default value.\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 Modification of AmsiEnable Registry Key\n\nThe Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and\nservices to integrate with any antimalware product that's present on a machine. AMSI provides integration with multiple\nWindows components, ranging from User Account Control (UAC) to VBA Macros.\n\nSince AMSI is widely used across security products for increased visibility, attackers can disable it to evade\ndetections that rely on it.\n\nThis rule monitors the modifications to the Software\\Microsoft\\Windows Script\\Settings\\AmsiEnable registry key.\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- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate the execution of scripts and macros after the registry modification.\n- Retrieve scripts or Microsoft Office files and determine if they are 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n- Use process name, command line, and file hash to search for occurrences on other hosts.\n\n### False positive analysis\n\n- This modification should not happen legitimately. Any potential benign true positive (B-TP) should be mapped and\nmonitored by the security team, as these modifications expose the host to malware infections.\n\n### Related rules\n\n- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3\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 triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Delete or set the key to its default value.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 : (\n    \"HKEY_USERS\\\\*\\\\Software\\\\Microsoft\\\\Windows Script\\\\Settings\\\\AmsiEnable\",\n    \"HKU\\\\*\\\\Software\\\\Microsoft\\\\Windows Script\\\\Settings\\\\AmsiEnable\"\n  ) and\n  registry.data.strings: (\"0\", \"0x00000000\")\n",
   "references": [
     "https://hackinparis.com/data/slides/2019/talks/HIP2019-Dominic_Chell-Cracking_The_Perimeter_With_Sharpshooter.pdf",
@@ -54,5 +54,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_attempt_to_disable_gatekeeper.json

@@ -14,7 +14,7 @@
   "query": "event.category:process and event.type:(start or process_started) and \n  process.args:(spctl and \"--master-disable\")\n",
   "references": [
     "https://support.apple.com/en-us/HT202491",
-    "https://www.carbonblack.com/blog/tau-threat-intelligence-notification-new-macos-malware-variant-of-shlayer-osx-discovered/"
+    "https://community.carbonblack.com/t5/Threat-Advisories-Documents/TAU-TIN-Shlayer-OSX/ta-p/68397"
   ],
   "risk_score": 47,
   "rule_id": "4da13d6e-904f-4636-81d8-6ab14b4e6ae9",
@@ -45,5 +45,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_clearing_windows_console_history.json

@@ -12,10 +12,10 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Clearing Windows Console History",
-  "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 Clearing Windows Console History\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can try to cover their tracks by clearing PowerShell console history. PowerShell has two different ways of\nlogging commands: the built-in history and the command history managed by the PSReadLine module. This rule looks for the\nexecution of commands that can clear the built-in PowerShell logs or delete the `ConsoleHost_history.txt` file.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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  - Verify if any other anti-forensics behaviors were observed.\n- Investigate the PowerShell logs on the SIEM to determine if there was suspicious behavior that an attacker may be\ntrying to cover up.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n  - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility.\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.action == \"start\" and\n  (process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") or process.pe.original_file_name == \"PowerShell.EXE\") and\n     (process.args : \"*Clear-History*\" or\n     (process.args : (\"*Remove-Item*\", \"rm\") and process.args : (\"*ConsoleHost_history.txt*\", \"*(Get-PSReadlineOption).HistorySavePath*\")) or\n     (process.args : \"*Set-PSReadlineOption*\" and process.args : \"*SaveNothing*\"))\n",
   "references": [
-    "https://stefanos.cloud/blog/kb/how-to-clear-the-powershell-command-history/",
+    "https://stefanos.cloud/kb/how-to-clear-the-powershell-command-history/",
     "https://www.shellhacks.com/clear-history-powershell/",
     "https://community.sophos.com/sophos-labs/b/blog/posts/powershell-command-history-forensics"
   ],
@@ -55,5 +55,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_clearing_windows_event_logs.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Clearing Windows Event Logs",
-  "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 Clearing Windows Event Logs\n\nWindows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries\ncan tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response.\n\nThis rule looks for the execution of the `wevtutil.exe` utility or the `Clear-EventLog` cmdlet to clear event logs.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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  - Verify if any other anti-forensics behaviors were observed.\n- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up.\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 action.\n- Analyze whether the cleared event log is pertinent to security and general monitoring. Administrators can clear\nnon-relevant event logs using this mechanism. If this activity is expected and noisy in your environment, consider\nadding exceptions \u2014 preferably with a combination of 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  - This activity is potentially done after the adversary achieves its objectives on the host. Ensure that previous\n  actions, if any, are investigated accordingly with their response playbooks.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 (\"process_started\", \"start\") and\n  (process.name : \"wevtutil.exe\" or process.pe.original_file_name == \"wevtutil.exe\") and\n    process.args : (\"/e:false\", \"cl\", \"clear-log\") or\n  process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") and process.args : \"Clear-EventLog\"\n",
   "risk_score": 21,
   "rule_id": "d331bbe2-6db4-4941-80a5-8270db72eb61",
@@ -50,5 +50,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 12
+  "version": 13
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_clearing_windows_security_logs.json

@@ -12,6 +12,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "Windows Event Logs Cleared",
+  "note": "## Triage and analysis\n\n### Investigating Windows Event Logs Cleared\n\nWindows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries\ncan tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response.\n\nThis rule looks for the occurrence of clear actions on the `security` event log.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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  - Verify if any other anti-forensics behaviors were observed.\n- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up.\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  - This activity is potentially done after the adversary achieves its objectives on the host. Ensure that previous\n  actions, if any, are investigated accordingly with their response playbooks.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n",
   "query": "event.action:(\"audit-log-cleared\" or \"Log clear\")\n",
   "risk_score": 21,
   "rule_id": "45ac4800-840f-414c-b221-53dd36a5aaf7",
@@ -49,5 +50,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_code_injection_conhost.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Suspicious Process from Conhost",
-  "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 Suspicious Process from Conhost\n\nThe Windows Console Host, or `conhost.exe`, is both the server application for all of the Windows Console APIs as well as\nthe classic Windows user interface for working with command-line applications.\n\nThe `conhost.exe` process doesn't normally have child processes. Any processes spawned by the `conhost.exe` process can indicate code\ninjection activity or a suspicious process masquerading as the `conhost.exe` process.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file\nmodifications, and any spawned child processes.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.\n- Retrieve the process executable 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n\n### Related rules\n\n- Conhost Spawned By Suspicious Parent Process - 05b358de-aa6d-4f6c-89e6-78f74018b43b\n- Suspicious PowerShell Engine ImageLoad - 852c1f19-68e8-43a6-9dce-340771fe1be3\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 hosts to prevent further post-compromise behavior.\n- If the triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 : \"conhost.exe\" and\n  not process.executable : (\"?:\\\\Windows\\\\splwow64.exe\", \"?:\\\\Windows\\\\System32\\\\WerFault.exe\", \"?:\\\\Windows\\\\System32\\\\conhost.exe\")\n",
   "references": [
     "https://modexp.wordpress.com/2018/09/12/process-injection-user-data/",
@@ -47,5 +47,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_defender_disabled_via_registry.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Windows Defender Disabled via Registry Modification",
-  "note": "## Triage and analysis\n\nDetections should be investigated to identify if the hosts and users are authorized to use this tool. As this rule detects post-exploitation process activity, investigations into this should be prioritized.\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 Disabled via Registry Modification\n\nMicrosoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple\nenvironments. Disabling it is a common step in threat actor playbooks.\n\nThis rule monitors the registry for configurations that disable Windows Defender or the start of its service.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate\nsoftware installations.\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 if this operation is done under change management and approved according to the organization's policy.\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,\nthe configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting),\nand no other suspicious activity has been observed.\n\n### Related rules\n\n- Disabling Windows Defender Security Settings via PowerShell - c8cccb06-faf2-4cd5-886e-2c9636cfcb87\n- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Re-enable Windows Defender and restore the service configurations to automatic start.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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  (\n    (\n      registry.path:\"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\DisableAntiSpyware\" and\n      registry.data.strings: (\"1\", \"0x00000001\")\n   ) or\n   (\n      registry.path:\"HKLM\\\\System\\\\*ControlSet*\\\\Services\\\\WinDefend\\\\Start\" and\n      registry.data.strings in (\"3\", \"4\", \"0x00000003\", \"0x00000004\")\n   )\n  )\n",
   "references": [
     "https://thedfirreport.com/2020/12/13/defender-control/"
@@ -58,5 +58,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_defender_exclusion_via_powershell.json

@@ -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 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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n- If the exclusion specifies a suspicious file or path, retrieve the file(s) and determine if 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Exclusion lists for antimalware capabilities should always be routinely monitored for review.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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"
@@ -80,5 +80,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_deletion_of_bash_command_line_history.json

@@ -12,7 +12,7 @@
   "license": "Elastic License v2",
   "name": "Tampering of Bash Command-Line History",
   "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 (\n  (process.args : (\"rm\", \"echo\") and process.args : (\".bash_history\", \"/root/.bash_history\", \"/home/*/.bash_history\")) or\n  (process.name : \"history\" and process.args : \"-c\") or\n  (process.args : \"export\" and process.args : (\"HISTFILE=/dev/null\", \"HISTFILESIZE=0\")) or\n  (process.args : \"unset\" and process.args : \"HISTFILE\") or\n  (process.args : \"set\" and process.args : \"history\" and process.args : \"+o\")\n )\n",
+  "query": "process where event.type in (\"start\", \"process_started\") and\n (\n  ((process.args : (\"rm\", \"echo\") or\n    (process.args : \"ln\" and process.args : \"-sf\" and process.args : \"/dev/null\") or\n    (process.args : \"truncate\" and process.args : \"-s0\"))\n    and process.args : (\".bash_history\", \"/root/.bash_history\", \"/home/*/.bash_history\",\"/Users/.bash_history\", \"/Users/*/.bash_history\",\n                        \".zsh_history\", \"/root/.zsh_history\", \"/home/*/.zsh_history\", \"/Users/.zsh_history\", \"/Users/*/.zsh_history\")) or\n  (process.name : \"history\" and process.args : \"-c\") or\n  (process.args : \"export\" and process.args : (\"HISTFILE=/dev/null\", \"HISTFILESIZE=0\")) or\n  (process.args : \"unset\" and process.args : \"HISTFILE\") or\n  (process.args : \"set\" and process.args : \"history\" and process.args : \"+o\")\n )\n",
   "risk_score": 47,
   "rule_id": "7bcbb3ac-e533-41ad-a612-d6c3bf666aba",
   "severity": "medium",
@@ -20,6 +20,7 @@
     "Elastic",
     "Host",
     "Linux",
+    "macOS",
     "Threat Detection",
     "Defense Evasion"
   ],
@@ -49,5 +50,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_disable_posh_scriptblocklogging.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "PowerShell Script Block Logging Disabled",
-  "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",
+  "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 that performed the action and whether it should perform this kind of action.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Check whether it makes sense for the user to use PowerShell to complete 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- Suspicious .NET Reflection via PowerShell - 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- Isolate the involved hosts to prevent further post-compromise behavior.\n- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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"
@@ -53,5 +53,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_disable_windows_firewall_rules_with_netsh.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Disable Windows Firewall Rules via Netsh",
-  "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",
+  "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 the Windows firewall or its rules to enable lateral movement and command and control activity.\n\nThis rule identifies patterns related to disabling the Windows firewall or its rules using the `netsh.exe` utility.\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 user to check if they are aware of the operation.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing\ntroubleshooting.\n- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall.\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- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -50,5 +50,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 11
+  "version": 12
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_disabling_windows_defender_powershell.json

@@ -15,7 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Disabling Windows Defender Security Settings via 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 Disabling Windows Defender Security Settings via PowerShell\n\nMicrosoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple\nenvironments. Disabling it is a common step in threat actor playbooks.\n\nThis rule monitors the execution of commands that can tamper the Windows Defender antivirus features.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate\nsoftware installations.\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- Examine the command line to determine which action was executed. Based on that, examine exceptions, antivirus state,\nsample submission, etc.\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,\nthe configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting),\nand no other suspicious activity has been observed.\n\n### Related rules\n\n- Windows Defender Disabled via Registry Modification - 2ffa1f1e-b6db-47fa-994b-1512743847eb\n- Microsoft Windows Defender Tampering - fe794edd-487f-4a90-b285-3ee54f2af2d3\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Based on the command line, take actions to restore the appropriate Windows Defender antivirus configurations.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 : \"Set-MpPreference\" and process.args : (\"-Disable*\", \"Disabled\", \"NeverSend\", \"-Exclusion*\")\n",
   "references": [
     "https://docs.microsoft.com/en-us/powershell/module/defender/set-mppreference?view=windowsserver2019-ps"
@@ -56,5 +56,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_disabling_windows_logs.json

@@ -14,10 +14,11 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Disable Windows Event and Security Logs Using Built-in Tools",
-  "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 Event and Security Logs Using Built-in Tools\n\nWindows event logs are a fundamental data source for security monitoring, forensics, and incident response. Adversaries\ncan tamper, clear, and delete this data to break SIEM detections, cover their tracks, and slow down incident response.\n\nThis rule looks for the usage of different utilities to disable the EventLog service or specific event logs.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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  - Verify if any other anti-forensics behaviors were observed.\n- Investigate the event logs prior to the action for suspicious behaviors that an attacker may be trying to cover up.\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- Re-enable affected logging components, services, and security monitoring.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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\n  ((process.name:\"logman.exe\" or process.pe.original_file_name == \"Logman.exe\") and\n      process.args : \"EventLog-*\" and process.args : (\"stop\", \"delete\")) or\n\n  ((process.name : (\"pwsh.exe\", \"powershell.exe\", \"powershell_ise.exe\") or process.pe.original_file_name in\n      (\"pwsh.exe\", \"powershell.exe\", \"powershell_ise.exe\")) and\n\tprocess.args : \"Set-Service\" and process.args: \"EventLog\" and process.args : \"Disabled\")  or\n\t\n  ((process.name:\"auditpol.exe\" or process.pe.original_file_name == \"AUDITPOL.EXE\") and process.args : \"/success:disable\")\n",
   "references": [
-    "https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/logman"
+    "https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/logman",
+    "https://medium.com/palantir/tampering-with-windows-event-tracing-background-offense-and-defense-4be7ac62ac63"
   ],
   "risk_score": 21,
   "rule_id": "4de76544-f0e5-486a-8f84-eae0b6063cdc",
@@ -49,11 +50,23 @@
               "reference": "https://attack.mitre.org/techniques/T1070/001/"
             }
           ]
+        },
+        {
+          "id": "T1562",
+          "name": "Impair Defenses",
+          "reference": "https://attack.mitre.org/techniques/T1562/",
+          "subtechnique": [
+            {
+              "id": "T1562.006",
+              "name": "Indicator Blocking",
+              "reference": "https://attack.mitre.org/techniques/T1562/006/"
+            }
+          ]
         }
       ]
     }
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_elastic_agent_service_terminated.json

@@ -0,0 +1,54 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Identifies the Elastic endpoint agent has stopped and is no longer running on the host. Adversaries may attempt to disable security monitoring tools in an attempt to evade detection or prevention capabilities during an intrusion. This may also indicate an issue with the agent itself and should be addressed to ensure defensive measures are back in a stable state.",
+  "from": "now-9m",
+  "index": [
+    "logs-*"
+  ],
+  "language": "eql",
+  "license": "Elastic License v2",
+  "name": "Elastic Agent Service Terminated",
+  "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\n/* net, sc or wmic stopping or deleting Elastic Agent on Windows */\n(event.type == \"start\" and\n  process.name : (\"net.exe\", \"sc.exe\", \"wmic.exe\",\"powershell.exe\",\"taskkill.exe\",\"PsKill.exe\",\"ProcessHacker.exe\") and \n  process.args : (\"stopservice\",\"uninstall\", \"stop\", \"disabled\",\"Stop-Process\",\"terminate\",\"suspend\") and\n  process.args : (\"elasticendpoint\", \"Elastic Agent\",\"elastic-agent\",\"elastic-endpoint\")) \nor\n/* service or systemctl used to stop Elastic Agent on Linux */\n(event.type == \"end\" and\n  (process.name : (\"systemctl\",\"service\") and \n    process.args : (\"elastic-agent\", \"stop\")) \n  or \n  /* Unload Elastic Agent extension on MacOS */\n  (process.name : \"kextunload\" and\n    process.args : \"com.apple.iokit.EndpointSecurity\" and \n    event.action : \"end\"))\n",
+  "risk_score": 47,
+  "rule_id": "b627cd12-dac4-11ec-9582-f661ea17fbcd",
+  "severity": "medium",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Linux",
+    "Windows",
+    "macOS",
+    "Threat Detection",
+    "Defense Evasion"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0005",
+        "name": "Defense Evasion",
+        "reference": "https://attack.mitre.org/tactics/TA0005/"
+      },
+      "technique": [
+        {
+          "id": "T1562",
+          "name": "Impair Defenses",
+          "reference": "https://attack.mitre.org/techniques/T1562/",
+          "subtechnique": [
+            {
+              "id": "T1562.001",
+              "name": "Disable or Modify Tools",
+              "reference": "https://attack.mitre.org/techniques/T1562/001/"
+            }
+          ]
+        }
+      ]
+    }
+  ],
+  "timestamp_override": "event.ingested",
+  "type": "eql",
+  "version": 1
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_enable_inbound_rdp_with_netsh.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "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",
+  "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 that 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 process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 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- 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- Isolate the involved hosts to prevent further post-compromise behavior.\n- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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",
@@ -50,5 +50,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_enable_network_discovery_with_netsh.json

@@ -15,7 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Enable Host Network Discovery 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 Enable Host Network Discovery via Netsh\n\nThe Windows Defender Firewall is a native component that 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 enable Network Discovery on the Windows firewall to find other systems present in the same network. Systems\nwith this setting enabled will communicate with other systems using broadcast messages, which can be used to identify\ntargets for lateral movement. This rule looks for the setup of this setting using the netsh utility.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.\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\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- Disable Network Discovery:\n    - Using netsh: `netsh advfirewall firewall set rule group=\"Network Discovery\" new enable=No`\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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\nprocess.name : \"netsh.exe\" and\nprocess.args : (\"firewall\", \"advfirewall\") and process.args : \"group=Network Discovery\" and process.args : \"enable=Yes\"\n",
   "risk_score": 47,
   "rule_id": "8b4f0816-6a65-4630-86a6-c21c179c0d09",
@@ -53,5 +53,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_execution_lolbas_wuauclt.json

@@ -48,5 +48,5 @@
   "timeline_title": "Comprehensive Process Timeline",
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 7
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_microsoft_defender_tampering.json

@@ -15,7 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Microsoft Windows Defender Tampering",
-  "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 Microsoft Windows Defender Tampering\n\nMicrosoft Windows Defender is an antivirus product built into Microsoft Windows, which makes it popular across multiple\nenvironments. Disabling it is a common step in threat actor playbooks.\n\nThis rule monitors the registry for modifications that disable Windows Defender features.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate\nsoftware installations.\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- Examine which features have been disabled, and check if this operation is done under change management and approved\naccording to the organization's policy.\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,\nthe configuration is justified (for example, it is being used to deploy other security solutions or troubleshooting),\nand no other suspicious activity has been observed.\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 hosts to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Take actions to restore the appropriate Windows Defender antivirus configurations.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\PUAProtection\" and\n  registry.data.strings : (\"0\", \"0x00000000\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender Security Center\\\\App and Browser protection\\\\DisallowExploitProtectionOverride\" and\n  registry.data.strings : (\"0\", \"0x00000000\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\DisableAntiSpyware\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Features\\\\TamperProtection\" and\n  registry.data.strings : (\"0\", \"0x00000000\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Real-Time Protection\\\\DisableRealtimeMonitoring\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Real-Time Protection\\\\DisableIntrusionPreventionSystem\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Real-Time Protection\\\\DisableScriptScanning\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Windows Defender Exploit Guard\\\\Controlled Folder Access\\\\EnableControlledFolderAccess\" and\n  registry.data.strings : (\"0\", \"0x00000000\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Real-Time Protection\\\\DisableIOAVProtection\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Reporting\\\\DisableEnhancedNotifications\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\SpyNet\\\\DisableBlockAtFirstSeen\" and\n  registry.data.strings : (\"1\", \"0x00000001\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\SpyNet\\\\SpynetReporting\" and\n  registry.data.strings : (\"0\", \"0x00000000\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\SpyNet\\\\SubmitSamplesConsent\" and\n  registry.data.strings : (\"0\", \"0x00000000\")) or\n  (registry.path : \"HKLM\\\\SOFTWARE\\\\Policies\\\\Microsoft\\\\Windows Defender\\\\Real-Time Protection\\\\DisableBehaviorMonitoring\" and\n  registry.data.strings : (\"1\", \"0x00000001\"))\n",
   "references": [
     "https://thedfirreport.com/2021/10/18/icedid-to-xinglocker-ransomware-in-24-hours/",
@@ -56,5 +56,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_ms_office_suspicious_regmod.json

@@ -11,7 +11,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "MS Office Macro Security Registry Modifications",
-  "note": "## Triage and analysis\n\n### Investigating MS Office Macro Security Registry Modifications\n\nMacros are small programs that are used to automate repetitive tasks in Microsoft Office applications.\nHistorically, macros have been used for a variety of reasons -- from automating part of a job, to\nbuilding entire processes and data flows. Macros are written in Visual Basic for Applications (VBA) and are saved as\npart of Microsoft Office files.\n\nMacros are often created for legitimate reasons, but they can also be written by attackers to gain access, harm a\nsystem, or bypass other security controls such as application allow listing. In fact, exploitation from malicious macros\nis one of the top ways that organizations are compromised today. These attacks are often conducted through phishing or\nspear phishing campaigns.\n\nAttackers can convince victims to modify Microsoft Office security settings, so their macros are trusted by default and\nno warnings are displayed when they are executed. These settings include:\n\n* *Trust access to the VBA project object model* - When enabled, Microsoft Office will trust all macros and run any code\nwithout showing a security warning or requiring user permission.\n* *VbaWarnings* - When set to 1, Microsoft Office will trust all macros and run any code without showing a security\nwarning or requiring user permission.\n\nThis rule looks for registry changes affecting the conditions above.\n\n#### Possible investigation steps\n\n- Identify the user that performed the operation.\n- Verify whether malicious macros were executed after the registry change.\n- Contact the user and check if the change was done manually.\n- Investigate other alerts associated with the user during the past 48 hours.\n\n### False positive analysis\n\n- This activity should not happen legitimately. The security team should address any potential benign true\npositives (B-TPs), 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- Reset the registry key value.\n- Isolate the host if malicious code was executed and reset the involved account's passwords.\n- Explore using GPOs to manage security settings for Microsoft Office macros.\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 MS Office Macro Security Registry Modifications\n\nMacros are small programs that are used to automate repetitive tasks in Microsoft Office applications.\nHistorically, macros have been used for a variety of reasons -- from automating part of a job, to\nbuilding entire processes and data flows. Macros are written in Visual Basic for Applications (VBA) and are saved as\npart of Microsoft Office files.\n\nMacros are often created for legitimate reasons, but they can also be written by attackers to gain access, harm a\nsystem, or bypass other security controls such as application allow listing. In fact, exploitation from malicious macros\nis one of the top ways that organizations are compromised today. These attacks are often conducted through phishing or\nspear phishing campaigns.\n\nAttackers can convince victims to modify Microsoft Office security settings, so their macros are trusted by default and\nno warnings are displayed when they are executed. These settings include:\n\n* *Trust access to the VBA project object model* - When enabled, Microsoft Office will trust all macros and run any code\nwithout showing a security warning or requiring user permission.\n* *VbaWarnings* - When set to 1, Microsoft Office will trust all macros and run any code without showing a security\nwarning or requiring user permission.\n\nThis rule looks for registry changes affecting the conditions above.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Contact the user and check if the change was done manually.\n- Verify whether malicious macros were executed after the registry change.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Retrieve recently executed Office documents and determine if they are 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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\npositives (B-TPs), 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- Reset the registry key value.\n- Isolate the involved host to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Explore using GPOs to manage security settings for Microsoft Office macros.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 event.type == \"change\" and\n    registry.path : (\n        \"HKU\\\\S-1-5-21-*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Security\\\\AccessVBOM\",\n        \"HKU\\\\S-1-5-21-*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Security\\\\VbaWarnings\"\n        ) and \n    registry.data.strings == \"0x00000001\" and\n    process.name : (\"cscript.exe\", \"wscript.exe\", \"mshta.exe\", \"mshta.exe\", \"winword.exe\", \"excel.exe\")\n",
   "risk_score": 47,
   "rule_id": "feeed87c-5e95-4339-aef1-47fd79bcfbe3",
@@ -64,5 +64,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_posh_assembly_load.json

@@ -11,6 +11,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "Suspicious .NET Reflection via PowerShell",
+  "note": "## Triage and analysis\n\n### Investigating Suspicious .NET Reflection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script,\nwhich can circumvent file-based security protections.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Retrieve the script 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 outside engineering or IT business units. As long as the analyst did\nnot identify malware or suspicious activity related to the user or host, this alert can be dismissed.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- PowerShell Suspicious Payload Encoded and Compressed - 81fe9dc6-a2d7-4192-a2d8-eed98afc766a\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 triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n    \"[System.Reflection.Assembly]::Load\" or\n    \"[Reflection.Assembly]::Load\"\n  )\n",
   "references": [
     "https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.load"
@@ -78,5 +79,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_posh_compressed.json

@@ -14,6 +14,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell Suspicious Payload Encoded and Compressed",
+  "note": "## Triage and analysis\n\n### Investigating PowerShell Suspicious Payload Encoded and Compressed\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can embed compressed and encoded payloads in scripts to load directly into the memory without touching the\ndisk. This strategy can circumvent string and file-based security protections.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Retrieve the script 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 files' SHA-256 hash values.\n    - Search for the existence and reputation of the hashes 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 outside engineering or IT business units. As long as the analyst did\nnot identify malware or suspicious activity related to the user or host, this alert can be dismissed.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n- Potential Process Injection via PowerShell - 2e29e96a-b67c-455a-afe4-de6183431d0d\n- Suspicious .NET Reflection via PowerShell - e26f042e-c590-4e82-8e05-41e81bd822ad\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 triage identified malware, search the environment for additional compromised hosts.\n  - Implement temporary network rules, procedures, and segmentation to contain the malware.\n  - Stop suspicious processes.\n  - Immediately block the identified indicators of compromise (IoCs).\n  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that\n  attackers could use to reinfect the system.\n- Remove and block malicious artifacts identified during triage.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n    (\n      \"System.IO.Compression.DeflateStream\" or\n      \"System.IO.Compression.GzipStream\" or\n      \"IO.Compression.DeflateStream\" or\n      \"IO.Compression.GzipStream\"\n    ) and\n    FromBase64String\n  )\n",
   "risk_score": 47,
   "rule_id": "81fe9dc6-a2d7-4192-a2d8-eed98afc766a",
@@ -71,5 +72,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_posh_process_injection.json

@@ -14,7 +14,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "Potential Process Injection via PowerShell",
-  "note": "## Triage and analysis.\n\n### Investigating Potential Process Injection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nPowerShell also has solid capabilities to make the interaction with the Win32 API in an uncomplicated and reliable way,\nlike the execution of inline C# code, PSReflect, Get-ProcAddress, etc.\n\nRed Team tooling and malware developers take advantage of these capabilities to develop stagers and loaders that inject\npayloads directly into the memory without touching the disk to circumvent file-based security protections.\n\n#### Possible investigation steps\n\n- Examine script content that triggered the detection. \n- Investigate the script execution chain (parent process tree).\n- Inspect any file or network events from the suspicious PowerShell host process instance.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Check if the imported function was executed and which process it targeted.\n- Check if the injected code can be retrieved (hardcoded in the script or on command line logs).\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 PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- Quarantine the involved host for forensic investigation, as well as eradication and recovery activities.\n- Configure AppLocker or equivalent software to restrict access to PowerShell for regular users.\n- Reset the password for the user account.\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
+  "note": "## Triage and analysis\n\n### Investigating Potential Process Injection via PowerShell\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nPowerShell also has solid capabilities to make the interaction with the Win32 API in an uncomplicated and reliable way,\nlike the execution of inline C# code, PSReflect, Get-ProcAddress, etc.\n\nRed Team tooling and malware developers take advantage of these capabilities to develop stagers and loaders that inject\npayloads directly into the memory without touching the disk to circumvent file-based security protections.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Check if the imported function was executed and which process it targeted.\n- Check if the injected code can be retrieved (hardcoded in the script or on command line logs).\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 PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\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- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n   (VirtualAlloc or VirtualAllocEx or VirtualProtect or LdrLoadDll or LoadLibrary or LoadLibraryA or\n      LoadLibraryEx or GetProcAddress or OpenProcess or OpenProcessToken or AdjustTokenPrivileges) and\n   (WriteProcessMemory or CreateRemoteThread or NtCreateThreadEx or CreateThread or QueueUserAPC or\n      SuspendThread or ResumeThread or GetDelegateForFunctionPointer)\n  )\n",
   "references": [
     "https://github.com/EmpireProject/Empire/blob/master/data/module_source/management/Invoke-PSInject.ps1",
@@ -62,5 +62,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_powershell_windows_firewall_disabled.json

@@ -15,7 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Windows Firewall Disabled via 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 Firewall Disabled via PowerShell\n\nWindows Defender Firewall is a native component that 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 the Windows firewall or its rules to enable lateral movement and command and control activity.\n\nThis rule identifies patterns related to disabling the Windows firewall or its rules using the `Set-NetFirewallProfile`\nPowerShell cmdlet.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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- Inspect the host for suspicious or abnormal behaviors in the alert timeframe.\n\n### False positive analysis\n\n- This mechanism can be used legitimately. Check whether the user is an administrator and is legitimately performing\ntroubleshooting.\n- In case of an allowed benign true positive (B-TP), assess adding rules to allow needed traffic and re-enable the firewall.\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- Re-enable the firewall with its desired configurations.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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.action == \"start\" and\n  (process.name : (\"powershell.exe\", \"pwsh.exe\", \"powershell_ise.exe\") or process.pe.original_file_name == \"PowerShell.EXE\") and\n   process.args : \"*Set-NetFirewallProfile*\" and\n  (process.args : \"*-Enabled*\" and process.args : \"*False*\") and\n  (process.args : \"*-All*\" or process.args : (\"*Public*\", \"*Domain*\", \"*Private*\"))\n",
   "references": [
     "https://docs.microsoft.com/en-us/powershell/module/netsecurity/set-netfirewallprofile?view=windowsserver2019-ps",
@@ -59,5 +59,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.json

@@ -14,7 +14,7 @@
   "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.name:\"scp\" and\n process.args:\"StrictHostKeyChecking=no\" and \n process.command_line:(\"scp *localhost:/*\", \"scp *127.0.0.1:/*\") and\n not process.args:\"vagrant@*127.0.0.1*\"\n",
   "references": [
-    "https://blog.trendmicro.com/trendlabs-security-intelligence/xcsset-mac-malware-infects-xcode-projects-performs-uxss-attack-on-safari-other-browsers-leverages-zero-day-exploits/"
+    "https://www.trendmicro.com/en_us/research/20/h/xcsset-mac-malware--infects-xcode-projects--uses-0-days.html"
   ],
   "risk_score": 73,
   "rule_id": "c02c8b9f-5e1d-463c-a1b0-04edcdfe1a3d",
@@ -61,5 +61,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 2
+  "version": 3
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_proxy_execution_via_msdt.json

@@ -0,0 +1,50 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Identifies potential abuse of the Microsoft Diagnostics Troubleshooting Wizard (MSDT) to proxy malicious command or binary execution via malicious process arguments.",
+  "from": "now-9m",
+  "index": [
+    "logs-endpoint.events.*",
+    "winlogbeat-*",
+    "logs-windows.*"
+  ],
+  "language": "eql",
+  "license": "Elastic License v2",
+  "name": "Suspicious Microsoft Diagnostics Wizard Execution",
+  "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.pe.original_file_name == \"msdt.exe\" or process.name : \"msdt.exe\") and\n   (\n    process.args : (\"IT_RebrowseForFile=*\", \"ms-msdt:/id\", \"ms-msdt:-id\", \"*FromBase64*\") or\n\n    (process.args : \"-af\" and process.args : \"/skip\" and \n     process.parent.name : (\"explorer.exe\", \"cmd.exe\", \"powershell.exe\", \"cscript.exe\", \"wscript.exe\", \"mshta.exe\", \"rundll32.exe\", \"regsvr32.exe\") and\n     process.args : (\"?:\\\\WINDOWS\\\\diagnostics\\\\index\\\\PCWDiagnostic.xml\", \"PCWDiagnostic.xml\", \"?:\\\\Users\\\\Public\\\\*\", \"?:\\\\Windows\\\\Temp\\\\*\")) or\n\n    (process.pe.original_file_name == \"msdt.exe\" and not process.name : \"msdt.exe\" and process.name != null) or\n\n    (process.pe.original_file_name == \"msdt.exe\" and not process.executable : (\"?:\\\\Windows\\\\system32\\\\msdt.exe\", \"?:\\\\Windows\\\\SysWOW64\\\\msdt.exe\"))\n    )\n",
+  "references": [
+    "https://twitter.com/nao_sec/status/1530196847679401984",
+    "https://lolbas-project.github.io/lolbas/Binaries/Msdt/"
+  ],
+  "risk_score": 73,
+  "rule_id": "2c3c29a4-f170-42f8-a3d8-2ceebc18eb6a",
+  "severity": "high",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Windows",
+    "Threat Detection",
+    "Defense Evasion"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0005",
+        "name": "Defense Evasion",
+        "reference": "https://attack.mitre.org/tactics/TA0005/"
+      },
+      "technique": [
+        {
+          "id": "T1218",
+          "name": "Signed Binary Proxy Execution",
+          "reference": "https://attack.mitre.org/techniques/T1218/"
+        }
+      ]
+    }
+  ],
+  "type": "eql",
+  "version": 1
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_suspicious_certutil_commands.json

@@ -52,5 +52,5 @@
   "timeline_title": "Comprehensive Process Timeline",
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 12
+  "version": 14
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_whitespace_padding_in_command_line.json

@@ -13,7 +13,7 @@
   "license": "Elastic License v2",
   "name": "Whitespace Padding in Process Command Line",
   "note": "## Triage and analysis\n\n- Analyze the command line of the process in question for evidence of malicious code execution.\n- Review the ancestor and child processes spawned by the process in question for indicators of further malicious code execution.\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.command_line regex \".*[ ]{20,}.*\" or \n  \n  /* this will match on 3 or more separate occurrences of 5+ contiguous whitespace characters */\n  process.command_line regex \".*(.*[ ]{5,}[^ ]*){3,}.*\"\n",
+  "query": "process where event.type in (\"start\", \"process_started\") and\n  process.command_line regex \".*[ ]{20,}.*\" or \n  \n  /* this will match on 3 or more separate occurrences of 3+ contiguous whitespace characters */\n  process.command_line regex \"([^ ]+[ ]{3,}[^ ]*){3,}.*\"\n",
   "references": [
     "https://twitter.com/JohnLaTwC/status/1419251082736201737"
   ],
@@ -40,5 +40,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 8
+  "version": 9
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/defense_evasion_workfolders_control_execution.json

@@ -11,8 +11,8 @@
   ],
   "language": "eql",
   "license": "Elastic License v2",
-  "name": "Signed Proxy Execution via MS WorkFolders",
-  "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",
+  "name": "Signed Proxy Execution via MS Work Folders",
+  "note": "## Triage and analysis\n\n### Investigating Signed Proxy Execution via MS Work Folders\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 affected 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",
@@ -48,5 +48,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 1
+  "version": 2
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_adfind_command_activity.json

@@ -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\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",
+  "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) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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.\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- 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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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/",
@@ -80,5 +80,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_admin_recon.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Enumeration of Administrator Accounts",
-  "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 Enumeration of Administrator Accounts\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of the `net` and `wmic` utilities to enumerate administrator-related users or groups \nin the domain and local machine scope. Attackers can use this information to plan their next steps of the attack, such\nas mapping targets for credential compromise and other post-exploitation activities.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\n\n### Related rules\n\n- AdFind Command Activity - eda499b8-a073-4e35-9733-22ec71f57f3a\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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\" or process.pe.original_file_name == \"net.exe\") or\n    ((process.name : \"net1.exe\" or process.pe.original_file_name == \"net1.exe\") and\n        not process.parent.name : \"net.exe\")) and\n   process.args : (\"group\", \"user\", \"localgroup\") and\n   process.args : (\"admin\", \"Domain Admins\", \"Remote Desktop Users\", \"Enterprise Admins\", \"Organization Management\") and\n   not process.args : \"/add\")\n\n   or\n\n  ((process.name : \"wmic.exe\" or process.pe.original_file_name == \"wmic.exe\") and\n     process.args : (\"group\", \"useraccount\"))\n",
   "risk_score": 21,
   "rule_id": "871ea072-1b71-4def-b016-6278b505138d",
@@ -55,5 +55,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_command_system_account.json

@@ -0,0 +1,47 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Identifies when the SYSTEM account uses an account discovery utility. This could be a sign of discovery activity after an adversary has achieved privilege escalation.",
+  "from": "now-9m",
+  "index": [
+    "winlogbeat-*",
+    "logs-endpoint.events.*",
+    "logs-windows.*"
+  ],
+  "language": "eql",
+  "license": "Elastic License v2",
+  "name": "Account Discovery Command via SYSTEM Account",
+  "note": "## Triage and analysis\n\n### Investigating Account Discovery Command via SYSTEM Account\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of account discovery utilities using the SYSTEM account, which is commonly observed\nafter attackers successfully perform privilege escalation or exploit web applications.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n  - If the process tree includes a web-application server process such as w3wp, httpd.exe, nginx.exe and alike,\n  investigate any suspicious file creation or modification in the last 48 hours to assess the presence of any potential\n  webshell backdoor.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Determine how the SYSTEM account is being used. For example, users with administrator privileges can spawn a system\nshell using Windows services, scheduled tasks or other third party utilities.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n- Use the data collected through the analysis to investigate other machines affected in the environment.\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.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",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Windows",
+    "Threat Detection",
+    "Discovery"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0007",
+        "name": "Discovery",
+        "reference": "https://attack.mitre.org/tactics/TA0007/"
+      },
+      "technique": [
+        {
+          "id": "T1033",
+          "name": "System Owner/User Discovery",
+          "reference": "https://attack.mitre.org/techniques/T1033/"
+        }
+      ]
+    }
+  ],
+  "timestamp_override": "event.ingested",
+  "type": "eql",
+  "version": 12
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_file_dir_discovery.json

@@ -15,6 +15,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "File and Directory Discovery",
+  "note": "## Triage and analysis\n\n### Investigating File and Directory Discovery\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for three directory-listing commands in one minute, which can indicate attempts to locate valuable files,\nspecific file types or installed programs.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n",
   "query": "sequence by agent.id, user.name with maxspan=1m\n[process where event.type in (\"start\", \"process_started\") and\n  ((process.name : \"cmd.exe\" or process.pe.original_file_name == \"Cmd.Exe\") and process.args : \"dir\") or\n    process.name : \"tree.com\"]\n[process where event.type in (\"start\", \"process_started\") and\n  ((process.name : \"cmd.exe\" or process.pe.original_file_name == \"Cmd.Exe\") and process.args : \"dir\") or\n    process.name : \"tree.com\"]\n[process where event.type in (\"start\", \"process_started\") and\n  ((process.name : \"cmd.exe\" or process.pe.original_file_name == \"Cmd.Exe\") and process.args : \"dir\") or\n    process.name : \"tree.com\"]\n",
   "risk_score": 21,
   "rule_id": "7b08314d-47a0-4b71-ae4e-16544176924f",
@@ -44,5 +45,5 @@
     }
   ],
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_linux_hping_activity.json

@@ -25,9 +25,27 @@
     "Elastic",
     "Host",
     "Linux",
-    "Threat Detection"
+    "Threat Detection",
+    "Discovery"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0007",
+        "name": "Discovery",
+        "reference": "https://attack.mitre.org/tactics/TA0007/"
+      },
+      "technique": [
+        {
+          "id": "T1082",
+          "name": "System Information Discovery",
+          "reference": "https://attack.mitre.org/techniques/T1082/"
+        }
+      ]
+    }
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_net_command_system_account.json

@@ -1,47 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies when the SYSTEM account uses an account discovery utility. This could be a sign of discovery activity after an adversary has achieved privilege escalation.",
-  "from": "now-9m",
-  "index": [
-    "winlogbeat-*",
-    "logs-endpoint.events.*",
-    "logs-windows.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "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",
-  "risk_score": 21,
-  "rule_id": "2856446a-34e6-435b-9fb5-f8f040bfa7ed",
-  "severity": "low",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Windows",
-    "Threat Detection",
-    "Discovery"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0007",
-        "name": "Discovery",
-        "reference": "https://attack.mitre.org/tactics/TA0007/"
-      },
-      "technique": [
-        {
-          "id": "T1033",
-          "name": "System Owner/User Discovery",
-          "reference": "https://attack.mitre.org/techniques/T1033/"
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 11
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_net_view.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Windows Network Enumeration",
-  "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 Network Enumeration\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of the `net` utility to enumerate servers in the environment that hosts shared drives\nor printers. This information is useful to attackers as they can identify targets for lateral movements and search for\nvaluable shared data.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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\" or process.pe.original_file_name == \"net.exe\") or\n   ((process.name : \"net1.exe\" or process.pe.original_file_name == \"net1.exe\") and\n       not process.parent.name : \"net.exe\")) and\n  (process.args : \"view\" or (process.args : \"time\" and process.args : \"\\\\\\\\*\"))\n\n\n  /* expand when ancestry is available\n  and not descendant of [process where event.type == (\"start\", \"process_started\") and process.name : \"cmd.exe\" and\n                           ((process.parent.name : \"userinit.exe\") or\n                            (process.parent.name : \"gpscript.exe\") or\n                            (process.parent.name : \"explorer.exe\" and\n                               process.args : \"C:\\\\*\\\\Start Menu\\\\Programs\\\\Startup\\\\*.bat*\"))]\n  */\n",
   "risk_score": 47,
   "rule_id": "7b8bfc26-81d2-435e-965c-d722ee397ef1",
@@ -48,5 +48,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_peripheral_device.json

@@ -2,7 +2,7 @@
   "author": [
     "Elastic"
   ],
-  "description": "Identifies use of the Windows file system utility (fsutil.exe ) to gather information about attached peripheral devices and components connected to a computer system.",
+  "description": "Identifies use of the Windows file system utility (fsutil.exe) to gather information about attached peripheral devices and components connected to a computer system.",
   "from": "now-9m",
   "index": [
     "winlogbeat-*",
@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Peripheral Device Discovery",
-  "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 Peripheral Device Discovery\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of the `fsutil` utility with the `fsinfo` subcommand to enumerate drives attached to\nthe computer, which can be used to identify secondary drives used for backups, mapped network drives, and removable\nmedia. These devices can contain valuable information for attackers.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n- Determine whether this activity was followed by suspicious file access/copy operations or uploads to file storage\nservices.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 : \"fsutil.exe\" or process.pe.original_file_name == \"fsutil.exe\") and \n  process.args : \"fsinfo\" and process.args : \"drives\"\n",
   "risk_score": 21,
   "rule_id": "0c7ca5c2-728d-4ad9-b1c5-bbba83ecb1f4",
@@ -43,5 +43,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_posh_suspicious_api_functions.json

@@ -14,7 +14,7 @@
   "language": "kuery",
   "license": "Elastic License v2",
   "name": "PowerShell Suspicious Discovery Related Windows API Functions",
-  "note": "## Triage and analysis.\n\n### Investigating PowerShell Suspicious Discovery Related Windows API Functions\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use PowerShell to interact with the Win32 API to bypass command line based detections, using libraries\nlike PSReflect or Get-ProcAddress Cmdlet.\n\n#### Possible investigation steps\n\n- Examine script content that triggered the detection. \n- Investigate the script execution chain (parent process tree).\n- Inspect any file or network events from the suspicious PowerShell host process instance.\n- Investigate other alerts related to the user/host in the last 48 hours.\n- Consider whether the user needs PowerShell to complete its tasks.\n- Check if the imported function was executed.\n\n### False positive analysis\n\n- Discovery activities themselves are not inherently malicious if occurring in isolation, as long as the script does not\ncontain other capabilities, and there are no other alerts related to the user or host; such alerts can be dismissed.\nHowever, analysts should keep in mind that this is not a common way of getting information, making it suspicious.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\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- 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 enabled.\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",
+  "note": "## Triage and analysis\n\n### Investigating PowerShell Suspicious Discovery Related Windows API Functions\n\nPowerShell is one of the main tools system administrators use for automation, report routines, and other tasks. This\nmakes it available for use in various environments, and creates an attractive way for attackers to execute code.\n\nAttackers can use PowerShell to interact with the Win32 API to bypass command line based detections, using libraries\nlike PSReflect or Get-ProcAddress Cmdlet.\n\n#### Possible investigation steps\n\n- Examine the script content that triggered the detection; look for suspicious DLL imports, collection or exfiltration\ncapabilities, suspicious functions, encoded or compressed data, and other potentially malicious characteristics.\n- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for\nprevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Examine file or network events from the involved PowerShell process for suspicious behavior.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Evaluate whether the user needs to use PowerShell to complete tasks.\n- Check for additional PowerShell and command-line logs that indicate that imported functions were run.\n\n### False positive analysis\n\n- Discovery activities themselves are not inherently malicious if occurring in isolation, as long as the script does not\ncontain other capabilities, and there are no other alerts related to the user or host; such alerts can be dismissed.\nHowever, analysts should keep in mind that this is not a common way of getting information, making it suspicious.\n\n### Related rules\n\n- PowerShell PSReflect Script - 56f2e9b5-4803-4e44-a0a4-a52dc79d57fe\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- Restrict PowerShell usage outside of IT and engineering business units using GPOs, AppLocker, Intune, or similar software.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'PowerShell Script Block Logging' logging policy must be enabled.\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",
   "query": "event.category:process and \n  powershell.file.script_block_text : (\n    NetShareEnum or\n    NetWkstaUserEnum or\n    NetSessionEnum or\n    NetLocalGroupEnum or\n    NetLocalGroupGetMembers or\n    DsGetSiteName or\n    DsEnumerateDomainTrusts or\n    WTSEnumerateSessionsEx or\n    WTSQuerySessionInformation or\n    LsaGetLogonSessionData or\n    QueryServiceObjectSecurity\n  )\n",
   "references": [
     "https://github.com/BC-SECURITY/Empire/blob/9259e5106986847d2bb770c4289c0c0f1adf2344/data/module_source/situational_awareness/network/powerview.ps1#L21413",
@@ -88,5 +88,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_post_exploitation_external_ip_lookup.json

@@ -13,6 +13,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "External IP Lookup from Non-Browser Process",
+  "note": "## Triage and analysis\n\n### Investigating External IP Lookup from Non-Browser Process\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for connections to known IP lookup services through non-browser processes or non-installed programs.\nUsing only the IP address of the compromised system, attackers can obtain valuable information such as the system's\ngeographic location, the company that owns the IP, whether the system is cloud-hosted, and more.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\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- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file\nmodifications, and any spawned child processes.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Isolate the involved hosts to prevent further post-compromise behavior.\n- Use the data collected through the analysis to investigate other machines affected in the environment.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n",
   "query": "network where network.protocol == \"dns\" and\n    process.name != null and user.id not in (\"S-1-5-19\", \"S-1-5-20\") and\n    event.action == \"lookup_requested\" and\n    /* Add new external IP lookup services here */\n    dns.question.name :\n    (\n        \"*api.ipify.org\",\n        \"*freegeoip.app\",\n        \"*checkip.amazonaws.com\",\n        \"*checkip.dyndns.org\",\n        \"*freegeoip.app\",\n        \"*icanhazip.com\",\n        \"*ifconfig.*\",\n        \"*ipecho.net\",\n        \"*ipgeoapi.com\",\n        \"*ipinfo.io\",\n        \"*ip.anysrc.net\",\n        \"*myexternalip.com\",\n        \"*myipaddress.com\",\n        \"*showipaddress.com\",\n        \"*whatismyipaddress.com\",\n        \"*wtfismyip.com\",\n        \"*ipapi.co\",\n        \"*ip-lookup.net\",\n        \"*ipstack.com\"\n    ) and\n    /* Insert noisy false positives here */\n    not process.executable :\n    (\n      \"?:\\\\Program Files\\\\*.exe\",\n      \"?:\\\\Program Files (x86)\\\\*.exe\",\n      \"?:\\\\Windows\\\\System32\\\\WWAHost.exe\",\n      \"?:\\\\Windows\\\\System32\\\\smartscreen.exe\",\n      \"?:\\\\Windows\\\\System32\\\\MicrosoftEdgeCP.exe\",\n      \"?:\\\\ProgramData\\\\Microsoft\\\\Windows Defender\\\\Platform\\\\*\\\\MsMpEng.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Fiddler\\\\Fiddler.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Programs\\\\Microsoft VS Code\\\\Code.exe\",\n      \"?:\\\\Users\\\\*\\\\AppData\\\\Local\\\\Microsoft\\\\OneDrive\\\\OneDrive.exe\"\n    )\n",
   "references": [
     "https://community.jisc.ac.uk/blogs/csirt/article/trickbot-analysis-and-mitigation",
@@ -37,15 +38,27 @@
         "reference": "https://attack.mitre.org/tactics/TA0007/"
       },
       "technique": [
+        {
+          "id": "T1614",
+          "name": "System Location Discovery",
+          "reference": "https://attack.mitre.org/techniques/T1614/"
+        },
         {
           "id": "T1016",
           "name": "System Network Configuration Discovery",
-          "reference": "https://attack.mitre.org/techniques/T1016/"
+          "reference": "https://attack.mitre.org/techniques/T1016/",
+          "subtechnique": [
+            {
+              "id": "T1016.001",
+              "name": "Internet Connection Discovery",
+              "reference": "https://attack.mitre.org/techniques/T1016/001/"
+            }
+          ]
         }
       ]
     }
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 7
+  "version": 8
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_privileged_localgroup_membership.json

@@ -11,7 +11,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Enumeration of Privileged Local Groups Membership",
-  "note": "## Config\n\nThis will require Windows security event 4799 by enabling audit success for the Windows Account Management category and\nthe Security Group Management subcategory.\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 Enumeration of Privileged Local Groups Membership\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the enumeration of privileged local groups' membership by suspicious processes, and excludes known\nlegitimate utilities and programs installed. Attackers can use this information to decide the next steps of the attack,\nsuch as mapping targets for credential compromise and other post-exploitation activities.\n\n#### Possible investigation steps\n\n- Identify the process, host and user involved on the event.\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n- Retrieve the process executable and determine if it is malicious:\n  - Check if the file belongs to the operating system or has a valid digital signature.\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\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Isolate the involved hosts to prevent further post-compromise behavior.\n- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\n\n## Config\n\nThe 'Audit Security Group Management' audit policy must be configured (Success).\nSteps to implement the logging policy with with Advanced Audit Configuration:\n\n```\nComputer Configuration > \nPolicies > \nWindows Settings > \nSecurity Settings > \nAdvanced Audit Policies Configuration > \nAudit Policies > \nAccount Management >\nAudit Security Group Management (Success)\n```\n\nMicrosoft introduced the [event used](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4799) in this detection rule on Windows 10 and Windows Server 2016 or later operating systems.\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 == \"user-member-enumerated\" and\n\n /* noisy and usual legit processes excluded */\n not winlog.event_data.CallerProcessName:\n              (\"?:\\\\Windows\\\\System32\\\\VSSVC.exe\",\n               \"?:\\\\Windows\\\\System32\\\\SearchIndexer.exe\",\n               \"?:\\\\Windows\\\\System32\\\\CompatTelRunner.exe\",\n               \"?:\\\\Windows\\\\System32\\\\oobe\\\\msoobe.exe\",\n               \"?:\\\\Windows\\\\System32\\\\net1.exe\",\n               \"?:\\\\Windows\\\\System32\\\\svchost.exe\",\n               \"?:\\\\Windows\\\\System32\\\\Netplwiz.exe\",\n               \"?:\\\\Windows\\\\System32\\\\msiexec.exe\",\n               \"?:\\\\Windows\\\\System32\\\\CloudExperienceHostBroker.exe\",\n               \"?:\\\\Windows\\\\System32\\\\wbem\\\\WmiPrvSE.exe\",\n               \"?:\\\\Windows\\\\System32\\\\SrTasks.exe\",\n               \"?:\\\\Windows\\\\System32\\\\lsass.exe\",\n               \"?:\\\\Windows\\\\System32\\\\diskshadow.exe\",\n               \"?:\\\\Windows\\\\System32\\\\dfsrs.exe\",\n               \"?:\\\\Program Files\\\\*.exe\",\n               \"?:\\\\Program Files (x86)\\\\*.exe\") and\n  /* privileged local groups */\n (group.name:(\"admin*\",\"RemoteDesktopUsers\") or\n  winlog.event_data.TargetSid:(\"S-1-5-32-544\",\"S-1-5-32-555\"))\n",
   "risk_score": 43,
   "rule_id": "291a0de9-937a-4189-94c0-3e847c8b13e4",
@@ -49,5 +49,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 3
+  "version": 4
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_remote_system_discovery_commands_windows.json

@@ -2,7 +2,7 @@
   "author": [
     "Elastic"
   ],
-  "description": "Discovery of remote system information using built-in commands, which may be used to mover laterally.",
+  "description": "Discovery of remote system information using built-in commands, which may be used to move laterally.",
   "from": "now-9m",
   "index": [
     "logs-endpoint.events.*",
@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Remote System Discovery Commands",
-  "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 System Discovery Commands\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of the `arp` or `nbstat` utilities to enumerate remote systems in the environment,\nwhich is useful for attackers to identify lateral movement targets.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 : \"nbtstat.exe\" and process.args : (\"-n\", \"-s\")) or\n  (process.name : \"arp.exe\" and process.args : \"-a\")\n",
   "risk_score": 21,
   "rule_id": "0635c542-1b96-4335-9b47-126582d2c19a",
@@ -33,6 +33,11 @@
         "reference": "https://attack.mitre.org/tactics/TA0007/"
       },
       "technique": [
+        {
+          "id": "T1016",
+          "name": "System Network Configuration Discovery",
+          "reference": "https://attack.mitre.org/techniques/T1016/"
+        },
         {
           "id": "T1018",
           "name": "Remote System Discovery",
@@ -43,5 +48,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_security_software_wmic.json

@@ -12,7 +12,7 @@
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Security Software Discovery using WMIC",
-  "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 Security Software Discovery using WMIC\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of the `wmic` utility with arguments compatible to the enumeration of the security\nsoftware installed on the host. Attackers can use this information to decide whether or not to infect a system, disable\nprotections, use bypasses, etc.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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:\"wmic.exe\" or process.pe.original_file_name:\"wmic.exe\") and\n    process.args:\"/namespace:\\\\\\\\root\\\\SecurityCenter2\" and process.args:\"Get\"\n",
   "risk_score": 47,
   "rule_id": "6ea55c81-e2ba-42f2-a134-bccf857ba922",
@@ -50,5 +50,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 5
+  "version": 6
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/discovery_whoami_command_activity.json

@@ -10,12 +10,13 @@
   "index": [
     "winlogbeat-*",
     "logs-endpoint.events.*",
-    "logs-windows.*"
+    "logs-windows.*",
+    "logs-system.*"
   ],
   "language": "eql",
   "license": "Elastic License v2",
   "name": "Whoami Process Activity",
-  "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 Whoami Process Activity\n\nAfter successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps.\nThis can happen by running commands to enumerate network resources, users, connections, files, and installed security\nsoftware.\n\nThis rule looks for the execution of the `whoami` utility. Attackers commonly use this utility to measure their current\nprivileges, discover the current user, determine if a privilege escalation was successful, etc.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files\nfor prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.\n- Identify the user account that performed the action and whether it should perform this kind of action.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Investigate abnormal behaviors observed using the account, such as commands executed, files created or modified, and\nnetwork connections.\n\n### False positive analysis\n\n- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify\nsuspicious activity related to the user or host, such alerts can be dismissed.\n\n### Related rules\n\n- Account Discovery Command via SYSTEM Account - 2856446a-34e6-435b-9fb5-f8f040bfa7ed\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- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are\nidentified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business\nsystems, and web services.\n- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and\nmalware components.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.\n- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the\nmean time to respond (MTTR).\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 process.name : \"whoami.exe\"\n",
   "risk_score": 21,
   "rule_id": "ef862985-3f13-4262-a686-5f357bbb9bc2",
@@ -46,5 +47,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 8
+  "version": 9
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/domain_added_to_google_workspace_trusted_domains.json

@@ -33,5 +33,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "query",
-  "version": 10
+  "version": 12
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_abnormal_process_id_file_created.json

@@ -0,0 +1,54 @@
+{
+  "author": [
+    "Elastic"
+  ],
+  "description": "Identifies the creation of a Process ID (PID), lock or reboot file created in temporary file storage paradigm (tmpfs) directory /var/run. On Linux, the PID files typically hold the process ID to track previous copies running and manage other tasks. Certain Linux malware use the /var/run directory for holding data, executables and other tasks, disguising itself or these files as legitimate PID files.",
+  "false_positives": [
+    "False-Positives (FP) can appear if the PID file is legitimate and holding a process ID as intended. To differentiate, if the PID file is an executable or larger than 10 bytes, it should be ruled suspicious."
+  ],
+  "from": "now-9m",
+  "index": [
+    "logs-endpoint.events.*"
+  ],
+  "language": "eql",
+  "license": "Elastic License v2",
+  "name": "Abnormal Process ID or Lock File Created",
+  "note": "## Triage and analysis\n\n### Investigating Abnormal Process ID or Lock File Created\nDetection alerts from this rule indicate that an unusual PID file was created and could potentially have alternate purposes during an intrusion.  Here are some possible avenues of investigation:\n- Run the following in Osquery to quickly identify unsual PID file size: \"SELECT f.size, f.uid, f.type, f.path from file f WHERE path like '/var/run/%pid';\"\n- Examine the history of this file creation and from which process it was created by using the \"lsof\" command.\n- Examine the contents of the PID file itself, simply by running the \"cat\" command to determine if the expected process ID integer exists and if not, the PID file is not legitimate.\n- Examine the reputation of the SHA256 hash from the PID file in a database like VirusTotal to identify additional pivots and artifacts for investigation.",
+  "query": "/* add file size filters when data is available */\nfile where event.type == \"creation\" and user.id == \"0\" and\n    file.path regex~ \"\"\"/var/run/\\w+\\.(pid|lock|reboot)\"\"\" and file.extension in (\"pid\",\"lock\",\"reboot\") and\n\n    /* handle common legitimate files */\n\n    not file.name in (\n    \"auditd.pid\",\n    \"python*\",\n    \"apport.pid\",\n    \"apport.lock\",\n    \"kworker*\",\n    \"gdm3.pid\",\n    \"sshd.pid\",\n    \"acpid.pid\",\n    \"unattended-upgrades.lock\",\n    \"unattended-upgrades.pid\",\n    \"cmd.pid\",\n    \"cron*.pid\"\n    )\n",
+  "references": [
+    "https://www.sandflysecurity.com/blog/linux-file-masquerading-and-malicious-pids-sandfly-1-2-6-update/",
+    "https://twitter.com/GossiTheDog/status/1522964028284411907",
+    "https://exatrack.com/public/Tricephalic_Hellkeeper.pdf"
+  ],
+  "risk_score": 43,
+  "rule_id": "cac91072-d165-11ec-a764-f661ea17fbce",
+  "severity": "medium",
+  "tags": [
+    "Elastic",
+    "Host",
+    "Linux",
+    "Threat Detection",
+    "Execution",
+    "BPFDoor"
+  ],
+  "threat": [
+    {
+      "framework": "MITRE ATT&CK",
+      "tactic": {
+        "id": "TA0002",
+        "name": "Execution",
+        "reference": "https://attack.mitre.org/tactics/TA0002/"
+      },
+      "technique": [
+        {
+          "id": "T1106",
+          "name": "Native API",
+          "reference": "https://attack.mitre.org/techniques/T1106/"
+        }
+      ]
+    }
+  ],
+  "timestamp_override": "event.ingested",
+  "type": "eql",
+  "version": 1
+}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_apt_binary.json

@@ -1,56 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary apt/apt-get abuse to breakout out of restricted shells or environments by spawning an interactive system shell. The apt utility allows us to manage installation and removal of softwares on Debian based Linux distributions and the activity of spawning shell is not a standard use of this binary for a user or system administrator. It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via  apt/apt-get Changelog Escape",
-  "query": "process where event.type == \"start\" and process.name == \"sensible-pager\" and\n  process.args in (\"/bin/sh\", \"/bin/bash\", \"/bin/dash\", \"sh\", \"bash\", \"dash\") and\n  process.parent.name in (\"apt\", \"apt-get\") and process.parent.args == \"changelog\"\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/apt/",
-    "https://gtfobins.github.io/gtfobins/apt-get/"
-  ],
-  "risk_score": 47,
-  "rule_id": "8fed8450-847e-43bd-874c-3bbf0cd425f3",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_apt_solarwinds_backdoor_child_cmd_powershell.json

@@ -19,7 +19,7 @@
   "query": "process where event.type in (\"start\", \"process_started\") and process.name: (\"cmd.exe\", \"powershell.exe\") and\nprocess.parent.name: (\n     \"ConfigurationWizard*.exe\",\n     \"NetflowDatabaseMaintenance*.exe\",\n     \"NetFlowService*.exe\",\n     \"SolarWinds.Administration*.exe\",\n     \"SolarWinds.Collector.Service*.exe\",\n     \"SolarwindsDiagnostics*.exe\"\n     )\n",
   "references": [
     "https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html",
-    "https://github.com/fireeye/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SOLARWINDS%20SUSPICIOUS%20FILEWRITES%20(METHODOLOGY).ioc"
+    "https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20FILEWRITES%20(METHODOLOGY).ioc"
   ],
   "risk_score": 47,
   "rule_id": "d72e33fc-6e91-42ff-ac8b-e573268c5a87",
@@ -72,5 +72,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_apt_solarwinds_backdoor_unusual_child_processes.json

@@ -19,7 +19,7 @@
   "query": "process where event.type in (\"start\", \"process_started\") and\n process.parent.name: (\"SolarWinds.BusinessLayerHost.exe\", \"SolarWinds.BusinessLayerHostx64.exe\") and\n not process.name : (\n        \"APMServiceControl*.exe\",\n        \"ExportToPDFCmd*.Exe\",\n        \"SolarWinds.Credentials.Orion.WebApi*.exe\",\n        \"SolarWinds.Orion.Topology.Calculator*.exe\",\n        \"Database-Maint.exe\",\n        \"SolarWinds.Orion.ApiPoller.Service.exe\",\n        \"WerFault.exe\",\n        \"WerMgr.exe\")\n",
   "references": [
     "https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html",
-    "https://github.com/fireeye/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SOLARWINDS%20SUSPICIOUS%20CHILD%20PROCESSES%20(METHODOLOGY).ioc"
+    "https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20CHILD%20PROCESSES%20(METHODOLOGY).ioc"
   ],
   "risk_score": 47,
   "rule_id": "93b22c0a-06a0-4131-b830-b10d5e166ff4",
@@ -72,5 +72,5 @@
   ],
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 4
+  "version": 5
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_awk_binary_shell.json

@@ -1,56 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary awk abuse to breakout out of restricted shells or environments by spawning an interactive system shell. The awk utility is a text processing language used for data extraction and reporting tools and the activity of spawning shell is not a standard use of this binary for a user or system administrator. It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via awk Commands",
-  "query": "process where event.type == \"start\" and process.name in (\"sh\", \"bash\", \"dash\") and\n  process.parent.name in (\"nawk\", \"mawk\", \"awk\", \"gawk\") and process.parent.args : \"BEGIN {system(*)}\"\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/nawk/",
-    "https://gtfobins.github.io/gtfobins/mawk/"
-  ],
-  "risk_score": 47,
-  "rule_id": "10754992-28c7-4472-be5b-f3770fd04f2d",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_busybox_binary.json

@@ -1,55 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary busybox abuse to break out from restricted environments by spawning an interactive system shell.The busybox is software utility suite that provides several Unix utilities in a single executable file and the activity of spawing a shell is not a standard use of this binary by a user or system administrator. It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via busybox Shell Evasion",
-  "query": "process where event.type == \"start\" and process.name == \"busybox\" and process.args_count == 2 and process.args in (\"/bin/sh\", \"/bin/ash\", \"sh\", \"ash\")\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/busybox/"
-  ],
-  "risk_score": 47,
-  "rule_id": "e9b4a3c7-24fc-49fd-a00f-9c938031eef1",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_c89_c99_binary.json

@@ -1,56 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary c89/c99 abuse to break out from restricted environments by spawning an interactive system shell.The c89/c99 utility is an interface to the standard C compilation system and the activity of spawing a shell is not a standard use of this binary by a user or system administrator. It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via c89/c99 Shell evasion",
-  "query": "process where event.type == \"start\" and process.name in (\"sh\", \"dash\", \"bash\") and\n  process.parent.name in (\"c89\",\"c99\") and process.parent.args == \"-wrapper\" and\n  process.parent.args in (\"sh,-s\", \"bash,-s\", \"dash,-s\", \"/bin/sh,-s\", \"/bin/bash,-s\", \"/bin/dash,-s\")\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/c89/",
-    "https://gtfobins.github.io/gtfobins/c99/"
-  ],
-  "risk_score": 47,
-  "rule_id": "1859ce38-6a50-422b-a5e8-636e231ea0cd",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_command_shell_started_by_svchost.json

@@ -45,5 +45,5 @@
   "timeline_title": "Comprehensive Process Timeline",
   "timestamp_override": "event.ingested",
   "type": "eql",
-  "version": 10
+  "version": 12
 }

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_cpulimit_binary.json

@@ -1,55 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary cpulimit abuse to break out from restricted environments by spawning an interactive system shell. The cpulimit utility is used to restrict the CPU usage of a process in cases of CPU or system load exceeding the defined threshold and the activity of spawning a shell is not a standard use of this binary by a user or system administrator. This can potentially indicate a malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via cpulimit Shell Evasion",
-  "query": "process where event.type == \"start\" and process.name in (\"bash\", \"sh\", \"dash\") and\n  process.parent.name == \"cpulimit\" and process.parent.args == \"-f\" and\n  process.parent.args in (\"/bin/sh\", \"/bin/bash\", \"/bin/dash\", \"sh\", \"bash\", \"dash\")\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/cpulimit/"
-  ],
-  "risk_score": 47,
-  "rule_id": "0968cfbd-40f0-4b1c-b7b1-a60736c7b241",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_crash_binary.json

@@ -1,55 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary crash abuse to break out from restricted environments by spawning an interactive system shell.The crash utility helps to analyze Linux crash dump data or a live system and the activity of spawing a shell is not a standard use of this binary by a user or system administrator. It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via crash Shell evasion",
-  "query": "process where event.type == \"start\" and process.parent.name == \"crash\" and process.parent.args == \"-h\" and process.name == \"sh\"\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/crash/"
-  ],
-  "risk_score": 47,
-  "rule_id": "ee619805-54d7-4c56-ba6f-7717282ddd73",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_env_binary.json

@@ -1,55 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary env abuse to break out from restricted environments by spawning an interactive system shell.The env utility is a shell command for Unix like OS which is used to print a list of environment variables and the activity of spawning shell is not a standard use of this binary for a user or system administrator. It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via env Shell Evasion",
-  "query": "process where event.type == \"start\" and process.name : \"env\" and process.args_count == 2 and process.args : (\"/bin/sh\", \"/bin/bash\", \"sh\", \"bash\")\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/env/"
-  ],
-  "risk_score": 47,
-  "rule_id": "72d33577-f155-457d-aad3-379f9b750c97",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_expect_binary.json

@@ -1,55 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary expect abuse to break out from restricted environments by spawning an interactive system shell. The expect utility allows us to automate control of interactive applications such as telnet,ftp,ssh and others and the activity of spawning shell is not a standard use of this binary for a user or system administrator and could potentially indicate malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via the expect command",
-  "query": "process where event.type == \"start\" and process.name in (\"bash\", \"sh\", \"dash\") and\n  process.parent.name == \"expect\" and process.parent.args == \"-c\" and\n  process.parent.args in (\"spawn /bin/sh;interact\", \"spawn /bin/bash;interact\", \"spawn /bin/dash;interact\", \"spawn sh;interact\", \"spawn bash;interact\", \"spawn dash;interact\")\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/expect/"
-  ],
-  "risk_score": 47,
-  "rule_id": "fd3fc25e-7c7c-4613-8209-97942ac609f6",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}

x-pack/plugins/security_solution/server/lib/detection_engine/rules/prepackaged_rules/execution_find_binary.json

@@ -1,55 +0,0 @@
-{
-  "author": [
-    "Elastic"
-  ],
-  "description": "Identifies Linux binary find abuse to break out from restricted environments by spawning an interactive system shell. The find command in Unix is a command line utility for walking a file hirerarchy and the activity of spawning shell is not a standard use of this binary for a user or system administrator.It indicates a potentially malicious actor attempting to improve the capabilities or stability of their access.",
-  "from": "now-9m",
-  "index": [
-    "logs-endpoint.events.*"
-  ],
-  "language": "eql",
-  "license": "Elastic License v2",
-  "name": "Linux Restricted Shell Breakout via the find command",
-  "query": "process where event.type == \"start\" and process.name in (\"bash\", \"sh\") and\n  process.parent.name == \"find\" and process.parent.args == \"-exec\" and\n  process.parent.args == \";\" and process.parent.args in (\"/bin/bash\", \"/bin/sh\", \"bash\", \"sh\")\n",
-  "references": [
-    "https://gtfobins.github.io/gtfobins/find/"
-  ],
-  "risk_score": 47,
-  "rule_id": "6f683345-bb10-47a7-86a7-71e9c24fb358",
-  "severity": "medium",
-  "tags": [
-    "Elastic",
-    "Host",
-    "Linux",
-    "Threat Detection",
-    "Execution",
-    "GTFOBins"
-  ],
-  "threat": [
-    {
-      "framework": "MITRE ATT&CK",
-      "tactic": {
-        "id": "TA0002",
-        "name": "Execution",
-        "reference": "https://attack.mitre.org/tactics/TA0002/"
-      },
-      "technique": [
-        {
-          "id": "T1059",
-          "name": "Command and Scripting Interpreter",
-          "reference": "https://attack.mitre.org/techniques/T1059/",
-          "subtechnique": [
-            {
-              "id": "T1059.004",
-              "name": "Unix Shell",
-              "reference": "https://attack.mitre.org/techniques/T1059/004/"
-            }
-          ]
-        }
-      ]
-    }
-  ],
-  "timestamp_override": "event.ingested",
-  "type": "eql",
-  "version": 1
-}