[rule-tuning] Adding more context with triage/investigation (#1481)

* [rule-tuning] Adding more context with triage/investigation

* Adding mimikatz rule

* Fixed updated date on mimikatz rule

* Adding Defender update

* Adding scheduled task

* Adding AdFind

* Adding rare process

* Adding cloudtrail country

* Adding cloudtrail spike

* Adding threat intel

* Fixed minor spelling/syntax

* Fixed minor spelling/syntax p2

* Update rules/cross-platform/threat_intel_module_match.toml

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

* Update rules/integrations/aws/ml_cloudtrail_error_message_spike.toml

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

* Update rules/ml/ml_rare_process_by_host_windows.toml

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

* Update rules/windows/credential_access_mimikatz_powershell_module.toml

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

* Update rules/windows/credential_access_mimikatz_powershell_module.toml

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

* Update rules/windows/defense_evasion_defender_exclusion_via_powershell.toml

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

* Update rules/windows/discovery_adfind_command_activity.toml

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

* Update rules/windows/discovery_adfind_command_activity.toml

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

* Update rules/windows/discovery_adfind_command_activity.toml

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

* Update rules/windows/discovery_adfind_command_activity.toml

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

* Update rules/windows/discovery_adfind_command_activity.toml

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

* Update rules/windows/discovery_adfind_command_activity.toml

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

* Removed MITRE link, added Microsoft

* Update ml_cloudtrail_error_message_spike.toml

* Update ml_cloudtrail_rare_method_by_country.toml

* Update ml_rare_process_by_host_windows.toml

* Update credential_access_mimikatz_powershell_module.toml

* Update defense_evasion_defender_exclusion_via_powershell.toml

* Update discovery_adfind_command_activity.toml

* Update lateral_movement_dns_server_overflow.toml

* Update lateral_movement_scheduled_task_target.toml

* Update persistence_evasion_registry_startup_shell_folder_modified.toml

* Update defense_evasion_defender_exclusion_via_powershell.toml

* Update lateral_movement_scheduled_task_target.toml

* Update persistence_evasion_registry_startup_shell_folder_modified.toml

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

rules/cross-platform/threat_intel_module_match.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/04/21"
 maturity = "production"
-updated_date = "2021/05/10"
+updated_date = "2021/09/13"
 
 [rule]
 author = ["Elastic"]
@@ -16,11 +16,45 @@ license = "Elastic License v2"
 name = "Threat Intel Filebeat Module Indicator Match"
 note = """## Triage and Analysis
 
+### Investigating Threat Intel Indicator Matches
+
+Threat Intel indicator match rules allow matching from a local observation such as an endpoint event that records a file
+hash with an entry of a file hash stored within the Threat Intel Filebeat module. Other examples of matches can occur on
+an IP address, registry path, URL and imphash.
+
+The matches will be based on the incoming feed data so it's important to validate the data and review the results by
+investigating the associated activity to determine if it requires further investigation.
+
 If an indicator matches a local observation, the following enriched fields will be generated to identify the indicator, field, and type matched.
 
 - `threatintel.indicator.matched.atomic` - this identifies the atomic indicator that matched the local observation
 - `threatintel.indicator.matched.field` - this identifies the indicator field that matched the local observation
 - `threatintel.indicator.matched.type` - this identifies the indicator type that matched the local observation
+
+#### Possible investigation steps:
+- Investigation should be validated and reviewed based on the data (file hash, registry path, URL, imphash) that was matched
+and viewing the source of that activity.
+- Consider the history of the indicator that was matched. Has it happened before? Is it happening on multiple machines?
+These kinds of questions can help understand if the activity is related to legitimate behavior.
+- Consider the user and their role within the company, is this something related to their job or work function?
+
+### False Positive Analysis
+- For any matches found, it's important to consider the initial release date of that indicator. Threat intelligence can
+be a great tool for augmenting existing security processes, while at the same time it should be understood that threat
+intelligence can represent a specific set of activity observed at a point in time. For example, an IP address
+may have hosted malware observed in a Dridex campaign six months ago, but it's possible that IP has been remediated and
+no longer represents any threat.
+- Adversaries often use legitimate tools as network administrators such as `PsExec` or `AdFind`, these tools often find their
+way into indicator lists creating the potential for false positives.
+- It's possible after large and publicly written campaigns, curious employees might end up going directly to attacker infrastructure and generating these rules
+
+### Response and Remediation
+- If suspicious or malicious behavior is observed, immediate response should be taken to isolate activity to prevent further
+post-compromise behavior.
+- One example of a response if a machine matched a command and control IP address would be to add an entry to a network
+device such as a firewall or proxy appliance to prevent any outbound activity from leaving that machine.
+- Another example of a response with a malicious file hash match would involve validating if the file was properly quarantined,
+review current running processes looking for any abnormal activity, and investigating for any other follow-up actions such as persistence or lateral movement
 """
 references = [ "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html"]
 risk_score = 99

rules/integrations/aws/ml_cloudtrail_error_message_spike.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/07/13"
 maturity = "production"
-updated_date = "2021/07/20"
+updated_date = "2021/09/13"
 integration = "aws"
 
 [rule]
@@ -31,11 +31,34 @@ The AWS Fleet integration, Filebeat module, or similarly structured data is requ
 ## Triage and analysis
 
 ### Investigating Spikes in CloudTrail Errors
-Detection alerts from this rule indicate a large spike in the number of CloudTrail log messages that contain a particular error message. The error message in question was associated with the response to an AWS API command or method call. Here are some possible avenues of investigation:
+
+CloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding
+what is considered normal behavior within an organization, suspicious or malicious activity can be spotted when deviations
+are observed. This example rule triggers from a large spike in the number of CloudTrail log messages that contain a
+particular error message. The error message in question was associated with the response to an AWS API command or method call,
+this has the potential to uncover unknown threats or activity.
+
+#### Possible investigation steps:
 - Examine the history of the error. Has it manifested before? If the error, which is visible in the `aws.cloudtrail.error_message` field, only manifested recently, it might be related to recent changes in an automation module or script.
 - Examine the request parameters. These may provide indications as to the nature of the task being performed when the error occurred. Is the error related to unsuccessful attempts to enumerate or access objects, data, or secrets? If so, this can sometimes be a byproduct of discovery, privilege escalation or lateral movement attempts.
-- Consider the user as identified by the user.name field. Is this activity part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request.
-- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts, or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?"""
+- Consider the user as identified by the `user.name field`. Is this activity part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request.
+- Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts, or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
+
+### False Positive Analysis
+- This rule has the possibility to produce false positives based on unexpected activity occurring such as bugs or recent
+changes to automation modules or scripting.
+- Adoption of new services or implementing new functionality to scripts may generate false positives
+
+### Related Rules
+- Unusual AWS Command for a User
+- Rare AWS Error Code
+
+### Response and Remediation
+- If activity is observed as suspicious or malicious, immediate response should be looked into rotating and deleting AWS IAM access keys
+- Validate if any unauthorized new users were created, remove these accounts and request password resets for other IAM users
+- Look into enabling multi-factor authentication for users
+- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS
+"""
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 risk_score = 21
 rule_id = "78d3d8d9-b476-451d-a9e0-7a5addd70670"

rules/integrations/aws/ml_cloudtrail_rare_method_by_country.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/07/13"
 maturity = "production"
-updated_date = "2021/07/20"
+updated_date = "2021/09/13"
 integration = "aws"
 
 [rule]
@@ -31,13 +31,35 @@ The AWS Fleet integration, Filebeat module, or similarly structured data is requ
 
 ## Triage and analysis
 
-### Investigating an Unusual CloudTrail Event
-Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address. Here are some possible avenues of investigation:
+### Investigating an Unusual Country For an AWS Command
+
+CloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding
+what is considered normal behavior within an organization, suspicious or malicious activity can be spotted when deviations
+are observed. This example rule focuses on AWS command activity where the country from the source of the activity has been
+considered unusual based on previous history.
+
+#### Possible investigation steps:
 - Consider the source IP address and geolocation for the calling user who issued the command. Do they look normal for the calling user? If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts, or could it be sourcing from an EC2 instance not under your control? If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
 - Consider the user as identified by the `user.name` field. Is this command part of an expected workflow for the user context? Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key id in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context. The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request.
 - Consider the time of day. If the user is a human, not a program or script, did the activity take place during a normal time of day?
 - Examine the history of the command. If the command, which is visible in the `event.action field`, only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, if it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process.
-- Examine the request parameters. These may provide indications as to the source of the program or the nature of the tasks it is performing."""
+- Examine the request parameters. These may provide indications as to the source of the program or the nature of the tasks it is performing.
+
+### False Positive Analysis
+- False positives can occur if activity is coming from new employees based in a country with no previous history in AWS,
+therefore it's important to validate the activity listed in the investigation steps above.
+
+### Related Rules
+- Unusual City For an AWS Command
+- Unusual AWS Command for a User
+- Rare AWS Error Code
+
+### Response and Remediation
+- If activity is observed as suspicious or malicious, immediate response should be looked into rotating and deleting AWS IAM access keys
+- Validate if any unauthorized new users were created, remove these accounts and request password resets for other IAM users
+- Look into enabling multi-factor authentication for users
+- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS
+"""
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 risk_score = 21
 rule_id = "dca28dee-c999-400f-b640-50a081cc0fd1"

rules/ml/ml_rare_process_by_host_windows.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/03/25"
 maturity = "production"
-updated_date = "2021/05/10"
+updated_date = "2021/09/13"
 
 [rule]
 anomaly_threshold = 50
@@ -24,14 +24,39 @@ machine_learning_job_id = ["rare_process_by_host_windows_ecs", "v2_rare_process_
 name = "Unusual Process For a Windows Host"
 note = """## Triage and analysis
 
-### Investigating an Unusual Windows Process
-Detection alerts from this rule indicate the presence of a Windows process that is rare and unusual for the host it ran on. Here are some possible avenues of investigation:
-- Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host?
+###  Investigating an Unusual Windows Process
+
+Searching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network.
+By understanding what is commonly run within an environment and developing baselines for legitimate activity can help
+uncover potential malware and suspicious behaviors.
+
+#### Possible investigation steps:
+- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?
 - Examine the history of execution. If this process only manifested recently, it might be part of a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.
 - Examine the process metadata like the values of the Company, Description and Product fields which may indicate whether the program is associated with an expected software vendor or package.
 - Examine arguments and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing.
 - Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.
-- If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools. """
+- If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools.
+
+### False Positive Analysis
+- Validate the unusual Windows process is not related to new benign software installation activity. If related to
+legitimate software, this can be done by leveraging the exception workflow in the Kibana Security App or Elasticsearch
+API to tune this rule to your environment
+- Try to understand the context of the execution by thinking about the user, machine, or business purpose.  It's possible that a small number of endpoints
+such as servers that have very unique software that might appear to be unusual, but satisfy a specific business need.
+
+### Related Rules
+- Anomalous Windows Process Creation
+- Unusual Windows Path Activity
+- Unusual Windows Process Calling the Metadata Service
+
+### Response and Remediation
+- This rule is related to process execution events and should be immediately reviewed and investigated to determine if malicious
+- Based on validation and if malicious, the impacted machine should be isolated and analyzed to determine other post-compromise
+behavior such as setting up persistence or performing lateral movement.
+- Look into preventive measures such as Windows Defender Application Control and AppLocker to gain better control on
+what is allowed to run on Windows infrastructure.
+"""
 references = ["https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
 risk_score = 21
 rule_id = "6d448b96-c922-4adb-b51c-b767f1ea5b76"

rules/windows/credential_access_mimikatz_powershell_module.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/12/07"
 maturity = "development"
-updated_date = "2021/06/17"
+updated_date = "2021/09/09"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,43 @@ license = "Elastic License v2"
 name = "Mimikatz Powershell Module Activity"
 note = """## Triage and analysis
 
-This rule identifies an adversary attempt to collect, decrypt, and/or use cached credentials. Alerts from this rule should be prioritized because an adversary has an initial foothold onto an endpoint."""
+### Investigating Mimikatz PowerShell Activity
+
+[Mimikatz](https://github.com/gentilkiwi/mimikatz) is an open-source tool used to collect, decrypt, and/or use cached
+credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained
+an initial foothold onto an endpoint and are looking to elevate privileges and seek out additional authentication objects
+such as tokens/hashes/credentials that can then be used to laterally move and pivot across a network.
+
+#### Possible investigation steps:
+- This specific rule is based on Mimikatz command-line parameters used to dump credentials from the Local Security
+Authority Subsystem Service (LSASS). Any activity triggered from this rule should be treated with high priority as it
+typically represents an active adversary.
+- Any kind of available host-based events or logs such as Windows Security Events, PowerShell logging and EDR events should
+be used to seek further understanding around the events that led up to the rule as well as activity found shortly after the event.
+- Further examination should include reviewing network logs to determine potential lateral movement.
+- Validate that the source of the Mimikatz activity was not from an authorized source such as automated testing such as
+Atomic Red Team or through offensive/compromise assessments.
+
+### False Positive Analysis
+- This rule should be on the higher confidence side of true positive activity therefore any testing such as offensive
+/compromise engagements should be ruled out before invoking incident response procedures
+
+### Related Rules
+- Mimikatz Memssp Log File Detected
+- Creation or Modification of Domain Backup DPAPI private key
+- Modification of WDigest Security Provider
+
+### Response and Remediation
+- Immediate response should be taken to review, investigate and potentially isolate activity to prevent further post-compromise
+behavior
+- During credential dump compromises, investigate the registry in order to check the number of cached users that have
+used the machine. These users should have their password reset.
+- Validate that cleartext passwords are disabled in memory for use with `WDigest`.
+- Look into preventing access to `LSASS` using capabilities such as LSA protection or leveraging AV/EDR tools that provide
+this capability.
+- This [resource](https://adsecurity.org/?page_id=1821) provided by ADSecurity should be used as required reading for
+detecting/preventing and understanding the different Mimikatz components.
+"""
 references = ["https://attack.mitre.org/software/S0002/"]
 risk_score = 99
 rule_id = "ac96ceb8-4399-4191-af1d-4feeac1f1f46"

rules/windows/defense_evasion_defender_exclusion_via_powershell.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/07/20"
 maturity = "production"
-updated_date = "2021/07/20"
+updated_date = "2021/09/09"
 
 [rule]
 author = ["Elastic"]
@@ -15,7 +15,38 @@ license = "Elastic License v2"
 name = "Windows Defender Exclusions Added via PowerShell"
 note = """## Triage and analysis
 
-Detections should be investigated to identify if the activity corresponds to legitimate activity used to put in exceptions for Windows Defender. As this rule detects post-exploitation process activity, investigations into this should be prioritized."""
+### Investigating Windows Defender Exclusions
+
+Microsoft Windows Defender is an anti-virus product built-in within Microsoft Windows. Since this software product is
+used to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration
+settings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of the more
+notable [examples](https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/) was observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defense to avoid detection.
+
+#### Possible investigation steps:
+- With this specific rule, it's completely possible to trigger detections on network administrative activity or benign users
+using scripting and PowerShell to configure the different exclusions for Windows Defender. Therefore, it's important to
+identify the source of the activity first and determine if there is any mal-intent behind the events.
+- The actual exclusion such as the process, the file or directory should be reviewed in order to determine the original
+intent behind the exclusion. Is the excluded file or process malicious in nature or is it related to software that needs
+to be legitimately whitelisted from Windows Defender?
+
+### False Positive Analysis
+- This rule has a higher chance to produce false positives based on the nature around configuring exclusions by possibly
+a network administrator. In order to validate the activity further, review the specific exclusion made and determine based
+on the exclusion of the original intent behind the exclusion. There are often many legitimate reasons why exclusions are made
+with Windows Defender so it's important to gain context around the exclusion.
+
+### Related Rules
+- Windows Defender Disabled via Registry Modification
+- Disabling Windows Defender Security Settings via PowerShell
+
+### Response and Remediation
+- Since this is related to post-exploitation activity, immediate response should be taken to review, investigate and
+potentially isolate further activity
+- If further analysis showed malicious intent was behind the Defender exclusions, administrators should remove
+the exclusion and ensure antimalware capability has not been disabled or deleted
+- Exclusion lists for antimalware capabilities should always be routinely monitored for review
+"""
 references = ["https://www.bitdefender.com/files/News/CaseStudies/study/400/Bitdefender-PR-Whitepaper-MosaicLoader-creat5540-en-EN.pdf"]
 risk_score = 47
 rule_id = "2c17e5d7-08b9-43b2-b58a-0270d65ac85b"

rules/windows/discovery_adfind_command_activity.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/10/19"
 maturity = "production"
-updated_date = "2021/05/10"
+updated_date = "2021/09/13"
 
 [rule]
 author = ["Elastic"]
@@ -17,7 +17,40 @@ license = "Elastic License v2"
 name = "AdFind Command Activity"
 note = """## Triage and analysis
 
-`AdFind.exe` is a legitimate domain query tool. Rule alerts should be investigated to identify if the user has a role that would explain using this tool and that it is being run from an expected directory and endpoint. Leverage the exception workflow in the Kibana Security App or Elasticsearch API to tune this rule to your environment."""
+### Investigating AdFind Command Activity
+
+[AdFind](http://www.joeware.net/freetools/tools/adfind/) is a freely available command-line tool used to retrieve information from
+Activity Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways
+they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and
+understand subnets and domain information. There are many [examples](https://thedfirreport.com/category/adfind/)
+observed where this tool has been adopted by ransomware and criminal groups and used in compromises.
+
+#### Possible investigation steps:
+- `AdFind` is a legitimate Active Directory enumeration tool used by network administrators, it's important to understand
+the source of the activity.  This could involve identifying the account using `AdFind` and determining based on the command-lines
+what information was retrieved, then further determining if these actions are in scope of that user's traditional responsibilities.
+- In multiple public references, `AdFind` is leveraged after initial access is achieved, review previous activity on impacted
+machine looking for suspicious indicators such as previous anti-virus/EDR alerts, phishing emails received, or network traffic
+to suspicious infrastructure
+
+### False Positive Analysis
+- This rule has the high chance to produce false positives as it is a legitimate tool used by network administrators. One
+option could be whitelisting specific users or groups who use the tool as part of their daily responsibilities. This can
+be done by leveraging the exception workflow in the Kibana Security App or Elasticsearch API to tune this rule to your environment
+- Malicious behavior with `AdFind` should be investigated as part of a step within an attack chain. It doesn't happen in
+isolation, so reviewing previous logs/activity from impacted machines could be very telling.
+
+### Related Rules
+- Windows Network Enumeration
+- Enumeration of Administrator Accounts
+- Enumeration Command Spawned via WMIPrvSE
+
+### Response and Remediation
+- Immediate response should be taken to validate activity, investigate and potentially isolate activity to prevent further
+post-compromise behavior
+- It's important to understand that `AdFind` is an Active Directory enumeration tool and can be used for malicious or legitimate
+purposes, so understanding the intent behind the activity will help determine the appropropriate response.
+"""
 references = [
     "http://www.joeware.net/freetools/tools/adfind/",
     "https://thedfirreport.com/2020/05/08/adfind-recon/",

rules/windows/lateral_movement_dns_server_overflow.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/07/16"
 maturity = "production"
-updated_date = "2021/05/10"
+updated_date = "2021/09/08"
 
 [rule]
 author = ["Elastic"]
@@ -23,11 +23,40 @@ name = "Abnormally Large DNS Response"
 note = """## Triage and analysis
 
 ### Investigating Large DNS Responses
-Detection alerts from this rule indicate an attempt was made to exploit CVE-2020-1350 (SigRed) through the use of large DNS responses on a Windows DNS server. Here are some possible avenues of investigation:
-- Investigate any corresponding Intrusion Detection Signatures (IDS) alerts that can validate this detection alert.
-- Examine the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data.
+Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS
+server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350)
+also known as [SigRed](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020.
+
+#### Possible investigation steps:
+- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate
+the source of the incoming traffic and determine if this activity has been observed previously within an environment.
+- Activity can be further investigated and validated by reviewing available corresponding Intrusion Detection Signatures (IDS) alerts associated with activity.
+- Further examination can be made by reviewing the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data.
 - Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale Internet vulnerability scanning.
-- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment."""
+- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment.
+
+#### False Positive Analysis
+- Based on this rule which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes
+and related to legitimate behavior.  In packet capture files received by the [SANS Internet Storm Center](https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/), byte responses
+were all observed as greater than 65k bytes.
+- This activity has the ability to be triggered from compliance/vulnerability scanning or compromise assessment, it's
+important to determine the source of the activity and potential whitelist the source host
+
+
+### Related Rules
+- Unusual Child Process of dns.exe
+- Unusual File Modification by dns.exe
+
+### Response and Remediation
+- Review and implement the above detection logic within your environment using technology such as Endpoint security, Winlogbeat, Packetbeat, or network security monitoring (NSM) platforms such as Zeek or Suricata.
+- Ensure that you have deployed the latest Microsoft [Security Update](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350) (Monthly Rollup or Security Only) and restart the
+patched machines. If unable to patch immediately: Microsoft [released](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability) a registry-based workaround that doesn’t require a
+restart. This can be used as a temporary solution before the patch is applied.
+- Maintain backups of your critical systems to aid in quick recovery.
+- Perform routine vulnerability scans of your systems, monitor [CISA advisories](https://us-cert.cisa.gov/ncas/current-activity) and patch identified vulnerabilities.
+- If observed true positive activity, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior.
+"""
+
 references = [
     "https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/",
     "https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/",

rules/windows/lateral_movement_scheduled_task_target.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2020/11/20"
 maturity = "production"
-updated_date = "2021/05/10"
+updated_date = "2021/09/13"
 
 [rule]
 author = ["Elastic"]
@@ -13,7 +13,39 @@ license = "Elastic License v2"
 name = "Remote Scheduled Task Creation"
 note = """## Triage and analysis
 
-Decode the base64 encoded tasks actions registry value to investigate the task configured action."""
+### Investigating Creation of Remote Scheduled Tasks
+
+[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism used for persistence and executing programs. These features can
+be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries.
+When investigating scheduled tasks that have been set-up remotely, one of the first methods should be determining the
+original intent behind the configuration and verify if the activity is tied to benign behavior such as software installations or any kind
+of network administrator work. One objective for these alerts is to understand the configured action within the scheduled
+task, this is captured within the registry event data for this rule and can be base64 decoded to view the value.
+
+#### Possible investigation steps:
+- Review the base64 encoded tasks actions registry value to investigate the task configured action.
+- Determine if task is related to legitimate or benign behavior based on the corresponding process or program tied to the
+scheduled task.
+- Further examination should include both the source and target machines where host-based artifacts and network logs
+should be reviewed further around the time window of the creation of the scheduled task.
+
+### False Positive Analysis
+- There is a high possibility of benign activity tied to the creation of remote scheduled tasks as it is a general feature
+within Windows and used for legitimate purposes for a wide range of activity. Any kind of context should be found to
+further understand the source of the activity and determine the intent based on the scheduled task contents.
+
+### Related Rules
+- Service Command Lateral Movement
+- Remotely Started Services via RPC
+
+### Response and Remediation
+- This behavior represents post-exploitation actions such as persistence or lateral movement, immediate response should
+be taken to review and investigate the activity and potentially isolate involved machines to prevent further post-compromise
+behavior.
+- Remove scheduled task and any other related artifacts to the activity.
+- Review privileged account management and user account management settings such as implementing GPO policies to further
+restrict activity or configure settings that only allow Administrators to create remote scheduled tasks.
+"""
 risk_score = 47
 rule_id = "954ee7c8-5437-49ae-b2d6-2960883898e9"
 severity = "medium"

rules/windows/persistence_evasion_registry_startup_shell_folder_modified.toml

@@ -1,7 +1,7 @@
 [metadata]
 creation_date = "2021/03/15"
 maturity = "production"
-updated_date = "2021/05/10"
+updated_date = "2021/09/10"
 
 [rule]
 author = ["Elastic"]
@@ -16,7 +16,37 @@ license = "Elastic License v2"
 name = "Suspicious Startup Shell Folder Modification"
 note = """## Triage and analysis
 
-Verify file creation events in the new Windows Startup folder location."""
+### Investigating Suspicious Startup Shell Activity
+
+Techniques used within malware and by adversaries often leverage the Windows registry to store malicious programs for
+persistence. Startup shell folders are often targeted as they are not as prevalent as normal Startup folder paths so this
+behavior may evade existing AV/EDR solutions. Another preference is that these programs might run with higher privileges
+which can be ideal for an attacker.
+
+#### Possible investigation steps:
+- Review the source process and related file tied to the Windows Registry entry
+- Validate the activity is not related to planned patches, updates, network administrator activity or legitimate software
+installations
+- Determine if activity is unique by validating if other machines in same organization have similar entry
+
+### False Positive Analysis
+- There is a high possibility of benign legitimate programs being added to Shell folders. This activity could be based
+on new software installations, patches, or any kind of network administrator related activity. Before entering further
+investigation, this activity should be validated that is it not related to benign activity
+
+### Related Rules
+- Startup or Run Key Registry Modification
+- Persistent Scripts in the Startup Directory
+
+### Response and Remediation
+- Activity should first be validated as a true positive event if so then immediate response should be taken to review,
+investigate and potentially isolate activity to prevent further post-compromise behavior
+- The respective binary or program tied to this persistence method should be further analyzed and reviewed to understand
+it's behavior and capabilities
+- Since this activity is considered post-exploitation behavior, it's important to understand how the behavior was first
+initialized such as through a macro-enabled document that was attached in a phishing email. By understanding the source
+of the attack, this information can then be used to search for similar indicators on other machines in the same environment.
+"""
 risk_score = 73
 rule_id = "c8b150f0-0164-475b-a75e-74b47800a9ff"
 severity = "high"