Overview of Windows Threats Category
This document provides an overview of the rule sets in the Windows Threats category, the required data sources, and configuration you can use to tune the alerts generated by these rule sets.
These rules sets provide you with immediately actionable context, through detections and alerts, indicating what should be further investigated from endpoint alert data. They help enhance security event monitoring and triage capacity, enabling you to focus your attention on alerts as well as cases (collections of alerts) that are malicious and actionable. These curated analytics allow you to prioritize the response to endpoint alerts, provide additional context for investigations, and improve security event monitoring using endpoint logs.
Rule sets in the Windows Threats category help identify threats in Microsoft Windows environments using Endpoint Detection and Response (EDR) logs. This category includes the following rule sets:
- Anomalous PowerShell: Identifies PowerShell commands containing obfuscation techniques or other anomalous behavior.
- Crypto Activity: Activity associated with suspicious crypto currency.
- Hacktool: Freely available tool that may be deemed suspicious, but may potentially be legitimate depending on the organization's use.
- Info Stealer: Tools used to steal credentials including passwords, cookies, crypto wallets, and other sensitive credentials.
- Initial Access: Tools used to gain initial execution on a machine with suspicious behavior.
- Legitimate but Misused: Legitimate software that is known to be abused for malicious purposes.
- Living off the Land (LotL) Binaries: Tools built-in to Microsoft Windows operating systems that can be abused by threat actors for malicious purposes.
- Named Threat: Behavior associated with a known threat actor.
- Ransomware: Activity associated with ransomware.
- RAT: Tools used to provide remote command and control of network assets.
- Security Posture Downgrade: Activity attempting to disable or decrease the effectiveness of security tools.
- Suspicious Behavior: General suspicious behavior.
- Mandiant Front-Line Threats: This rule set contains rules derived from Mandiant's investigation and response to active incidents across the world. These rules cover commonly seen TTPs such as execution through script interpreters (T1059), user execution (T1204), and system binary proxy execution (T1218).
- Mandiant Intel Emerging Threats: This rule set contains rules derived from Mandiant Intelligence Campaigns and Significant Events, which cover highly impactful geopolitical and threat activity, as assessed by Mandiant. This activity may include geopolitical conflict, exploitation, phishing, malvertising, ransomware, and supply chain compromises.
- Alert Prioritization for Endpoints: This rule set utilizes the capability
previously found in the Mandiant Automated Defense - Alert, Investigation &
Prioritization product. This rule set identifies patterns such as the
following:
- Attack progression: Internal assets exhibiting multiple signs of compromise that, when considered together, increases the likelihood the system is compromised and therefore should be investigated.
- Malware on internal assets: Internal assets exhibiting signs that malware has reached the file system and should be investigated. Attackers often stage malicious code on the file system after a successful exploitation attempt.
- Unauthorized hack tools: Internal assets exhibiting exploitation tool activity indicating system compromise. Exploitation tools are publicly available software or hack tools that can be used to gain and expand access on systems and are used by both attackers and Red teams. Observance of these tools should be investigated if use is not explicitly authorized by a system or account.
- Unusual process behaviors: Internal assets where common executables are being used in an unusual manner is a strong indicator of a compromised host. Occurrence of unusual "Living off the Land" behaviors should be investigated.
The Alert Prioritization for Endpoints rule set is available with a Google Security Operations Enterprise Plus license.
Supported devices and log types
This section lists the data required by each rule set.
Rule sets in the Windows Threats category have been tested and are supported with the following Google Security Operations supported EDR data sources:
- Carbon Black (
CB_EDR
) - Microsoft Sysmon (
WINDOWS_SYSMON
) - SentinelOne (
SENTINEL_EDR
) - Crowdstrike Falcon (
CS_EDR
)
Rule sets in the Windows Threats category are being tested and optimized for the following Google Security Operations supported EDR data sources:
- Tanium
- Cybereason EDR (
CYBEREASON_EDR
) - Lima Charlie (
LIMACHARLIE_EDR
) - OSQuery
- Zeek
- Cylance (
CYLANCE_PROTECT
)
Contact your Google Security Operations representative if you are collecting endpoint data using different EDR software.
For a list of all Google Security Operations supported data sources, see Supported default parsers.
Required fields needed by Windows Threats category
The following section describes specific data needed by rule sets in the Windows Threats category to get the greatest benefit. Make sure that your devices are configured to record the following data to device event logs.
- Event Timestamp
- Hostname: Hostname of the system where the EDR software is running.
- Principal Process: Name of the current process being logged.
- Principal Process Path: Location on disk of the current running process, if available.
- Principal Process Command Line: Command line parameters of the process, if available.
- Target Process: Name of the spawned process being launched by the principal process.
- Target Process Path: Location on disk of the target process, if available.
- Target Process Command Line: Command line parameters of the target process, if available.
- Target Process SHA256\MD5: Checksum of the target process, if available. This is used to tune alerts.
- User ID: The username of the principal process.
Alert Prioritization for Endpoints rule set
This rule set has been tested and are supported with the following Google Security Operations supported EDR data sources:
- Microsoft Defender for Endpoint (
MICROSOFT_GRAPH_ALERT
) - SentinelOne (
SENTINEL_EDR
) - Crowdstrike Falcon (
CS_EDR
)
Alert Prioritization for Endpoints rule set UDM fields
The following section describes UDM fields data needed by the Alert Prioritization for Endpoints rule set. If you modify a default parser by creating your own custom parser, make sure you don't change the mapping of these fields. If you change how these fields are mapped,you may impact the behavior of this feature.
UDM field name | Description |
---|---|
metadata.event_type |
A normalized event type. |
metadata.product_name |
The name of the product. |
security_result.detection_fields["externall_api_type"] |
Fields to filter for events of interest. |
security_result.threat_name |
A vendor-assigned classification of a threat such as a malware family. |
security_result.category_details |
The vendor specific malware category |
security_result.summary |
A summary of the alert. |
security_result.rule_name |
An alert name provided by the vendor. |
security_result.attack_details |
Used to identify Mitre ATT&CK tactics and techniques. |
security_result.description |
A short description for the alert. |
security_result.action |
Action taken by the control. |
principal.process.file.names |
The filename of the running process. |
principal.process.file.full_path |
Location on disk of the current running process, if available. |
principal.process.command_line |
Command line parameters of the process, if available. |
principal.asset.hostname |
Hostname of the system where the EDR software is running. |
principal.hostname |
Hostname of the system where the EDR software is running. |
principal.user.userid |
The username of the principal process. |
target.file.full_path |
The name of the file that the principal is interacting with. |
target.file.md5/sha256 |
Checksum of the target file, if available. |
Tuning alerts returned by Windows Threats category
You can reduce the number of detections a rule or rule set generates using rule exclusions.
A rule exclusion defines the criteria used to exclude an event from being evaluated by the rule set, or by specific rules in the rule set. Create one or more rule exclusions to help reduce the volume of detections. See Configure rule exclusions for information about how to do this.
For example, you might exclude events based on the following information:
principal.hostname
principal.process.command_line
principal.user.userid