#############
# Automatically generated by generator.py in splunk/security_content
# On Date: 2024-04-17T22:08:10 UTC
# Author: Splunk Threat Research Team - Splunk
# Contact: research@splunk.com
#############

### DETECTIONS ###

[savedsearch://ESCU - Detect New Login Attempts to Routers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search queries the authentication logs for assets that are categorized as routers in the ES Assets and Identity Framework, to identify connections that have not been seen before in the last 30 days.
how_to_implement = To successfully implement this search, you must ensure the network router devices are categorized as "router" in the Assets and identity table. You must also populate the Authentication data model with logs related to users authenticating to routing infrastructure.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = Legitimate router connections may appear as new connections
providing_technologies = null

[savedsearch://ESCU - Detect Risky SPL using Pretrained ML Model - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic uses a pretrained machine learning text classifier to detect potentially risky commands. The model is trained independently and then the model file is packaged within ESCU for usage. A command is deemed risky based on the presence of certain trigger keywords, along with the context and the role of the user (please see references). The model uses custom features to predict whether a SPL is risky using text classification. The model takes as input the command text, user and search type and outputs a risk score between [0,1]. A high score indicates higher likelihood of a command being risky. This model is on-prem only.
how_to_implement = This detection depends on the MLTK app which can be found here - https://splunkbase.splunk.com/app/2890/ and the Splunk Audit datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. Additionally, you need to be ingesting logs which include Search_Activity.search, Search_Activity.user, Search_Activity.search_type from your endpoints. The risk score threshold should be adjusted based on the environment. The detection uses a custom MLTK model hence we need a few more steps for deployment, as outlined here - https://gist.github.com/ksharad-splunk/be2a62227966049047f5e5c4f2adcabb.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if suspicious behavior is observed, as determined by frequent usage of risky keywords.
providing_technologies = null

[savedsearch://ESCU - Email Attachments With Lots Of Spaces - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Attackers often use spaces as a means to obfuscate an attachment's file extension. This search looks for messages with email attachments that have many spaces within the file names.
how_to_implement = You need to ingest data from emails. Specifically, the sender's address and the file names of any attachments must be mapped to the Email data model. The threshold ratio is set to 10%, but this value can be configured to suit each environment. \
 **Splunk Phantom Playbook Integration**\
If Splunk Phantom is also configured in your environment, a playbook called "Suspicious Email Attachment Investigate and Delete" can be configured to run when any results are found by this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/` and add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search. The notable event will be sent to Phantom and the playbook will gather further information about the file attachment and its network behaviors. If Phantom finds malicious behavior and an analyst approves of the results, the email will be deleted from the user's inbox.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = None at this time
providing_technologies = null

[savedsearch://ESCU - Email files written outside of the Outlook directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks at the change-analysis data model and detects email files created outside the normal Outlook directory.
how_to_implement = To successfully implement this search, you must be ingesting data that records the file-system activity from your hosts to populate the Endpoint.Filesystem data model node. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or by other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report file-system reads and writes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.001"], "nist": ["DE.CM"]}
known_false_positives = Administrators and users sometimes prefer backing up their email data by moving the email files into a different folder. These attempts will be detected by the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Email servers sending high volume traffic to hosts - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for an increase of data transfers from your email server to your clients. This could be indicative of a malicious actor collecting data using your email server.
how_to_implement = This search requires you to be ingesting your network traffic and populating the Network_Traffic data model.  Your email servers must be categorized as "email_server" for the search to work, as well. You may need to adjust the deviation_threshold and minimum_data_samples values based on the network traffic in your environment. The "deviation_threshold" field is a multiplying factor to control how much variation you're willing to tolerate. The "minimum_data_samples" field is the minimum number of connections of data samples required for the statistic to be valid.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.AE"]}
known_false_positives = The false-positive rate will vary based on how you set the deviation_threshold and data_samples values. Our recommendation is to adjust these values based on your network traffic to and from your email servers.
providing_technologies = null

[savedsearch://ESCU - Monitor Email For Brand Abuse - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for emails claiming to be sent from a domain similar to one that you want to have monitored for abuse.
how_to_implement = You need to ingest email header data. Specifically the sender's address (src_user) must be populated.  You also need to have run the search "ESCU - DNSTwist Domain Names", which creates the permutations of the domain that will be checked for.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = None at this time
providing_technologies = null

[savedsearch://ESCU - No Windows Updates in a time frame - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for Windows endpoints that have not generated an event indicating a successful Windows update in the last 60 days. Windows updates are typically released monthly and applied shortly thereafter. An endpoint that has not successfully applied an update in this time frame indicates the endpoint is not regularly being patched for some reason.
how_to_implement = To successfully implement this search, it requires that the 'Update' data model is being populated. This can be accomplished by ingesting Windows events or the Windows Update log via a universal forwarder on the Windows endpoints you wish to monitor. The Windows add-on should be also be installed and configured to properly parse Windows events in Splunk. There may be other data sources which can populate this data model, including vulnerability management systems.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - Okta Authentication Failed During MFA Challenge - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies an authentication attempt event against an Okta tenant that fails during the Multi-Factor Authentication (MFA) challenge. This detection is written against the Authentication datamodel and we look for a specific failed events where the authentication signature is `user.authentication.auth_via_mfa`. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]}
known_false_positives = A user may have accidentally entered the wrong credentials during the MFA challenge. If the user is new to MFA, they may have trouble authenticating. Ensure that the user is aware of the MFA process and has the correct credentials.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta IDP Lifecycle Modifications - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This detection identifies modifications to Okta Identity Provider (IDP) lifecycle events, such as creation, activation, deactivation, and deletion of IDP configurations. Monitoring these events is crucial for maintaining the integrity and security of authentication mechanisms within an organization. By detecting unauthorized or anomalous changes, organizations can quickly respond to potential security breaches or misconfigurations, ensuring that their identity management systems remain secure and operational.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"]}
known_false_positives = It's possible for legitimate administrative actions or automated processes to trigger this detection, especially if there are bulk modifications to Okta IDP lifecycle events. Review the context of the modification, such as the user making the change and the specific lifecycle event modified, to determine if it aligns with expected behavior.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta MFA Exhaustion Hunt - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies patterns within Okta data to determine the amount of successful and failed pushes. Based on that, eval statements determine a finding of whether this is suspicious or not. The events are within a window of time and may be tuned as needed.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning is complete.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Mismatch Between Source and Response for Verify Push Request - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies variations in client-based values for source and response events to identify suspicious request behavior. The detection is enhanced if the org is evaluating behavior conditions in sign-on policies using Okta Behavior Detection. NOTE: This detection requires the use of Okta Identity Engine (OIE) and will not function on Okta Classic.\
For each Okta Verify Push challenge, the following two events are recorded in Okta System Log \
Source of Push (Sign-In) \
eventType eq \"system.push.send_factor_verify_push\" \
User Push Response (Okta Verify client) \
eventType eq "user.authentication.auth_via_mfa" AND debugContext.debugData.factor eq "OKTA_VERIFY_PUSH" \
In sequence, the logic for the analytic - \
* Groups by SessionID and retrieves any system.push.send_factor_verify_push events (the source of the push) and user.authentication.auth_via_mfa events where the factor is OKTA_VERIFY_PUSH - (the user response to the push) \
* Counts the total number of push events, successful authentication events, and any push sources where the client is a new device. \ * Creates a ratio of successful sign-ins to pushes. \
* If the ratio (currently tuned aggressively) indicates push spam, or if a user has rejected a push, the detection proceeds to evaluate whether there is more than one IP address used during the session (session roaming) and the presence of both a new IP and new device during the session.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on organization size and configuration of Okta. Monitor, tune and filter as needed.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Multi-Factor Authentication Disabled - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies an attempt to disable multi-factor authentication for an Okta user. An adversary who has obtained access to an Okta tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = Legitimate use case may require for users to disable MFA. Filter lightly and monitor for any unusual activity.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Multiple Accounts Locked Out - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic utilizes the user.acount.lock event to identify multiple Okta accounts locking out in a short period of time. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold set by the organization. Monitoring for multiple account lockouts can help detect potential account takeover attempts or unauthorized access to Okta accounts.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]}
known_false_positives = Multiple account lockouts may be also triggered by an application malfunction. Filter as needed, and monitor for any unusual activity.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Multiple Failed MFA Requests For User - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Okta tenant. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Okta tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.AE"]}
known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed and monitor for any unusual activity.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Multiple Failed Requests to Access Applications - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies multiple failed app requests in an attempt to identify the reuse a stolen web session cookie. The logic of the analytic is as follows: \ * Retrieves policy evaluation and SSO details in events that contain the Application requested \
* Formats target fields so we can aggregate specifically on Applications (AppInstances) \
* Groups by User, Session and IP \
* Creates a ratio of successful SSO events to total MFA challenges related to Application Sign On Policies \
* Alerts when more than half of app sign on events are unsuccessful, and challenges were unsatisfied for more than three apps.
how_to_implement = This analytic is specific to Okta and requires Okta:im2 logs to be ingested.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550.004", "T1538"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present based on organization size and configuration of Okta.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Multiple Users Failing To Authenticate From Ip - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes) within an Okta tenant. Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach security by targeting multiple user accounts.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003"], "nist": ["DE.AE"]}
known_false_positives = A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta New API Token Created - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies when a new API token is created within an Okta tenant. An adversary may create a new API token to maintain persistence within the environment. Monitoring for new API tokens can help detect potential account takeover attempts or unauthorized access to Okta accounts.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta New Device Enrolled on Account - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = The following analytic identifies when a new device is enrolled on an Okta account. This behavior is indicative of a user adding a new device to their account. This activity is common when a user is setting up a new device or when a user has lost access to their previous device. However, this activity can also be indicative of an adversary adding a new device to an account to maintain access to an account. Monitoring for this activity can help detect potential account takeover attempts or unauthorized access to Okta accounts.
how_to_implement = The analytic leverages Okta OktaIm2 logs to be ingested using the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]}
known_false_positives = It is possible that the user has legitimately added a new device to their account. Please verify this activity.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Phishing Detection with FastPass Origin Check - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = The following analytic identifies when Okta''s FastPass prevents known phishing sites. When your users are enrolled in FastPass, Okta can provide defenders a high-fidelity signal for when user applications are being targeted by attackers wielding real-time (AiTM) proxies. Okta''s Defensive Cyber Operations team routinely identifies phishing infrastructure configured to imitate an Okta sign-in page and proactively notify Okta customers when suspicious infrastructure we detect appears to be targeting their users. Since March 2020, we have delivered over 1000 notifications to customers.
how_to_implement = This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001", "T1556"], "nist": ["DE.CM"]}
known_false_positives = Fidelity of this is high as Okta is specifying malicious infrastructure. Filter and modify as needed.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Risk Threshold Exceeded - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This correlation computes the risk events associated with the detection analytics from "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories. This analytic will trigger a notable event in your incident review when there are 5 or more distinct TTPs related to these analytic stories in the last 24 hours. This incident highlights potentially suspicious activity by a compromised user.
how_to_implement = This search leverages the Risk Framework from Enterprise Security. Ensure that "Suspicious Okta Activity", "Okta Account Takeover", and "Okta MFA Exhaustion" analytic stories are enabled. TTPs may be set to Notables for point detections; anomalies should not be notables but rather risk generators. The correlation relies on risk before generating a notable. Modify the value as needed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1110"], "nist": ["DE.AE"]}
known_false_positives = False positives will be limited to the number of events generated by the analytics tied to the stories. Analytics will need to be tested and tuned, and the risk score reduced as needed based on the organization.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Successful Single Factor Authentication - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This analytic identifies successful authentication events against the Okta Dashboard for accounts without Multi-Factor Authentication enabled. It specifically searches for events where "Okta Verify" is not detected during authentication. This could indicate a misconfiguration, a policy violation, or an account takeover attempt that warrants investigation. If your organization has other authenticators configured in the environment, consider excluding those from the "targets" in the detection search.
how_to_implement = This detection utilizes logs from Okta environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.AE"]}
known_false_positives = Although not recommended, certain users may be exempt from multi-factor authentication. Adjust the filter as necessary.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Suspicious Activity Reported - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This event is generated when an associate receives an email from Okta inquiring whether a login attempt was suspicious. If the associate deems it suspicious, an event is generated for review.
how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553). Additionally, it necessitates the activation of suspicious activity reporting and training for associates to report such activities.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be minimal, given the high fidelity of this detection. marker.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Suspicious Use of a Session Cookie - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This analytic identifies instances where multiple client attributes (such as IP, User Agent, etc.) associated with the same Device Token change for a specific user. It aims to detect scenarios where an adversary might attempt to reuse a stolen web session cookie. \
* It retrieves policy evaluation events from successful authentication attempts. \
* It aggregates and groups these events by Device Token and User, providing the first policy evaluation event within the search window. \
* It checks for the presence of more than one IP and whether there are multiple OS or browsers for each User/Device Token combination.
how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1539"], "nist": ["DE.AE"]}
known_false_positives = False positives may occur, depending on the organization's size and the configuration of Okta.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta ThreatInsight Threat Detected - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = This anomaly is based on the identification of threats by Okta ThreatInsight. It allows for the escalation of risk based on src_ip or the addition of fields for further tracking. Possible identifications include password spraying, login failures, and login failures with a high count of unknown users.
how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.AE"]}
known_false_positives = False positives may occur. It is recommended to fine-tune Okta settings and the analytic to ensure high fidelity. Adjust the risk score as necessary.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Unauthorized Access to Application - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This search detects instances where a user attempts to access an Okta application that has not been assigned to them. Such unauthorized access to applications poses a significant security risk, potentially leading to the exposure of sensitive information, disruption of services, and breaches of data protection laws. Ensuring that only authorized users have access to applications is crucial for maintaining a secure and compliant IT environment.
how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments and requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.004"], "nist": ["DE.AE"]}
known_false_positives = There is a possibility that a user may accidentally click on the wrong application, which could trigger this event. It is advisable to verify the location from which this activity originates.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta User Logins from Multiple Cities - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = This search identifies instances where the same user logs in from different cities within a 24-hour period, potentially indicating a compromised account. Such behavior may be indicative of an attacker attempting to gain unauthorized access to an Okta account from multiple locations. Investigating and responding to such incidents promptly is crucial to prevent account takeovers and data breaches.
how_to_implement = This detection utilizes logs from Okta Identity Management (IM) environments. It requires the ingestion of OktaIm2 logs through the Splunk Add-on for Okta Identity Cloud (https://splunkbase.splunk.com/app/6553).
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1586.003"], "nist": ["DE.AE"]}
known_false_positives = It is uncommon for a user to log in from multiple cities simultaneously, which may indicate a false positive.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Path traversal SPL injection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On May 3rd, 2022, Splunk published a security advisory for a Path traversal in search parameter that can potentiall allow SPL injection. An attacker can cause the application to load data from incorrect endpoints, urls leading to outcomes such as running arbitrary SPL queries.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This search will provide search UI requests with path traversal parameter ("../../../../../../../../../") which shows exploitation attempts. This detection is meant for on premise environments, and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.CM"]}
known_false_positives = This search may find additional path traversal exploitation attempts.
providing_technologies = null

[savedsearch://ESCU - PingID Mismatch Auth Source and Verification Response - Rule]
type = detection
asset_type = Identity
confidence = medium
explanation = The following analytic identifies variations in the authentication event IP address versus the verification response event IP address to identify suspicious sign-in behavior. Currently this detection is configured to identify when the originating country of an authentication request is different than the verification country.
how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated by users working out the geographic region where the organizations services or technology is hosted.
providing_technologies = ["Ping ID"]

[savedsearch://ESCU - PingID Multiple Failed MFA Requests For User - Rule]
type = detection
asset_type = Identity
confidence = medium
explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a PingID (PingOne) environment. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 10 minutes. PingID environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1621", "T1078", "T1110"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated by normal provisioning workflows for user device registration.
providing_technologies = ["Ping ID"]

[savedsearch://ESCU - PingID New MFA Method After Credential Reset - Rule]
type = detection
asset_type = Identity
confidence = medium
explanation = A common social engineering technique used by threat actors is the impersonation of a valid user to organizational support staff for a password reset. During the same support call or quickly afterwards the threat actor will request provisioning of a new MFA device. This does not require malware or phishing infrastructure and has proven to be successful in numerous historical attacks. This detection looks for the pattern of password reset, followed by MFA device provisioning.
how_to_implement = Target environment must ingest Windows Event Log and PingID(PingOne) data sources. Specifically from logs from Active Directory Domain Controllers and JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated by normal provisioning workflows that generate a password reset followed by a device registration.
providing_technologies = ["Ping ID"]

[savedsearch://ESCU - PingID New MFA Method Registered For User - Rule]
type = detection
asset_type = Identity
confidence = medium
explanation = The following analytic identifies the registration of a new Multi Factor authentication method for a PingID (PingOne) account. Adversaries who have obtained unauthorized access to a user account may register a new MFA method to maintain persistence.
how_to_implement = Target environment must ingest JSON logging from a PingID(PingOne) enterprise environment, either via Webhook or Push Subscription.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1621", "T1556.006", "T1098.005"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated by normal provisioning workflows for user device registration.
providing_technologies = ["Ping ID"]

[savedsearch://ESCU - Splunk Absolute Path Traversal Using runshellscript - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can exploit an absolute path traversal to execute arbitrary code that is located on a separate disk.
how_to_implement = Must have access to internal indexes. Only applies to Splunk on Windows versions.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.AE"]}
known_false_positives = The command runshellscript can be used for benign purposes. Analyst will have to review the searches and determined maliciousness specially by looking at targeted script.
providing_technologies = null

[savedsearch://ESCU - Splunk Account Discovery Drilldown Dashboard Disclosure - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Splunk drilldown vulnerability disclosure in Dashboard application that can potentially allow exposure of tokens from privilege users. An attacker can create dashboard and share it to privileged user (admin) and detokenize variables using external urls within dashboards drilldown function.
how_to_implement = This search uses REST function to query for dashboards with environment variables present in URL options.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"]}
known_false_positives = This search may reveal non malicious URLs with environment variables used in organizations.
providing_technologies = null

[savedsearch://ESCU - Splunk App for Lookup File Editing RCE via User XSLT - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This search provides information to investigate possible remote code execution exploitation via user-supplied Extensible Stylesheet Language Transformations (XSLT), affecting Splunk versions 9.1.x.
how_to_implement = Because there is no way to detect the payload, this search only provides the ability to monitor the creation of lookups which are the base of this exploit. An operator must then investigate suspicious lookups. This search requires ability to perform REST queries. Note that if the Splunk App for Lookup File Editing is not, or was not, installed in the Splunk environment then it is not necessary to run the search as the enviornment was not vulnerable.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]}
known_false_positives = This search will provide information for investigation and hunting of lookup creation via user-supplied XSLT which may be indications of possible exploitation. There will be false positives as it is not possible to detect the payload executed via this exploit.
providing_technologies = null

[savedsearch://ESCU - Splunk Authentication Token Exposure in Debug Log - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This detection search finds exposed authentication tokens in debug logs. This issue occurs in Splunk Enterprise versions below 9.2.1, 9.1.4, and 9.0.9, which may be affected by a vulnerability where JsonWebTokens can be exposed if the log level is set to DEBUG.
how_to_implement = Requires access to internal Splunk indexes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1654"], "nist": ["DE.CM"]}
known_false_positives = Only applies to affected versions of Splunk Enterprise below 9.2.1, 9.1.4, and 9.0.9
providing_technologies = null

[savedsearch://ESCU - Splunk Code Injection via custom dashboard leading to RCE - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This hunting search provides information about a vulnerability in Splunk Enterprise versions below 8.2.9, 8.1.12, 9.0.2, where an authenticated user can execute arbitrary code via the dashboard pdf generation component. Please review events with file=export in the _internal index for the potential targets of exploitation.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]}
known_false_positives = Not all exports and downloads are malicious, special attention must be put as well on /en-US/splunkd/__raw/services/pdfgen/render in the context of this search.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Command and Scripting Interpreter Delete Usage - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies the use of the risky command - Delete - that may be utilized in Splunk to delete some or all data queried for. In order to use Delete in Splunk, one must be assigned the role. This is typically not used and should generate an anomaly if it is used.
how_to_implement = To successfully implement this search acceleration is recommended against the Search_Activity datamodel that runs against the splunk _audit index. In addition, this analytic requires the Common Information Model App which includes the Splunk Audit Datamodel https://splunkbase.splunk.com/app/1621/.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if this command is used as a common practice. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Splunk Command and Scripting Interpreter Risky Commands - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The Splunk platform contains built-in search processing language (SPL) safeguards to warn you when you are about to unknowingly run a search that contains commands that might be a security risk. This warning appears when you click a link or type a URL that loads a search that contains risky commands. The warning does not appear when you create ad hoc searches. This warning alerts you to the possibility of unauthorized actions by a malicious user. Unauthorized actions include - Copying or transferring data (data exfiltration), Deleting data and Overwriting data. All risky commands may be found here https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga. A possible scenario when this might occur is when a malicious actor creates a search that includes commands that exfiltrate or damage data. The malicious actor then sends an unsuspecting user a link to the search. The URL contains a query string (q) and a search identifier (sid), but the sid is not valid. The malicious actor hopes the user will use the link and the search will run. During analysis, pivot based on user name and filter any user or queries not needed. Queries ran from a dashboard are seen as adhoc queries. When a query runs from a dashboard it will not show in audittrail logs the source dashboard name. The query defaults to adhoc and no Splunk system user activity. In addition, modify this query by removing key commands that generate too much noise, or too little, and create separate queries with higher confidence to alert on.
how_to_implement = To successfully implement this search acceleration is recommended against the Search_Activity datamodel that runs against the splunk _audit index.  In addition, this analytic requires the Common Information Model App which includes the Splunk Audit Datamodel https://splunkbase.splunk.com/app/1621/. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present until properly filtered by Username and search name.
providing_technologies = null

[savedsearch://ESCU - Splunk Command and Scripting Interpreter Risky SPL MLTK - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = This detection utilizes machine learning model named "risky_command_abuse" trained from "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline". It should be scheduled to run hourly to detect whether a user has run searches containing risky SPL from this list https://docs.splunk.com/Documentation/Splunk/latest/Security/SPLsafeguards#Commands_that_trigger_the_warninga with abnormally long running time in the past one hour, comparing with his/her past seven days history. This search uses the trained baseline to infer whether a search is an outlier (isOutlier ~= 1.0) or not (isOutlier~= 0.0)
how_to_implement = This detection depends on MLTK app which can be found here - https://splunkbase.splunk.com/app/2890/ and the Splunk Audit datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. Baseline model needs to be built using "Splunk Command and Scripting Interpreter Risky SPL MLTK Baseline" before this search can run. Please note that the current search only finds matches exactly one space between separator bar and risky commands.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = If the run time of a search exceeds the boundaries of outlier defined by the fitted density function model, false positives can occur, incorrectly labeling a long running search as potentially risky.
providing_technologies = null

[savedsearch://ESCU - Splunk csrf in the ssg kvstore client endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a cross-site request forgery in the Splunk Secure Gateway (SSG) app in the kvstore_client endpoint allows for updating SSG KV store collections via a GET request. SSG is a Splunk Built app included by default with Splunk Enterprise. The vulnerability affects instances with SSG and Splunk Web enabled. This hunting search provides information on affected server specific method and post data that may reveal exploitation of this vulnerability.
how_to_implement = Requires access to internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]}
known_false_positives = This hunting search only applies to the affected versions and setup mentioned in the description of this search, it does not extract payload so it requires manual investigation after executing search. This search will produce false positives.
providing_technologies = null

[savedsearch://ESCU - Splunk Data exfiltration from Analytics Workspace using sid query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This hunting search allows operator to discover attempts to exfiltrate data by executing a prepositioned malicious search ID in Analytic Workspace in Splunk Enterprise versions 8.2.9,8.1.12,9.0.2. The attack is browser-based. It requires the attacker to compel a victim to initiate a request within their browser (phishing). The attacker cannot exploit the vulnerability at will.
how_to_implement = The vulnerability affects only instances with Splunk Web Enabled.  After running this search, please run "Splunk Command and Scripting Interpreter Risky SPL MLTK" to gain more insight into potentially risky commands which could lead to data exfiltration.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567"], "nist": ["DE.AE"]}
known_false_positives = This search may produce false positives.  This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. Special attention must be paid to "/en-US/app/search/analytics_workspace?sid=[sid]" which is where the malicious code will be inserted to trigger attack at victim.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Digital Certificates Infrastructure Version - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search will check the TLS validation is properly configured on the search head it is run from as well as its search peers after Splunk version 9. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked.
how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (the `dispatch_rest_to_indexers` capability) in some architectures. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"]}
known_false_positives = No known at this time.
providing_technologies = null

[savedsearch://ESCU - Splunk Digital Certificates Lack of Encryption - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. In other circumstances, a client may be allowed to publish a forwarder bundle to other clients, which may allow for arbitrary code execution. The fixes for these require upgrading to at least Splunk 9.0 on the forwarder as well. This is a great opportunity to configure TLS across the environment. This search looks for forwarders that are not using TLS and adds risk to those entities.
how_to_implement = This anomaly search looks for forwarder connections that are not currently using TLS. It then presents the source IP, the type of forwarder, and the version of the forwarder. You can also remove the "ssl=false" argument from the initial stanza in order to get a full list of all your forwarders that are sending data, and the version of Splunk software they are running, for audit purposes. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1587.003"], "nist": ["DE.AE"]}
known_false_positives = None at this time
providing_technologies = null

[savedsearch://ESCU - Splunk DoS Using Malformed SAML Request - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions lower than 9.0.6, and 8.2.12, an attacker can send a malformed security assertion markup language SAML request to the /saml/acs REST endpoint which can cause a denial of service through a crash or hang of the Splunk daemon.The SAML extensible markup language (XML) parser does not fail SAML signature validation when the attacker modifies the URI in the SAML request. Instead it attempts to access the modified URI, which causes the Splunk daemon to crash or hang.
how_to_implement = To run this search, you must have access to the _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.AE"]}
known_false_positives = This search will show false positives. The analyst must look for errors and a pointer indicating a malicious file.
providing_technologies = null

[savedsearch://ESCU - Splunk DOS Via Dump SPL Command - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, an attacker can exploit a vulnerability in the dump SPL command to cause a Denial of Service by crashing the Splunk daemon.
how_to_implement = This search does not require additional ingestion of data. Requires the ability to search _internal index and monitor segmentation faults.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499.004"], "nist": ["DE.AE"]}
known_false_positives = Segmentation faults may occur due to other causes, so this search may produce false positives
providing_technologies = null

[savedsearch://ESCU - Splunk DoS via Malformed S2S Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On March 24th, 2022, Splunk published a security advisory for a possible Denial of Service stemming from the lack of validation in a specific key-value field in the Splunk-to-Splunk (S2S) protocol. This detection will alert on attempted exploitation in patched versions of Splunk.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection will only find attempted exploitation on versions of Splunk already patched for CVE-2021-3422.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498"], "nist": ["DE.CM"]}
known_false_positives = None.
providing_technologies = null

[savedsearch://ESCU - Splunk DOS via printf search function - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This hunting search provides information on detecting a vulnerability In Splunk Enterprise versions lower than 8.1.14, 8.2.12, 9.0.6, and 9.1.1, an attacker can use the printf SPL function to perform a denial of service against the Splunk Enterprise instance.
how_to_implement = This search requires the ability to search internal indexes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499.004"], "nist": ["DE.AE"]}
known_false_positives = This search may produces false positives, analyst most focuse in the use of printf conversion function of eval to craft an expression that splunkd cannot interpret correctly causing it to crash.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Edit User Privilege Escalation - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = A low-privilege user who holds a role that has the edit_user capability assigned to it can escalate their privileges to that of the admin user by providing specially crafted web requests.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to discover abuse of edit_user privilege.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"]}
known_false_positives = This search may produce false positives as password changing actions may be part of normal behavior. Operator will need to investigate these actions in order to discern exploitation attempts.
providing_technologies = null

[savedsearch://ESCU - Splunk Endpoint Denial of Service DoS Zip Bomb - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search allows operator to identify Splunk search app crashes resulting from specially crafted ZIP file using file monitoring that affects UF versions 8.1.11 and 8.2 versions below 8.2.7.1. It is not possible to detect Zip Bomb attack before crash. This search will provide Universal Forwarder errors from uploaded binary files (zip compression) which are used for this attack. If an analyst sees results from this search we suggest you investigate and triage what zip file was uploaded, zip compressed files may have different extensions.
how_to_implement = Need to monitor Splunkd data from Universal Forwarders.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]}
known_false_positives = This search may reveal non malicious zip files causing errors as well.
providing_technologies = null

[savedsearch://ESCU - Splunk Enterprise KV Store Incorrect Authorization - Rule]
type = detection
asset_type = Splunk Server
confidence = medium
explanation = In Splunk Enterprise versions below 9.0.8 and 9.1.3, Splunk app key value store KV Store improperly handles permissions for users using the REST application programming interface (API). This can potentially result in the deletion of KV Store collections.
how_to_implement = Requires access to internal indexes and REST API enabled instances.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"]}
known_false_positives = This is a hunting search and will produce false positives. Operator must follow results into instances where curl requests coming from actual users may indicate intent of exploitation.
providing_technologies = null

[savedsearch://ESCU - Splunk Enterprise Windows Deserialization File Partition - Rule]
type = detection
asset_type = Splunk Server
confidence = medium
explanation = In Splunk Enterprise for Windows versions below 9.0.8 and 9.1.3, Splunk Enterprise does not correctly sanitize path input data resulting in the unsafe deserialization of untrusted data. This vulnerability only affects Splunk Enterprise for Windows.
how_to_implement = Requires access to internal indexes. This detection search will display irregular path file execution, which will display exploit attempts. Only applies to Microsoft Windows Splunk versions.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = Irregular path with files that may be purposely called for benign reasons may produce false positives.
providing_technologies = null

[savedsearch://ESCU - Splunk ES DoS Investigations Manager via Investigation Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted.
how_to_implement = This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]}
known_false_positives = The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk ES DoS Through Investigation Attachments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible.
how_to_implement = This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]}
known_false_positives = This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk HTTP Response Splitting Via Rest SPL Command - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = A low-privileged user, using a specially crafted search command, can trigger an HTTP response splitting vulnerability with the rest SPL command that lets them potentially access other REST endpoints in the system arbitrarily, including accessing restricted content such as password files. This is because the user is able to inject the rest SPL command into the q parameter of an HTTP GET web request. The vulnerability requires the attacker to phish the victim by tricking them into initiating a request within their browser. The attacker cannot exploit the vulnerability at will.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This search may assist in detecting possible http response splitting exploitation attemptss.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.006"], "nist": ["DE.AE"]}
known_false_positives = This search may have produce false positives as malformed or erroneous requests made to this endpoint may be executed willingly or erroneously by operators.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Improperly Formatted Parameter Crashes splunkd - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, when the INGEST\\_EVAL parameter is improperly formatted, it crashes splunkd. This hunting search provides the user, timing and number of times the crashing command was executed.
how_to_implement = Requires access to audittrail and use of Splunk_Audit.Search_Activity datamodel.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1499"], "nist": ["DE.CM"]}
known_false_positives = This is a hunting search it should be focused on affected products, otherwise it is likely to produce false positives.
providing_technologies = null

[savedsearch://ESCU - Splunk Information Disclosure in Splunk Add-on Builder - Rule]
type = detection
asset_type = Splunk Server
confidence = medium
explanation = In Splunk Add-on Builder versions below 4.1.4, the application writes sensitive information to its internal log files when you visit the Splunk Add-on Builder or when you build or edit a custom app or add-on.
how_to_implement = This search should be run on search heads where Splunk Add-on Builder may be installed.  The results of this search will conclusively show whether or not a vulnerable version of Splunk Add-on Builder is currently installed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.AE"]}
known_false_positives = This search is highly specific for vulnerable versions of Splunk Add-on Builder. There are no known false positives.
providing_technologies = null

[savedsearch://ESCU - Splunk list all nonstandard admin accounts - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search will enumerate all Splunk Accounts with administrative rights on this instance.  It deliberately ignores the default admin account since this is assumed to be present.  This search may help in a detection the Cross-Site Scripting Attack listed: In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled.
how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (the `dispatch_rest_to_indexers` capability) in some architectures.  If there have been admin account, in addition to the standard admin account, intentionally created on this server, then edit the filter macro to exclude them.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = It is not possible to discern from the user table whether or not users with admin rights have been created intentionally, accidentally, or as a result of exploitation. Each user with these rights should be investigated and, if legitimate, added to the filter macro above.  If a user is not believed to be legitimate, then further investigation should take place.
providing_technologies = null

[savedsearch://ESCU - Splunk Low Privilege User Can View Hashed Splunk Password - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user who holds the user role can see the hashed version of the initial user name and password for the Splunk instance by using the rest SPL command against the conf-user-seed REST endpoint. This can lead to a privilege escalation that lets the user take over the admin account on the instance.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to discover attempts to access con-user-seed file content.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1212"], "nist": ["DE.AE"]}
known_false_positives = This search may produce false positives as accounts with high privileges may access this file. Operator will need to investigate these actions in order to discern exploitation attempts.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Path Traversal In Splunk App For Lookup File Edit - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 9.0.5, 8.2.11, and 8.1.14, a low-privilege user with access to the Splunk App for Lookup File Editing can, with a specially crafted web request, trigger a path traversal exploit that can then be used to read and write to restricted areas of the Splunk installation directory, including but not limited to the password hash file for the instance.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection is meant for on premise environments, and if executed on internet facing servers without a WAF may produce a lot of results. This detection will not work against obfuscated path traversal requests.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1083"], "nist": ["DE.AE"]}
known_false_positives = This search may find additional path traversal exploitation attempts or malformed requests.
providing_technologies = null

[savedsearch://ESCU - Persistent XSS in RapidDiag through User Interface Views - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise 9.0 versions before 9.0.4, a View allows for Cross-Site Scripting through the error message in a Base64-encoded image. The vulnerability affects instances with Splunk Web enabled. It does not affect Splunk Enterprise versions below 9.0. This search provides information on what user may have potentially added a malicious payload and what users were exposed to it.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]}
known_false_positives = This is a hunting search, it will not deobfuscate base64 payload, it provides however it will provide what user added the view artifact and what user opened it. It will require further investigation based on the information presented by this hunting search.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Persistent XSS Via URL Validation Bypass W Dashboard - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 9.0.4, 8.2.10, and 8.1.13, a low-privileged user can bypass URL validation to perform a path traversal and access restricted and confidential information by targeting other users on the instance, including the admin user.  The only affected version of bootstrap which shipped with Splunk was version 2.3.1, so the search is targeted at that version alone.
how_to_implement = This search does not require additional data to be ingested. This search requires ability to search _internal index. This search helps discover access to vulnerable bootstrap versions.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = This search will produce numerous false positives as it shows ANY accesses to vulnerable bootstrap Javascript files.  Accesses to these files occur during normal Splunk usage. To reduce or eliminate false positives, update the a version of Splunk which has addressed the vulnerability.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Process Injection Forwarder Bundle Downloads - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On June 14th, 2022, Splunk released a security advisory relating to the authentication that happens between Universal Forwarders and Deployment Servers. In some circumstances, an unauthenticated client can download forwarder bundles from the Deployment Server. This hunting search pulls a full list of forwarder bundle downloads where the peer column is the forwarder, the host column is the Deployment Server, and then you have a list of the apps downloaded and the serverclasses in which the peer is a member of. You should look for apps or clients that you do not recognize as being part of your environment.
how_to_implement = This hunting search uses native logs produced when a deployment server is within your environment. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]}
known_false_positives = None at this time.
providing_technologies = null

[savedsearch://ESCU - Splunk Protocol Impersonation Weak Encryption Configuration - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On June 14th, 2022, Splunk released a security advisory relating to TLS validation occuring within the httplib and urllib python libraries shipped with Splunk. In addition to upgrading to Splunk Enterprise 9.0 or later, several configuration settings need to be set. This search will check those configurations on the search head it is run from as well as its search peers. In addition to these settings, the PYTHONHTTPSVERIFY setting in $SPLUNK_HOME/etc/splunk-launch.conf needs to be enabled as well. Other components such as additional search heads or anything this rest command cannot be distributed to will need to be manually checked.
how_to_implement = The user running this search is required to have a permission allowing them to dispatch REST requests to indexers (The `dispatch_rest_to_indexers` capability). Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1001.003"], "nist": ["DE.AE"]}
known_false_positives = While all of the settings on each device returned by this search may appear to be hardened, you will still need to verify the value of PYTHONHTTPSVERIFY in $SPLUNK_HOME/etc/splunk-launch.conf on each device in order to harden the python configuration.
providing_technologies = null

[savedsearch://ESCU - Splunk protocol impersonation weak encryption selfsigned - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On June 14th 2022, Splunk released vulnerability advisory addresing Python TLS validation which was not set before Splunk version 9. This search displays events showing WARNING of using Splunk issued default selfsigned certificates.
how_to_implement = Must upgrade to Splunk version 9 and Configure TLS in order to apply this search. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1588.004"], "nist": ["DE.AE"]}
known_false_positives = This searches finds self signed certificates issued by Splunk which are not recommended from Splunk version 9 forward.
providing_technologies = null

[savedsearch://ESCU - Splunk protocol impersonation weak encryption simplerequest - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On Splunk version 9 on Python3 client libraries verify server certificates by default and use CA certificate store. This search warns a user about a failure to validate a certificate using python3 request.
how_to_implement = Must upgrade to Splunk version 9 and Configure TLS host name validation for Splunk Python modules in order to apply this search. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1588.004"], "nist": ["DE.AE"]}
known_false_positives = This search tries to address validation of server and client certificates within Splunk infrastructure, it might produce results from accidental or unintended requests to port 8089.
providing_technologies = null

[savedsearch://ESCU - Splunk RBAC Bypass On Indexing Preview REST Endpoint - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = An unauthorized user can use the /services/indexing/preview REST endpoint to overwrite search results if they know the search ID (SID) of an existing search job.
how_to_implement = This search does not require additional data ingestion. It requires the ability to search _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134"], "nist": ["DE.AE"]}
known_false_positives = This is a hunting search which provides verbose results against this endpoint. Operator must consider things such as IP address, useragent and user(specially low privelege) and host to investigate possible attack.
providing_technologies = null

[savedsearch://ESCU - Splunk RCE via Serialized Session Payload - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise versions lower than 8.2.12, 9.0.6, and 9.1.1, an attacker can execute a specially crafted query that they can then use to serialize untrusted data. The attacker can use the query to execute arbitrary code. The exploit requires the use of the 'collect' SPL command which writes a file within the Splunk Enterprise installation.  The attacker can then use this file to submit a serialized payload that can result in execution of code within the payload. Please refer to the following URL for additional information on these disclosures - https://advisory.splunk.com
how_to_implement = Requires access to the _audit index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]}
known_false_positives = There are numerous many uses of the 'makeresults' and 'collect' SPL commands. Please evaluate the results of this search for potential abuse.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk RCE via Splunk Secure Gateway  Splunk Mobile alerts feature - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This hunting search provides information on possible exploitation attempts against Splunk Secure Gateway App Mobile Alerts feature in Splunk versions 9.0, 8.2.x, 8.1.x. An authenticated user can run arbitrary operating system commands remotely through the use of specially crafted requests to the mobile alerts feature in the Splunk Secure Gateway app.
how_to_implement = This search only applies if Splunk Mobile Gateway is deployed in the vulnerable Splunk versions.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]}
known_false_positives = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. Focus of this search is "uri_path=/servicesNS/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*" which is the injection point.
providing_technologies = null

[savedsearch://ESCU - Splunk RCE via User XSLT - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This search provides information to investigate possible remote code execution exploitation via user-supplied Extensible Stylesheet Language Transformations (XSLT), affecting Splunk versions 9.1.x.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]}
known_false_positives = This search will provide information for investigation and hunting possible abuse of user-supplied XSLT. There may be false positives and results should individually evaluated. Please evaluate the source IP and useragent responsible for creating the requests.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Reflected XSS in the templates lists radio - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Splunk versions below 8.1.12,8.2.9 and 9.0.2 are vulnerable to reflected cross site scripting (XSS). A View allows for a Reflected Cross Site scripting via JavaScript Object Notation (JSON) in a query parameter when ouput_mode=radio.
how_to_implement = This vulnerability only affects instances with Splunk Web enabled. This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = This search may produce false positives as it is difficult to pinpoint all possible XSS injection characters in a single search string. Special attention is required to "en-US/list/entities/x/ui/views" which is the vulnerable injection point.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Reflected XSS on App Search Table Endpoint - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 9.1.1, 9.0.6, and 8.2.12, an attacker can craft a special web request that can result in reflected cross-site scripting XSS on the app search table web endpoint, which presents as the Create Table View page in Splunk Web. Exploitation of this vulnerability can lead to the execution of arbitrary commands on the Splunk platform instance. A JavaScript file within this web endpoint does not properly validate input which lets an attacker insert a payload into a function.
how_to_implement = Need access to the internal indexes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = This search will produce false positives. It is necessary to also look at uri_query parameter to determine the possible malicious intention of inserting makeresults within the uri string.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk risky Command Abuse disclosed february 2023 - Rule]
type = detection
asset_type = Splunk Server
confidence = medium
explanation = This search looks for a variety of high-risk commands throughout a number of different Splunk Vulnerability Disclosures.  Please refer to the following URL for additional information on these disclosures - https://advisory.splunk.com
how_to_implement = Requires implementation of Splunk_Audit.Search_Activity datamodel.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548", "T1202"], "nist": ["DE.AE"]}
known_false_positives = This search encompasses many commands.
providing_technologies = null

[savedsearch://ESCU - Splunk Stored XSS via Data Model objectName field - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Splunk Enterprise versions 8.1.12, 8.2.9, 9.0.2 are vulnerable to persistent cross site scripting via Data Model object name. An authenticated user can inject and store arbitrary scripts that can lead to persistent cross-site scripting (XSS) in the object name Data Model.
how_to_implement = This vulnerability only affects Splunk Web enabled instances. This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = This search may produce false positives and does not cover exploitation attempts via code obfuscation, focus of search is suspicious requests against "/en-US/splunkd/__raw/servicesNS/*/launcher/datamodel/model" which is the injection point.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk Unauthenticated Log Injection Web Service Log - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = An attacker can use a specially crafted web URL in their browser to cause log file injection, in which the attack inserts American National Standards Institute (ANSI) escape codes into specific files using a terminal program that supports those escape codes. The attack requires a terminal program that supports the translation of ANSI escape codes and requires additional user interaction to successfully execute. This following analytic detects potential log injection attempts into the Splunk server.
how_to_implement = This only affects web enabled Splunk instances. The detection does require the ability to search the _internal index.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]}
known_false_positives = This hunting search will produce false positives if ANSI escape characters are included in URLs either voluntarily or by accident. This search will not detect obfuscated ANSI characters.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk unnecessary file extensions allowed by lookup table uploads - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, the lookup table uploads let a user upload lookup tables with unnecessary filename extensions. Lookup table file extensions may now only be one of .csv, .csv.gz, .kmz, .kml, .mmdb, or .mmdb.gz. This search provides user activity focus on uploads which aims to help hunt for malicious file uploads.
how_to_implement = Requires access to internal splunkd_access.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]}
known_false_positives = This is a hunting search, the search provides information on upload, edit, and delete activity on Lookup Tables. Manual investigation is necessary after executing search. This search will produce false positives as payload cannot be directly discerned.
providing_technologies = null

[savedsearch://ESCU - Splunk User Enumeration Attempt - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = On May 3rd, 2022, Splunk published a security advisory for  username enumeration stemming from verbose login failure messages present on some REST endpoints. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _audit index. This detection may assist in efforts to find password spraying or brute force authorization attempts in addition to someone enumerating usernames.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]}
known_false_positives = Automation executing authentication attempts against your Splunk infrastructure with outdated credentials may cause false positives.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk XSS in Highlighted JSON Events - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This detection provides information about possible exploitation against affected versions of Splunk Enterprise 9.1.2. The ability to view JSON logs in the web GUI may be abused by crafting a specific request, causing the execution of javascript in script tags. This vulnerability can be used to execute javascript to access the API at the permission level of the logged-in user. If user is admin it can be used to create an admin user, giving an attacker broad access to the Splunk Environment.
how_to_implement = This search only applies to web-GUI-enabled Splunk instances and operator must have access to internal indexes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = This is a hunting search and will produce false positives as it is not possible to view contents of a request payload. It shows the artifact resulting from a potential exploitation payload (the creation of a user with admin privileges).
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk XSS in Monitoring Console - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = On May 3rd, 2022, Splunk published a security advisory for a reflective Cross-Site Scripting (XSS) vulnerability stemming from the lack of input validation in the Distributed Monitoring Console app. This detection will alert on attempted exploitation in patched versions of Splunk as well as actual exploitation in unpatched version of Splunk.
how_to_implement = This detection does not require you to ingest any new data. The detection does require the ability to search the _internal index. This detection will find attempted exploitation of CVE-2022-27183.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]}
known_false_positives = Use of the monitoring console where the less-than sign (<) is the first character in the description field.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk XSS in Save table dialog header in search page - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This is a hunting search to find persistent cross-site scripting XSS code that was included while inputing data in 'Save Table' dialog in Splunk Enterprise (8.1.12,8.2.9,9.0.2). A remote user with "power" Splunk role can store this code that can lead to persistent cross site scripting.
how_to_implement = Watch for POST requests combined with XSS script strings or obfuscation against the injection point /en-US/splunkd/__raw/servicesNS/nobody/search/datamodel/model.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = If host is vulnerable and XSS script strings are inputted they will show up in search. Not all Post requests are malicious as they will show when users create and save dashboards. This search may produce several results with non malicious POST requests. Only affects Splunk Web enabled instances.
providing_technologies = ["Splunk Internal Logs"]

[savedsearch://ESCU - Splunk XSS via View - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In Splunk Enterprise versions below 8.1.13, 8.2.10, and 9.0.4, a View allows for Cross-Site Scripting in an XML View through the 'layoutPanel' attribute in the 'module' tag. The vulnerability affects instances with Splunk Web enabled. This hunting search shows users action, application and role used for creating views related to this vulnerability.
how_to_implement = This data is collected by default in Splunk.  Upon first enabling this rule, a number of errors may be observed. Those that are due to improperly formatted, but non-nefarious, XML views should be be remedied in the corresponding view. Please take care investigating potential XSS as accessing an affected page could retrigger the exploit.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.AE"]}
known_false_positives = The error detected above can be generated for a wide variety of improperly formatted XML views.  There will be false positives as the search cannot extract the malicious payload and the view should be manually investigated.
providing_technologies = null

[savedsearch://ESCU - Suspicious Email Attachment Extensions - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects emails that contain attachments with suspicious file extensions. Detecting and responding to emails with suspicious attachments can mitigate the risks associated with phishing and malware attacks, thereby protecting the organization's data and systems from potential harm. The detection is made by using a Splunk query that searches for emails in the datamodel=Email where the filename of the attachment is not empty. The analytic uses the tstats command to summarize the count, first time, and last time of the emails that meet the criteria. It groups the results by the source user, file name, and message ID of the email. The detection is important because it indicates potential phishing or malware delivery attempts in which an attacker attempts to deliver malicious content through email attachments, which can lead to data breaches, malware infections, or unauthorized access to sensitive information. Next steps include reviewing the identified emails and attachments and analyzing the source user, file name, and message ID to determine if they are legitimate or malicious. Additionally, you must inspect any relevant on-disk artifacts associated with the attachments and investigate any concurrent processes to identify the source of the attack.
how_to_implement = You need to ingest data from emails. Specifically, the sender's address and the file names of any attachments must be mapped to the Email data model. \
 **Splunk Phantom Playbook Integration**\
If Splunk Phantom is also configured in your environment, a Playbook called "Suspicious Email Attachment Investigate and Delete" can be configured to run when any results are found by this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, and add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search. The notable event will be sent to Phantom and the playbook will gather further information about the file attachment and its network behaviors. If Phantom finds malicious behavior and an analyst approves of the results, the email will be deleted from the user's inbox.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - Suspicious Java Classes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for suspicious Java classes that are often used to exploit remote command execution in common Java frameworks, such as Apache Struts.
how_to_implement = In order to properly run this search, Splunk needs to ingest data from your web-traffic appliances that serve or sit in the path of your Struts application servers. This can be accomplished by indexing data from a web proxy, or by using network traffic-analysis tools, such as Splunk Stream or Bro.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = There are no known false positives.
providing_technologies = null

[savedsearch://ESCU - Web Servers Executing Suspicious Processes - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic detects suspicious processes on systems labeled as web servers. This detection is made by a Splunk query that searches for specific process names that might indicate malicious activity. These suspicious processes include "whoami", "ping", "iptables", "wget", "service", and "curl". Uses the Splunk data model "Endpoint.Processes" and filters the results to only include systems categorized as web servers. This detection is important because it indicates unauthorized or malicious activity on web servers since these processes are commonly used by attackers to perform reconnaissance, establish persistence, or exfiltrate data from compromised systems. The impact of such an attack can be significant, ranging from data theft to the deployment of additional malicious payloads, potentially leading to ransomware or other damaging outcomes. False positives might occur since the legitimate use of these processes on web servers can trigger the analytic. Next steps include triaging and investigating to determine the legitimacy of the activity. Also, review the source and command of the suspicious process. You must also examine any relevant on-disk artifacts and look for concurrent processes to identify the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.CM"]}
known_false_positives = Some of these processes may be used legitimately on web servers during maintenance or other administrative tasks.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Abnormally High Number Of Cloud Infrastructure API Calls - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search will detect a spike in the number of API calls made to your cloud infrastructure environment by a user.
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Infrastructure API Calls Per User` to create the probability density function.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]}
known_false_positives = 
providing_technologies = null

[savedsearch://ESCU - Abnormally High Number Of Cloud Instances Destroyed - Rule]
type = detection
asset_type = Cloud Instance
confidence = medium
explanation = This search finds for the number successfully destroyed cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers.
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Destroyed` to create the probability density function.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured within a cloud infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
providing_technologies = null

[savedsearch://ESCU - Abnormally High Number Of Cloud Instances Launched - Rule]
type = detection
asset_type = Cloud Instance
confidence = medium
explanation = This search finds for the number successfully created cloud instances for every 4 hour block. This is split up between weekdays and the weekend. It then applies the probability densitiy model previously created and alerts on any outliers.
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Instances Launched` to create the probability density function.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
providing_technologies = null

[savedsearch://ESCU - Abnormally High Number Of Cloud Security Group API Calls - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search will detect a spike in the number of API calls made to your cloud infrastructure environment about security groups by a user.
how_to_implement = You must be ingesting your cloud infrastructure logs. You also must run the baseline search `Baseline Of Cloud Security Group API Calls Per User` to create the probability density function model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]}
known_false_positives = 
providing_technologies = null

[savedsearch://ESCU - Amazon EKS Kubernetes cluster scan detection - Rule]
type = detection
asset_type = Amazon EKS Kubernetes cluster
confidence = medium
explanation = This search provides information of unauthenticated requests via user agent, and authentication data against Kubernetes cluster in AWS
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudWatch EKS Logs inputs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]}
known_false_positives = Not all unauthenticated requests are malicious, but frequency, UA and source IPs will provide context.
providing_technologies = null

[savedsearch://ESCU - Amazon EKS Kubernetes Pod scan detection - Rule]
type = detection
asset_type = Amazon EKS Kubernetes cluster Pod
confidence = medium
explanation = The following analytic detects unauthenticated requests made against the Kubernetes' Pods API through proactive monitoring to protect the Kubernetes environment from unauthorized access and potential security breaches. The detection is made by using the Splunk query `aws_cloudwatchlogs_eks` with specific filters to identify these requests. Identifies events where the `user.username` is set to "system:anonymous", the `verb` is set to "list", and the `objectRef.resource` is set to "pods". Additionally, the search checks if the `requestURI` is equal to "/api/v1/pods". Analyzing these events helps you to identify any unauthorized access attempts to the Kubernetes' Pods API. Unauthenticated requests can indicate potential security breaches or unauthorized access to sensitive resources within the Kubernetes environment. The detection is important because unauthorized access to Kubernetes' Pods API can lead to the compromise of sensitive data, unauthorized execution of commands, or even the potential for lateral movement within the Kubernetes cluster. False positives might occur since there might be legitimate use cases for unauthenticated requests in certain scenarios. Therefore, you must review and validate any detected events before taking any action.  Next steps include investigating the incident to mitigate any ongoing threats, and strengthening the security measures to prevent future unauthorized access attempts.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on forAWS (version 4.4.0 or later), then configure your AWS CloudWatch EKS Logs.Please also customize the `kubernetes_pods_aws_scan_fingerprint_detection` macro to filter out the false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]}
known_false_positives = Not all unauthenticated requests are malicious, but frequency, UA and source IPs and direct request to API provide context.
providing_technologies = null

[savedsearch://ESCU - ASL AWS Concurrent Sessions From Different Ips - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.AE"]}
known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS CreateAccessKey - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This detection rule monitors for the creation of AWS Identity and Access Management (IAM) access keys. An IAM access key consists of an access key ID and secret access key, which are used to sign programmatic requests to AWS services. While IAM access keys can be legitimately used by developers and administrators for API access, their creation can also be indicative of malicious activity. Attackers who have gained unauthorized access to an AWS environment might create access keys as a means to establish persistence or to exfiltrate data through the APIs. Moreover, because access keys can be used to authenticate with AWS services without the need for further interaction, they can be particularly appealing for bad actors looking to operate under the radar. Consequently, it's important to vigilantly monitor and scrutinize access key creation events, especially if they are associated with unusual activity or are created by users who don't typically perform these actions. This hunting query identifies when a potentially compromised user creates a IAM access key for another user who may have higher privilleges, which can be a sign for privilege escalation. Hunting queries are designed to be executed manual during threat hunting.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS Defense Evasion Delete Cloudtrail - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their malicious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may delete the the entire cloudtrail that is logging activities in the environment.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS Defense Evasion Delete CloudWatch Log Group - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. Attackers may evade the logging capability by deleting the log group in CloudWatch. This will stop sending the logs and metrics to CloudWatch. When the adversary has the right type of permissions within the compromised AWS environment, they may delete the CloudWatch log group that is logging activities in the environment.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS Defense Evasion Impair Security Services - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic looks for several delete specific API calls made to AWS Security Services like CloudWatch, GuardDuty and Web Application Firewalls. These API calls are often leveraged by adversaries to weaken existing security defenses by deleting logging configurations in the CloudWatch alarm, delete a set of detectors from your Guardduty environment or simply delete a bunch of CloudWatch alarms to remain stealthy and avoid detection.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS Excessive Security Scanning - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events and analyse the amount of eventNames which starts with Describe by a single user. This indicates that this user scans the configuration of your AWS cloud environment.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS IAM Delete Policy - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following detection identifes when a policy is deleted on AWS. This does not identify whether successful or failed, but the error messages tell a story of suspicious attempts. There is a specific process to follow when deleting a policy. First, detach the policy from all users, groups, and roles that the policy is attached to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]}
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS Multi-Factor Authentication Disabled - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an attempt to disable multi-factor authentication for an AWS IAM user. An adversary who has obtained access to an AWS tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS New MFA Method Registered For User - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies the registration of a new Multi Factor authentication method for an AWS account logged through Amazon Secruity Lake (ASL). Adversaries who have obtained unauthorized access to an AWS account may register a new MFA method to maintain persistence.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - ASL AWS Password Policy Changes - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events from Amazon Security Lake where a user is making successful API calls to view/update/delete the existing password policy in an AWS organization. It is unlikely for a regular user to conduct this operation. These events may potentially be malicious, adversaries often use this information to gain more understanding of the password defenses in place and exploit them to increase their attack surface when a user account is compromised.
how_to_implement = You must install Splunk Add-On for AWS Version v7.0.0 (https://splunkbase.splunk.com/app/1876) that includes includes a merge of all the capabilities of the Splunk Add-on for Amazon Security Lake. This search works with Amazon Security Lake logs which are parsed in the Open Cybersecurity Schema Framework (OCSF)format.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately triggered an AWS audit tool activity which may trigger this event.
providing_technologies = ["Amazon Security Lake"]

[savedsearch://ESCU - AWS AMI Attribute Modification for Exfiltration - Rule]
type = detection
asset_type = EC2 Snapshot
confidence = medium
explanation = This search looks for suspicious AWS AMI attribute modifications, such as sharing it with another AWS account or making the full AMI image public. Adversaries are known to abuse these APIs to exfiltrate sensitive organization information stored in the AWS Resources, there by its very important to monitor these seemingly benign API activity in Cloudtrail logs.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with others for  a specific purpose.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Concurrent Sessions From Different Ips - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an AWS IAM account with concurrent sessions coming from more than one unique IP address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. When a user navigates the AWS Console after authentication, the API call with the event name `DescribeEventAggregates` is registered in the AWS CloudTrail logs. The Splunk Threat Research team leveraged this event name to identify 2 concurrent sessions. The presence of this event occurring from two different IP addresses is highly unlikely. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments.
how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]}
known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Console Login Failed During MFA Challenge - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an authentication attempt event against an AWS Console that fails during the Multi Factor Authentication challenge. AWS Cloudtrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled.
how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.CM"]}
known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Create Policy Version to allow all resources - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user created a policy version that allows them to access any resource in their account.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources and you must verify this activity.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS CreateAccessKey - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This detection rule monitors for the creation of AWS Identity and Access Management (IAM) access keys. An IAM access key consists of an access key ID and secret access key, which are used to sign programmatic requests to AWS services. While IAM access keys can be legitimately used by developers and administrators for API access, their creation can also be indicative of malicious activity. Attackers who have gained unauthorized access to an AWS environment might create access keys as a means to establish persistence or to exfiltrate data through the APIs. Moreover, because access keys can be used to authenticate with AWS services without the need for further interaction, they can be particularly appealing for bad actors looking to operate under the radar. Consequently, it's important to vigilantly monitor and scrutinize access key creation events, especially if they are associated with unusual activity or are created by users who don't typically perform these actions. This hunting query identifies when a potentially compromised user creates a IAM access key for another user who may have higher privilleges, which can be a sign for privilege escalation. Hunting queries are designed to be executed manual during threat hunting.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS CreateLoginProfile - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user A(victim A) creates a login profile for user B, followed by a AWS Console login event from user B from the same src_ip as user B. This correlated event can be indicative of privilege escalation since both events happened from the same src_ip
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a login profile for another user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Credential Access Failed Login - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = It shows that there have been an unsuccessful attempt to log in using the user identity to the AWS management console. Since the user identity has access to AWS account services and resources, an attacker might try to brute force the password for that identity.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.001"], "nist": ["DE.CM"]}
known_false_positives = Users may genuinely mistype or forget the password.
providing_technologies = null

[savedsearch://ESCU - AWS Credential Access GetPasswordData - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This detection analytic identifies more than 10 GetPasswordData API calls made to your AWS account with a time window of 5 minutes. Attackers can retrieve the encrypted administrator password for a running Windows instance.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. We encourage the users to adjust the values of `distinct_instance_ids` and tweak the `span` value according to their environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.001"], "nist": ["DE.AE"]}
known_false_positives = Administrator tooling or automated scripts may make these calls but it is highly unlikely to make several calls in a short period of time.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Credential Access RDS Password reset - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The master user password for Amazon RDS DB instance can be reset using the Amazon RDS console. Using this technique, the attacker can get access to the sensitive data from the DB. Usually, the production databases may have sensitive data like Credit card information, PII, Health care Data. This event should be investigated further.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = Users may genuinely reset the RDS password.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Cross Account Activity From Previously Unseen Account - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AssumeRole events where an IAM role in a different account is requested for the first time.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen AWS Cross Account Activity - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen AWS Cross Account Activity - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `aws_cross_account_activity_from_previously_unseen_account_filter` macro.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = Using multiple AWS accounts and roles is perfectly valid behavior. It's suspicious when an account requests privileges of an account it hasn't before. You should validate with the account owner that this is a legitimate request.
providing_technologies = null

[savedsearch://ESCU - AWS Defense Evasion Delete Cloudtrail - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies AWS `DeleteTrail` events within CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their malicious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may delete the the entire cloudtrail that is logging activities in the environment.
how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudTrail logging. Please investigate this activity.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Defense Evasion Delete CloudWatch Log Group - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies AWS `DeleteLogGroup` events in CloudTrail logs. Attackers may evade the logging capability by deleting the log group in CloudWatch. This will stop sending the logs and metrics to CloudWatch. When the adversary has the right type of permissions within the compromised AWS environment, they may delete the CloudWatch log group that is logging activities in the environment.
how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has deleted CloudWatch logging. Please investigate this activity.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Defense Evasion Impair Security Services - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic looks for several delete specific API calls made to AWS Security Services like CloudWatch, GuardDuty and Web Application Firewalls. These API calls are often leveraged by adversaries to weaken existing security defenses by deleting logging configurations in the CloudWatch alarm, delete a set of detectors from your Guardduty environment or simply delete a bunch of CloudWatch alarms to remain stealthy and avoid detection.
how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Defense Evasion PutBucketLifecycle - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies `PutBucketLifecycle` events in CloudTrail logs where a user has created a new lifecycle rule for an S3 bucket with a short expiration period. Attackers may use this API call to impair the CloudTrail logging by removing logs from the S3 bucket by changing the object expiration day to 1 day, in which case the CloudTrail logs will be deleted.
how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment. We recommend our users to set the expiration days value according to your company's log retention policies.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that it is a legitimate admin activity. Please consider filtering out these noisy events using userAgent, user_arn field names.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Defense Evasion Stop Logging Cloudtrail - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies `StopLogging` events in CloudTrail logs. Adversaries often try to impair their target's defenses by stopping their macliious activity from being logged, so that they may operate with stealth and avoid detection. When the adversary has the right type of permissions in the compromised AWS environment, they may easily stop logging.
how_to_implement = You must install Splunk AWS Add on and enable Cloudtrail logs in your AWS Environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.008", "T1562"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has stopped cloudtrail logging. Please investigate this activity.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Defense Evasion Update Cloudtrail - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic identifies `UpdateTrail` events in CloudTrail logs. Attackers may evade the logging capability by updating the settings and impairing them with wrong parameters. For example, Attackers may change the multi-regional log into a single region logs, which evades the logging for other regions. When the adversary has the right type of permissions in the compromised AWS environment, they may update the CloudTrail settings that is logging activities in your environment.
how_to_implement = You must install Splunk AWS Add on and enable CloudTrail logs in your AWS Environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has updated cloudtrail logging. Please investigate this activity.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - aws detect attach to role policy - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search provides detection of an user attaching itself to a different role trust policy. This can be used for lateral movement and escalation of privileges.
how_to_implement = You must install splunk AWS add-on and Splunk App for AWS. This search works with cloudwatch logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Attach to policy can create a lot of noise. This search can be adjusted to provide specific values to identify cases of abuse (i.e status=failure). The search can provide context for common users attaching themselves to higher privilege policies or even newly created policies.
providing_technologies = null

[savedsearch://ESCU - aws detect permanent key creation - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search provides detection of accounts creating permanent keys. Permanent keys are not created by default and they are only needed for programmatic calls. Creation of Permanent key is an important event to monitor.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Not all permanent key creations are malicious. If there is a policy of rotating keys this search can be adjusted to provide better context.
providing_technologies = null

[savedsearch://ESCU - aws detect role creation - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search provides detection of role creation by IAM users. Role creation is an event by itself if user is creating a new role with trust policies different than the available in AWS and it can be used for lateral movement and escalation of privileges.
how_to_implement = You must install splunk AWS add-on and Splunk App for AWS. This search works with cloudwatch logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = CreateRole is not very common in common users. This search can be adjusted to provide specific values to identify cases of abuse. In general AWS provides plenty of trust policies that fit most use cases.
providing_technologies = null

[savedsearch://ESCU - aws detect sts assume role abuse - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search provides detection of suspicious use of sts:AssumeRole. These tokens can be created on the go and used by attackers to move laterally and escalate privileges.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Sts:AssumeRole can be very noisy as it is a standard mechanism to provide cross account and cross resources access. This search can be adjusted to provide specific values to identify cases of abuse.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - aws detect sts get session token abuse - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search provides detection of suspicious use of sts:GetSessionToken. These tokens can be created on the go and used by attackers to move laterally and escalate privileges.
how_to_implement = You must install splunk AWS add-on and Splunk App for AWS. This search works with cloudwatch logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550"], "nist": ["DE.AE"]}
known_false_positives = Sts:GetSessionToken can be very noisy as in certain environments numerous calls of this type can be executed. This search can be adjusted to provide specific values to identify cases of abuse. In specific environments the use of field requestParameters.serialNumber will need to be used.
providing_technologies = null

[savedsearch://ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search provides detection of KMS keys where action kms:Encrypt is accessible for everyone (also outside of your organization). This is an indicator that your account is compromised and the attacker uses the encryption key to compromise another company.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Detect Users with KMS keys performing encryption S3 - Rule]
type = detection
asset_type = S3 Bucket
confidence = medium
explanation = This search provides detection of users with KMS keys performing encryption specifically against S3 buckets.
how_to_implement = You must install Splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]}
known_false_positives = There maybe buckets provisioned with S3 encryption
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Disable Bucket Versioning - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic detects AWS cloudtrail events where bucket versioning is suspended by a user. Versioning allows the AWS Administrators to maintain different version of the S3 bucket which can be used to recover deleted data. Adversaries have leveraged this technique in the wild during a ransomware incident to disable versioning so the client cannot recover the data.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.AE"]}
known_false_positives = It is possible that an AWS Administrator has legitimately disabled versioning on certain buckets to avoid costs.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS EC2 Snapshot Shared Externally - Rule]
type = detection
asset_type = EC2 Snapshot
confidence = medium
explanation = The following analytic utilizes AWS CloudTrail events to identify when an EC2 snapshot permissions are modified to be shared with a different AWS account. This method is used by adversaries to exfiltrate the EC2 snapshot.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with others for  a specific purpose.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS ECR Container Scanning Findings High - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). You need to activate image scanning in order to get the event DescribeImageScanFindings with the results.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS ECR Container Scanning Findings Low Informational Unknown - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). You need to activate image scanning in order to get the event DescribeImageScanFindings with the results.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS ECR Container Scanning Findings Medium - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). You need to activate image scanning in order to get the event DescribeImageScanFindings with the results.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS ECR Container Upload Outside Business Hours - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done during business hours. When done outside business hours, we want to take a look into it.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = When your development is spreaded in different time zones, applying this rule can be difficult.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS ECR Container Upload Unknown User - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events from AWS Elastic Container Service (ECR). A upload of a new container is normally done from only a few known users. When the user was never seen before, we should have a closer look into the event.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Excessive Security Scanning - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events and analyse the amount of eventNames which starts with Describe by a single user. This indicates that this user scans the configuration of your AWS cloud environment.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Exfiltration via Anomalous GetObject API Activity - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search uses built in  Splunk command `| anomalydetection` to detect anomalies with respect to users making high number of GetObject API calls to download objects from S3 in a 10 minute time window. The field `probable_cause` is the name of the field that best explains why the event is anomalous. This command identifies anomalous events by computing a probability for each GetObject event by "count" "user_type" "user_arn" and detects anomaly based on the frequencies.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.AE"]}
known_false_positives = It is possible that a user downloaded these files to use them locally and there are AWS services in configured that perform these activities for a legitimate reason. Filter is needed.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Exfiltration via Batch Service - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for events where AWS Batch Service is used for creating a job that could potentially abuse the AWS Bucket Replication feature on S3 buckets. This AWS service can used to transfer data between different AWS S3 buckets and an attacker can leverage this to exfiltrate data by creating a malicious batch job.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an AWS Administrator or a user has legitimately created this job for some tasks.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Exfiltration via Bucket Replication - Rule]
type = detection
asset_type = EC2 Snapshot
confidence = medium
explanation = The following analytic detects API calls made to an S3 bucket when bucket replication services are enabled. S3 bucket replication is a feature offered by Amazon Web Services (AWS) that allows you to automatically and asynchronously copy data from one S3 bucket to another in the same or different region.\
S3 bucket replication can also be used for cross-account replication, where data is replicated from a source bucket owned by one AWS account to a destination bucket owned by a different AWS account.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an AWS admin has legitimately implemented data replication to ensure data availability and improve data protection/backup strategies.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Exfiltration via DataSync Task - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for potential misuse of an AWS service known as DataSync. This AWS service is used to transfer data between different AWS cloud storage services, such as Amazon S3, Amazon EFS, and Amazon FSx for Windows File Server. Attackers can create a task in AWS to periodically copy data from a private AWS location to a public location resulting in the compromise of the data.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1119"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an AWS Administrator has legitimately created this task for creating backup. Please check the `sourceLocationArn` and `destinationLocationArn` of this task
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Exfiltration via EC2 Snapshot - Rule]
type = detection
asset_type = EC2 Snapshot
confidence = medium
explanation = This search detects a series of AWS API calls, made in a short time window, related to EC2 snapshots that can detect a potential exfiltration via EC2 Snapshot modifications. In this attack, the attacker typically proceeds by listing and creating EC2 snapshots of the available EC2 instances followed by modifying snapshot attributes such that it can be shared externally. Once this is done, the attacker can then load that EC2 snapshot and access all the sensitive information.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs. We have intentionally removed `guardduty.amazonaws.com` from src_ip to remove false positives caused by guard duty. We recommend you adjust the time window as per your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an AWS admin has legitimately shared a snapshot with an other account for a specific purpose. Please check any recent change requests filed in your organization.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS High Number Of Failed Authentications For User - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an AWS account with more than 20 failed authentication events in the span of 5 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection.
how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]}
known_false_positives = A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS High Number Of Failed Authentications From Ip - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an IP address failing to authenticate 20 or more times to the AWS Web Console in the span of 5 minutes. This behavior could represent a brute force attack against an AWS tenant to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection.
how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = An Ip address with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS IAM AccessDenied Discovery Events - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following detection identifies excessive AccessDenied events within an hour timeframe. It is possible that an access key to AWS may have been stolen and is being misused to perform discovery events. In these instances, the access is not available with the key stolen therefore these events will be generated.
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580"], "nist": ["DE.AE"]}
known_false_positives = It is possible to start this detection will need to be tuned by source IP or user. In addition, change the count values to an upper threshold to restrict false positives.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS IAM Assume Role Policy Brute Force - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following detection identifies any malformed policy document exceptions with a status of `failure`. A malformed policy document exception occurs in instances where roles are attempted to be assumed, or brute forced. In a brute force attempt, using a tool like CloudSploit or Pacu, an attempt will look like `arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS`.  Meaning, when an adversary is attempting to identify a role name, multiple failures will occur. This detection focuses on the errors of a remote attempt that is failing.
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs. Set the `where count` greater than a value to identify suspicious activity in your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1580", "T1110"], "nist": ["DE.CM"]}
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS IAM Delete Policy - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following detection identifies when a policy is deleted on AWS. This does not identify whether successful or failed, but the error messages tell a story of suspicious attempts. There is a specific process to follow when deleting a policy. First, detach the policy from all users, groups, and roles that the policy is attached to, using DetachUserPolicy , DetachGroupPolicy , or DetachRolePolicy.
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]}
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete policies (least privilege). In addition, this may be saved seperately and tuned for failed or success attempts only.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS IAM Failure Group Deletion - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This detection identifies failure attempts to delete groups. We want to identify when a group is attempting to be deleted, but either access is denied, there is a conflict or there is no group. This is indicative of administrators performing an action, but also could be suspicious behavior occurring. Review parallel IAM events - recently added users, new groups and so forth.
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.AE"]}
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege).
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS IAM Successful Group Deletion - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following query uses IAM events to track the success of a group being deleted on AWS. This is typically not indicative of malicious behavior, but a precurser to additional events thay may unfold. Review parallel IAM events - recently added users, new groups and so forth. Inversely, review failed attempts in a similar manner.
how_to_implement = The Splunk AWS Add-on and Splunk App for AWS is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1069.003", "T1098", "T1069"], "nist": ["DE.AE"]}
known_false_positives = This detection will require tuning to provide high fidelity detection capabilties. Tune based on src addresses (corporate offices, VPN terminations) or by groups of users. Not every user with AWS access should have permission to delete groups (least privilege).
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Lambda UpdateFunctionCode - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This analytic is designed to detect IAM users attempting to update/modify AWS lambda code via the AWS CLI to gain persistence, futher access into your AWS environment and to facilitate planting backdoors. In this instance, an attacker may upload malicious code/binary to a lambda function which will be executed automatically when the funnction is triggered.
how_to_implement = You must install Splunk AWS Add on and enable Cloudtrail logs in your AWS Environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin or an autorized IAM user has updated the lambda fuction code legitimately.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Multi-Factor Authentication Disabled - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an attempt to disable multi-factor authentication for an AWS IAM user. An adversary who has obtained access to an AWS tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users.
how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = AWS Administrators may disable MFA but it is highly unlikely for this event to occur without prior notice to the company
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Multiple Failed MFA Requests For User - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies multiple failed multi-factor authentication requests to an AWS Console for a single user. AWS Cloudtrail logs provide a a very useful field called `additionalEventData` that logs information regarding usage of MFA. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. AWS Environments can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1621"], "nist": ["DE.AE"]}
known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Multiple Users Failing To Authenticate From Ip - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies one source Ip failing to authenticate into the AWS Console with 30 unique valid users within 10 minutes. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment tenant to obtain initial access or elevate privileges.
how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the tried account threshold to tune this search according to their environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = No known false postives for this detection. Please review this alert
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Network Access Control List Created with All Open Ports - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = The search looks for AWS CloudTrail events to detect if any network ACLs were created with all the ports open to a specified CIDR.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS, version 4.4.0 or later, and configure your AWS CloudTrail inputs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It's possible that an admin has created this ACL with all ports open for some legitimate purpose however, this should be scoped and not allowed in production environment.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Network Access Control List Deleted - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = Enforcing network-access controls is one of the defensive mechanisms used by cloud administrators to restrict access to a cloud instance. After the attacker has gained control of the AWS console by compromising an admin account, they can delete a network ACL and gain access to the instance from anywhere. This search will query the AWS CloudTrail logs to detect users deleting network ACLs.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a user has legitimately deleted a network ACL.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS New MFA Method Registered For User - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies the registration of a new Multi Factor authentication method for an AWS account. Adversaries who have obtained unauthorized access to an AWS account may register a new MFA method to maintain persistence.
how_to_implement = You must install Splunk AWS add on and Splunk App for AWS. This search works when AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Password Policy Changes - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user is making successful API calls to view/update/delete the existing password policy in an AWS organization. It is unlikely for a regular user to conduct this operation. These events may potentially be malicious, adversaries often use this information to gain more understanding of the password defenses in place and exploit them to increase their attack surface when a user account is compromised.
how_to_implement = You must install Splunk AWS Add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately triggered an AWS audit tool activity which may trigger this event.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS S3 Exfiltration Behavior Identified - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This correlation search looks at the risk events created by the detection analytics related Collection and Exfiltration techniques used by adversaries. The rule is designed to identify instances where 2 or more analytics unique AWS analytics and 2 or more distinct mitre IDs has triggered for a particular risk object. This alert when triggered may indicate a potential exfiltration in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information.
how_to_implement = You must enable all the detection searches in the Data Exfiltration Analytic story to create risk events in Enterprise Security.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.AE"]}
known_false_positives = alse positives may be present based on automated tooling or system administrators. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - AWS SAML Access by Provider User and Principal - Rule]
type = detection
asset_type = AWS Federated Account
confidence = medium
explanation = This search provides specific SAML access from specific Service Provider, user and targeted principal at AWS. This search provides specific information to detect abnormal access or potential credential hijack or forgery, specially in federated environments using SAML protocol inside the perimeter or cloud provider.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Attacks using a Golden SAML or SAML assertion hijacks or forgeries are very difficult to detect as accessing cloud providers with these assertions looks exactly like normal access, however things such as source IP sourceIPAddress user, and principal targeted at receiving cloud provider along with endpoint credential access and abuse detection searches can provide the necessary context to detect these attacks.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS SAML Update identity provider - Rule]
type = detection
asset_type = AWS Federated Account
confidence = medium
explanation = This search provides detection of updates to SAML provider in AWS. Updates to SAML provider need to be monitored closely as they may indicate possible perimeter compromise of federated credentials, or backdoor access from another cloud provider set by attacker.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]}
known_false_positives = Updating a SAML provider or creating a new one may not necessarily be malicious however it needs to be closely monitored.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS SetDefaultPolicyVersion - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user has set a default policy versions. Attackers have been know to use this technique for Privilege Escalation in case the previous versions of the policy had permissions to access more resources than the current version of the policy
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately set a default policy to allow a user to access all resources. That said, AWS strongly advises against granting full control to all AWS resources
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Successful Console Authentication From Multiple IPs - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies an AWS account successfully authenticating from more than one unique Ip address in the span of 5 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments.
how_to_implement = You must install Splunk AWS add on and Splunk App for AWS. This search works when AWS CloudTrail events are normalized use the Authentication datamodel.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1535"], "nist": ["DE.AE"]}
known_false_positives = A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Successful Single-Factor Authentication - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies a successful Console Login authentication event against an AWS IAM user for an account without Multi-Factor Authentication enabled. This could be evidence of a misconfiguration, a policy violation or an account take over attempt that should be investigated
how_to_implement = The Splunk AWS Add-on is required to utilize this data. The search requires AWS Cloudtrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = It is possible that some accounts do not have MFA enabled for the AWS account however its agaisnt the best practices of securing AWS.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Unusual Number of Failed Authentications From Ip - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic identifies one source IP failing to authenticate into the AWS Console with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an AWS environment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises. While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `AWS Multiple Users Failing To Authenticate From Ip`.
how_to_implement = You must install Splunk Add-on for AWS in order to ingest Cloudtrail. We recommend the users to try different combinations of the bucket span time and the calculation of the upperBound field to tune this search according to their environment
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = No known false postives for this detection. Please review this alert
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS UpdateLoginProfile - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user A who has already permission to update login profile, makes an API call to update login profile for another user B . Attackers have been know to use this technique for Privilege Escalation in case new victim(user B) has more permissions than old victim(user B)
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with AWS CloudTrail logs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created keys for another user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Azure Active Directory High Risk Sign-in - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic triggers on a high risk sign-in against Azure Active Directory identified by Azure Identity Protection. Identity Protection monitors sign-in events using heuristics and machine learning to identify potentially malicious events and categorizes them in three categories high, medium and low.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. Specifically, this analytic leverages the RiskyUsers and UserRiskEvents log category in the azure:monitor:aad sourcetype.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003"], "nist": ["DE.CM"]}
known_false_positives = Details for the risk calculation algorithm used by Identity Protection are unknown and may be prone to false positives.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Admin Consent Bypassed by Service Principal - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = This detection focuses on identifying instances in Azure Active Directory where a service principal assigns app roles without standard admin consent, using Entra ID logs. It operates on the azure_monitor_aad data source, scrutinizing the "Add app role assignment to service principal" operation, specifically from service principals. The query dissects details such as role ID, value, and description, important for understanding the nature of the roles being assigned. Monitoring this in a SOC is critical as it flags potential bypasses of vital administrative consent processes in Azure AD, which could result in unauthorized privileges being granted. A true positive detection suggests that a service principal may be exploiting automation to assign sensitive permissions without proper oversight.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Application Administrator Role Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the assignment of the Application Administrator role to an Azure AD user. Users in this role can create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to manage application credentials. Users assigned this role can add credentials to an application, and use those credentials to impersonate the applications identity. If the applications identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application. This ability to impersonate the applications identity may be an elevation of privilege over what the user can do via their role assignments. Red teams and adversaries alike may abuse this role to escalate their privileges in an Azure AD tenant.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlog log category
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately assign the Application Administrator role to a user. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Authentication Failed During MFA Challenge - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies an authentication attempt event against an Azure AD tenant that fails during the Multi Factor Authentication challenge. Error Code 500121 represents a failed attempt to authenticate using a second factor. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. 
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]}
known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Block User Consent For Risky Apps Disabled - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = This analytic detects when the risk-based step-up consent security setting in Azure AD is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative step-up for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"]}
known_false_positives = Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Concurrent Sessions From Different Ips - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies an Azure AD account with concurrent sessions coming from more than one unique Ip address within the span of 5 minutes. This behavior could represent a session hijacking attack whereby an adversary has extracted cookies from a victims browser and is using them from a different location to access corporate online resources. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]}
known_false_positives = A user with concurrent sessions from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Device Code Authentication - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies the execution of the Azure Device Code Phishing attack, which can lead to Azure Account Take-Over (ATO). The detection leverages Azure AD logs specifically focusing on authentication requests to identify the attack. This technique involves creating malicious infrastructure, bypassing Multi-Factor Authentication (MFA), and bypassing Conditional Access Policies (CAPs). The attack aims to compromise users by sending them phishing emails from attacker-controlled domains and trick the victims into performing OAuth 2.0 device authentication. A successful execution of this attack can result in adversaries gaining unauthorized access to Azure AD, Exchange mailboxes, and the target's Outlook Web Application (OWA). This attack technique was detailed by security researchers including Bobby Cooke, Stephan Borosh, and others. It's crucial for organizations to be aware of this threat, as it can lead to unauthorized access and potential data breaches.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery"], "mitre_attack": ["T1528", "T1566", "T1566.002"], "nist": ["DE.CM"]}
known_false_positives = In most organizations, device code authentication will be used to access common Microsoft service but it may be legitimate for others. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD External Guest User Invited - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the invitation of an external guest user within Azure AD. With Azure AD B2B collaboration, users and administrators can invite external users to collaborate with internal users. External guest account invitations should be monitored by security teams as they could potentially lead to unauthorized access. An example of this attack vector was described at BlackHat 2022 by security researcher Dirk-Jan during his tall `Backdooring and Hijacking Azure AD Accounts by Abusing External Identities`
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"]}
known_false_positives = Administrator may legitimately invite external guest users. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD FullAccessAsApp Permission Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies when the 'full_access_as_app' permission, marked by the GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', is assigned to an application within Office 365 Exchange Online, identified by ResourceAppId '00000002-0000-0ff1-ce00-000000000000'. This permission grants broad control over Office 365 operations, including full access to all mailboxes and the capability to send emails as any user. The query utilizes the azure_monitor_aad data source, focusing on AuditLogs with the operation name 'Update application'. This monitoring is crucial for early detection of potential unauthorized access or data exfiltration, as the 'full_access_as_app' permission could lead to significant security incidents if exploited.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Global Administrator Role Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the assignment of the Azure AD Global Administrator role to an Azure AD user. The Global Administrator role is the most powerful administrator role in Azure AD and provides almost unlimited access to data, resources and settings. It is equivalent to the Domain Administrator group in an Active Directory environment. While Azure AD roles do not grant access to Azure services and resources, it is possible for a Global Administrator account to gain control of Azure resources. Adversaries and red teams alike may assign this role to a compromised account to establish Persistence or escalate their privileges in an Azure AD environment.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately assign the Global Administrator role to a user. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD High Number Of Failed Authentications For User - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies an Azure AD account with more than 20 failed authentication events in the span of 10 minutes. This behavior could represent a brute force attack against the account. As environments differ across organizations, security teams should customize the threshold of this detection.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"]}
known_false_positives = A user with more than 20 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies an Ip address failing to authenticate 20 or more times to an Azure AD tenant in the span of 10 minutes. This behavior could represent a brute force attack againstan Azure AD to obtain initial access or elevate privileges. As environments differ across organizations, security teams should customize the threshold of this detection.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"]}
known_false_positives = An Ip address with more than 20 failed authentication attempts in the span of 10 minutes may also be triggered by a broken application.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multi-Factor Authentication Disabled - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies an attempt to disable multi-factor authentication for an Azure AD user. An adversary who has obtained access to an Azure AD tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = Legitimate use case may require for users to disable MFA. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multi-Source Failed Authentications Spike - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = This analytic detects potential distributed password spraying attacks within an Azure AD environment. It identifies a notable increase in failed authentication attempts across a variety of unique user-and-IP address combinations, originating from multiple source IP addresses and countries, and employing different user agents. Such patterns suggest an adversary's attempt to bypass security controls by using a range of IP addresses to test commonly used passwords against numerous user accounts. The detection scrutinizes SignInLogs from Azure AD logs, particularly focusing on events with error code 50126, which signals a failed authentication due to incorrect credentials. By collating data over a five-minute interval, the analytic computes the distinct counts of user-and-IP combinations, unique users, source IPs, and countries. It then applies a set of thresholds to these metrics to pinpoint unusual activities that could indicate a coordinated attack effort. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Recognizing this behavior is vital for security operations centers (SOCs) as distributed password spraying represents a more complex form of traditional password spraying. Attackers distribute the source of their attempts to evade detection mechanisms that typically monitor for single-source IP anomalies. Prompt detection of such distributed activities is essential to thwart unauthorized access attempts, prevent account compromises, and mitigate the risk of further malicious activities within the organization's network. A true positive alert from this analytic suggests an active distributed password spraying attack against the organization's Azure AD tenant. A successful attack could result in unauthorized access, particularly to accounts with elevated privileges, leading to data breaches, privilege escalation, persistent threats, and lateral movement within the organization's infrastructure.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multiple AppIDs and UserAgents Authentication Spike - Rule]
type = detection
asset_type = Azure AD Tenant
confidence = medium
explanation = This analytic is crafted to identify unusual and potentially malicious authentication activity within an Azure AD environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of Azure AD audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multiple Denied MFA Requests For User - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = This analytic targets the detection of an unusually high number of denied Multi-Factor Authentication (MFA) requests for a single user within a 10-minute window, specifically identifying instances where more than nine MFA prompts were declined by the user. Utilizing Azure Active Directory (Azure AD) sign-in logs, particularly focusing on "Sign-in activity" events, it filters for scenarios where the MFA request was denied due to the user declining the authentication, as indicated by error code 500121 and additional details stating "MFA denied; user declined the authentication." The data is then aggregated into 10-minute intervals, counting distinct raw events and capturing the earliest and latest times of occurrence for each user. This behavior is significant for a Security Operations Center (SOC) as it could be an early indicator of a targeted attack or an account compromise attempt, with an attacker having obtained the user's credentials and the user actively declining the MFA prompts, preventing unauthorized access. A true positive detection would imply that an attacker is on the verge of gaining full access to the user's account, posing a threat that could lead to data exfiltration, lateral movement, or further malicious activities within the organization, necessitating immediate investigation and response to safeguard the organization's assets.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]}
known_false_positives = Multiple denifed MFA requests in a short period of span may also be a sign of authentication errors. Investigate and filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multiple Failed MFA Requests For User - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within an Azure AD tenant. Error Code 500121 represents a failed attempt to authenticate using a second factor. Specifically, the analytic triggers when more than 10 MFA user prompts fail within 10 minutes. The reasons for these failure could be several, like the user not responding in time or receiving multiple duplicate MFA requests. Azure AD tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multiple Service Principals Created by SP - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = This detection identifies when a single service principal in Azure AD creates more than three unique OAuth applications within a 10-minute span, potentially signaling malicious activity. It monitors the 'Add service principal' operation, focusing on the activity of service principals rather than individual users. By aggregating the creation events over a 10-minute period, the analytic tracks how many distinct OAuth applications are created by each service principal. This is key for SOC teams to pinpoint potential attack staging, where an attacker might use a compromised or malicious service principal to rapidly establish multiple service principals, facilitating network infiltration or expansion. While the default threshold is set to trigger on more than three applications, security teams should adjust this to fit their specific environment's norm
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]}
known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multiple Service Principals Created by User - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = This detection focuses on identifying instances where a single user creates more than three unique OAuth applications within a 10-minute timeframe in Azure AD, a potential indicator of malicious activity. By monitoring the 'Add service principal' operation and aggregating the data with a 10-minute bucket span, it tracks the number of distinct OAuth applications created by each user. This analytic is crucial for SOC teams to detect possible staging of attacks, where an adversary might rapidly create multiple service principals as part of their infiltration or expansion strategy within the network. The threshold of three applications is set to flag unusual behavior, but security teams are advised to adjust this value to suit the normal operational patterns of their environment
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]}
known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Multiple Users Failing To Authenticate From Ip - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies one source Ip failing to authenticate with 30 unique valid users within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password. This logic can be used for real time security monitoring as well as threat hunting exercises.\
Azure AD tenants can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold if needed.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = A source Ip failing to authenticate with multiple users is not a common for legitimate behavior.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD New Custom Domain Added - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the addition of a new custom domain within an Azure Active Directory tenant. Adding a custom domain is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"]}
known_false_positives = In most organizations, new customm domains will be updated infrequently. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD New Federated Domain Added - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the addition of a new federated domain within an Azure Active Directory tenant. This event could represent the execution of the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.002"], "nist": ["DE.CM"]}
known_false_positives = In most organizations, domain federation settings will be updated infrequently. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD New MFA Method Registered - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Azure Active Directory by monitoring Azure AD audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]}
known_false_positives = Users may register MFA methods legitimally, investigate and filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD New MFA Method Registered For User - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the registration of a new Multi Factor authentication method for an Azure AD account. Adversaries who have obtained unauthorized access to an Azure AD account may register a new MFA method to maintain persistence.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = Newly onboarded users who are registering an MFA method for the first time will also trigger this detection.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD OAuth Application Consent Granted By User - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = This analytic detects when a user in an Azure AD environment grants consent to an OAuth application, capturing any consent granted regardless of the specific permissions requested. Utilizing Azure AD audit logs, it focuses on events related to OAuth application consents, alerting security teams to instances where users actively grant consent to applications. This monitoring is crucial as it highlights potential risks associated with third-party applications gaining access to organizational data, a tactic often exploited by malicious actors to gain unauthorized access. A true positive from this analytic necessitates immediate investigation to validate the application's legitimacy, review the granted permissions, and assess potential risks, helping to prevent unauthorized access and protect sensitive data and resources. While false positives may occur with legitimate application integrations, ensuring alignment with organizational policies and security best practices is paramount.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = False positives may occur if users are granting consents as part of legitimate application integrations or setups. It is crucial to review the application and the permissions it requests to ensure they align with organizational policies and security best practices.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD PIM Role Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = As part of legitimate administrative behavior, users may be assigned PIM roles. Filter as needed
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD PIM Role Assignment Activated - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = As part of legitimate administrative behavior, users may activate PIM roles. Filter as needed
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Privileged Authentication Administrator Role Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the assignment of the Privileged Authentication Administrato role to an Azure AD user. Users in this role can set or reset authentication methods for any user in Azure Active Directory, including privileged roles like Global Administrators. Users with this role can change credentials for people who may have access to sensitive or private information or critical configuration inside and outside of Azure Active Directory. Changing the credentials of a user may mean the ability to assume that users identity and permissions. Red teams and adversaries alike may abuse this role to escalate their privileges.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately assign the Privileged Authentication Administrator role as part of administrative tasks. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Privileged Graph API Permission Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = This Splunk analytic flags the assignment of three high-risk Graph API permissions in Azure AD, Application.ReadWrite.All (1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions enable broad control over Azure AD, including application and directory settings. Utilizing azure_monitor_aad data, the query scans AuditLogs for 'Update application' operations, identifying when these permissions are assigned. It collects data on user, object, and user agent. Immediate attention is needed upon detection, as misuse of these permissions can lead to unauthorized Azure AD modifications and potential security breaches.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]}
known_false_positives = Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Privileged Role Assigned - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the assignment of sensitive and privileged Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike may assign these roles to a compromised account to establish Persistence in an Azure AD environment.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators will legitimately assign the privileged roles users as part of administrative tasks. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Privileged Role Assigned to Service Principal - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). The detection is made by running a specific search within the ingested Azure Active Directory events to leverage the AuditLogs log category. This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately assign the privileged roles to Service Principals as part of administrative tasks. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Service Principal Authentication - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = Monitoring service principal authentication events in Azure Active Directory is crucial, but to effectively leverage this detection, teams should first conduct a thorough inventory of all service principals and their source IPs to establish a baseline of normal behavior. The detection, using azure_monitor_aad, specifically targets "Sign-in activity" within ServicePrincipalSignInLogs, gathering key details like sign-in frequency, timing, source IPs, and accessed resources. This baseline is essential for SOC teams to distinguish between regular application authentication and anomalous patterns that might suggest compromised credentials or malicious activities.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Service Principals will legitimally authenticate remotely to your tenant. Implementing this detection after establishing a baseline enables a more accurate identification of security threats, ensuring proactive and informed responses to safeguard the Azure AD environment. source ips.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Service Principal Created - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the creation of a Service Principal in an Azure AD environment. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may create a Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment thorough an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.CM"]}
known_false_positives = Administrator may legitimately create Service Principal. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Service Principal New Client Credentials - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the addition of new credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 certificates and passwords. With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules. Adversaries and red teams alike who have obtained privileged access to Azure AD may add credentials to Service Principals to maintain persistent access to victim accounts and other instances within the Azure environment. By compromising an account who is an Owner of an application with privileged access, attackers may also escalate their privileges in an Azure AD environment by adding new credentials and logging in as the service principal.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"]}
known_false_positives = Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Service Principal Owner Added - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the addition of a new owner for a Service Principal within an Azure AD tenant. An Azure Service Principal is an identity designed to be used with applications, services, and automated tools to access resources. It is similar to a service account within an Active Directory environment. Service Principal authentication does not support multi-factor authentication nor conditional access policies. Adversaries and red teams alike who have obtained administrative access may add a new owner for an existing Service Principal to establish Persistence and obtain single-factor access to an Azure AD environment. Attackers who are looking to escalate their privileges by leveraging a Service Principals permissions may also add a new owner.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = Administrator may legitimately add new owners for Service Principals. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Successful Authentication From Different Ips - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies an Azure AD account successfully authenticating from more than one unique Ip address in the span of 30 minutes. This behavior could represent an adversary who has stolen credentials via a phishing attack or some other method and using them to access corporate online resources around the same time as a legitimate user. As users may behave differently across organizations, security teams should test and customize this detection to fit their environments.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001", "T1110.003"], "nist": ["DE.CM"]}
known_false_positives = A user with successful authentication events from different Ips may also represent the legitimate use of more than one device. Filter as needed and/or customize the threshold to fit your environment.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Successful PowerShell Authentication - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies a successful authentication event against an Azure AD tenant using PowerShell commandlets. This behavior is not common for regular, non administrative users. After compromising an account in Azure AD, attackers and red teams  alike will perform enumeration and discovery techniques. One method of executing these techniques is leveraging the native PowerShell modules.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Administrative users will likely use PowerShell commandlets to troubleshoot and maintain the environment. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Successful Single-Factor Authentication - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies a successful authentication event against Azure Active Directory for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Although not recommended, certain users may be required without multi-factor authentication. Filter as needed
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Tenant Wide Admin Consent Granted - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies instances where admin consent is granted to an application within an Azure AD tenant. It leverages Azure AD audit logs, specifically events related to the admin consent action within the ApplicationManagement category. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Auditlogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may be granted tenant wide consent, filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD Unusual Number of Failed Authentications From Ip - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies one source Ip failing to authenticate with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against an Azure Active Directory tenant to obtain initial access or elevate privileges. Error Code 50126 represents an invalid password.\
The detection calculates the standard deviation for source Ip and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `Azure AD Multiple Users Failing To Authenticate From Ip`.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the Signin log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = A source Ip failing to authenticate with multiple users is not a common for legitimate behavior.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD User Consent Blocked for Risky Application - Rule]
type = detection
asset_type = Azure AD tenant
confidence = medium
explanation = The following analytic identifies instances where Azure AD has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the Azure AD audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where Azure's built-in security measures have intervened. Applications that are flagged and blocked by Azure typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = UPDATE_KNOWN_FALSE_POSITIVES
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD User Consent Denied for OAuth Application - Rule]
type = detection
asset_type = Azure AD
confidence = medium
explanation = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Azure AD environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the Azure AD's audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment through an EventHub. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the SignInLogs log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = Users may deny consent for legitimate applications by mistake, filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD User Enabled And Password Reset - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies an Azure AD user enabling a previously disabled account and resetting its password within 2 minutes. This behavior could represent an adversary who has obtained administrative access and is trying to establish a backdoor identity within an Azure AD tenant.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = While not common, Administrators may enable accounts and reset their passwords for legitimate reasons. Filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure AD User ImmutableId Attribute Updated - Rule]
type = detection
asset_type = Azure Active Directory
confidence = medium
explanation = The following analytic identifies the modification of the SourceAnchor (also called ImmutableId) attribute for an Azure Active Directory user. Updating this attribute is a step required to set up the Azure Active Directory identity federation backdoor technique discovered by security researcher Nestori Syynimaa. Similar to Active Directory, Azure AD uses the concept of domains to manage directories of identities. A new Azure AD tenant will initially contain a single domain that is commonly called the `cloud-only` onmicrosoft.com domain. Organizations can also add their registered custom domains to Azure AD for email addresses to match the organizations domain name. If the organization intends to use a third-party identity provider such as ADFS for authentication, the added custom domains can be configured as federated. An adversary who has obtained privileged access to an Azure AD tenant may leverage this technique to establish persistence and be able to authenticate to Azure AD impersonating any user and bypassing the requirement to have a valid password and/or perform MFA.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = The SourceAnchor (also called ImmutableId) Azure AD attribute has legitimate uses for directory synchronization. Investigate and filter as needed.
providing_technologies = ["Azure AD", "Entra ID"]

[savedsearch://ESCU - Azure Automation Account Created - Rule]
type = detection
asset_type = Azure
confidence = medium
explanation = The following analytic identifies the creation of a new Azure Automation account within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure using PowerShell and Python. Azure Automation can also be configured to automate tasks on on premise infrastructure using a component called a Hybrid Runbook Worker. Automation accounts serve as a container to isolate Automation resources, runbooks, assets, and configurations from the resources of other accounts. They allow administrators to separate resources into logical environments or delegated responsibilities. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation account with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately create Azure Automation accounts. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Azure Automation Runbook Created - Rule]
type = detection
asset_type = Azure
confidence = medium
explanation = The following analytic identifies the creation of a new Azure Automation Runbook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. Adversaries or red teams who have obtained privileged access to an Azure tenant may create an Azure Automation Runbook that runs with elevated privileges to maintain persistence in the Azure tenant. A malicious Automation Runbook can be created to create Global Administrators in Azure AD, execute code on VMs, etc.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136", "T1136.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately create Azure Automation Runbooks. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Azure Runbook Webhook Created - Rule]
type = detection
asset_type = Azure
confidence = medium
explanation = The following analytic identifies the creation of a new Automation Runbook Webhook within an Azure tenant. Azure Automation is a cloud-based automation platform that allows administrators to automate Azure management tasks and orchestrate actions across external systems within Azure. Azure Automation script files called Runbooks that can be written in PowerShell or Python. One of the ways administrators can configure a Runbook to be executed is through HTTP Webhooks. Webhooks leverage custom unauthenticated URLs that are exposed to the Internet. An adversary who has obtained privileged access to an Azure tenant may create a Webhook to trigger the execution of an Automation Runbook with malicious code that can create users or execute code on a VM. This provides a persistent foothold on the environment.
how_to_implement = You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase (https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Audit events into your Splunk environment. Specifically, this analytic leverages the Azure Activity log category.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Administrators may legitimately create Azure Runbook Webhooks. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Circle CI Disable Security Job - Rule]
type = detection
asset_type = CircleCI
confidence = medium
explanation = This analytic searches for a specific behavior in CircleCI pipelines such as the disabling of security jobs. The detection is made by using a Splunk query that renames certain fields and retrieves values for specified job names, workflow IDs and names, user information, commit messages, URLs, and branches. Then, the query identifies mandatory jobs for each workflow and searches for instances where they were run. The search also identifies the phase of the pipeline as "build" and extracts the repository name from the URL using regular expressions. The detection is important because it detects attempts to bypass security measures in CircleCI pipelines, which can potentially lead to malicious code being introduced into the pipeline, data breaches, system downtime, and reputational damage.  False positives might occur since legitimate use cases can require the disabling of security jobs. However, you can proactively monitor and identify any suspicious activity in the pipeline using this analytic and mitigate potential threats through early detection.
how_to_implement = You must index CircleCI logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Circle CI Disable Security Step - Rule]
type = detection
asset_type = CircleCI
confidence = medium
explanation = The following analytic detects the disablement of security steps in a CircleCI pipeline. Addressing instances of security step disablement in CircleCI pipelines can mitigate the risks associated with potential security vulnerabilities and unauthorized changes. A proactive approach helps protect the organization's infrastructure, data, and overall security posture. The detection is made by a Splunk query that searches for specific criteria within CircleCI logs through a combination of field renaming, joining, and statistical analysis to identify instances where security steps are disabled. It retrieves information such as job IDs, job names, commit details, and user information from the CircleCI logs.  The detection is important because it indicates potential security vulnerabilities or unauthorized changes to the pipeline caused by someone within the organization intentionally or unintentionally disabling security steps in the CircleCI pipeline.Disabling security steps can leave the pipeline and the associated infrastructure exposed to potential attacks, data breaches, or the introduction of malicious code into the pipeline. Investigate by reviewing the job name, commit details, and user information associated with the disablement of security steps. You must also examine any relevant on-disk artifacts and identify concurrent processes that might indicate the source of the attack or unauthorized change.
how_to_implement = You must index CircleCI logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1554"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Cloud API Calls From Previously Unseen User Roles - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = The following analytic detects when a new command is run by a user, who typically does not run those commands. The detection is made by a Splunk query to search for these commands in the Change data model. Identifies commands run by users with the user_type of AssumedRole and a status of success. The query retrieves the earliest and latest timestamps of each command run and groups the results by the user and command. Then, it drops the unnecessary data model object name and creates a lookup to verify if the command was seen before. The lookup table contains information about previously seen cloud API calls for each user role, including the first time the command was seen and whether enough data is available for analysis. If the firstTimeSeenUserApiCall field is null or greater than the relative time of 24 hours ago, it indicates that the command is new and was not seen before. The final result table includes the firstTime, user, object, and command fields of the new commands. It also applies the security_content_ctime function to format the timestamps and applies a filter to remove any cloud API calls from previously unseen user roles. The detection is important because it helps to identify new commands run by different user roles. New commands can indicate potential malicious activity or unauthorized actions within the environment. Detecting and investigating these new commands can help identify and mitigate potential security threats earlier, preventing data breaches, unauthorized access, or other damaging outcomes.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider.  You should run the baseline search `Previously Seen Cloud API Calls Per User Role - Initial` to build the initial table of user roles, commands, and times. You must also enable the second baseline search `Previously Seen Cloud API Calls Per User Role - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `cloud_api_calls_from_previously_unseen_user_roles_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_api_calls_from_previously_unseen_user_roles_filter`
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = .
providing_technologies = null

[savedsearch://ESCU - Cloud Compute Instance Created By Previously Unseen User - Rule]
type = detection
asset_type = Cloud Compute Instance
confidence = medium
explanation = This search looks for cloud compute instances created by users who have not created them before.
how_to_implement = You must be ingesting the appropriate cloud-infrastructure logs Run the "Previously Seen Cloud Compute Creations By User" support search to create of baseline of previously seen users.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a user will start to create compute instances for the first time, for any number of reasons. Verify with the user launching instances that this is the intended behavior.
providing_technologies = null

[savedsearch://ESCU - Cloud Compute Instance Created In Previously Unused Region - Rule]
type = detection
asset_type = Cloud Compute Instance
confidence = medium
explanation = This search looks at cloud-infrastructure events where an instance is created in any region within the last hour and then compares it to a lookup file of previously seen regions where instances have been created.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Regions - Initial` to build the initial table of images observed and times. You must also enable the second baseline search `Previously Seen Cloud Regions - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_in_previously_unused_region_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1535"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a user has unknowingly started an instance in a new region. Please verify that this activity is legitimate.
providing_technologies = null

[savedsearch://ESCU - Cloud Compute Instance Created With Previously Unseen Image - Rule]
type = detection
asset_type = Cloud Compute Instance
confidence = medium
explanation = The following analytic detects potential instances that are created in a cloud computing environment using new or unknown image IDs that have not been seen before. This detection is important because it helps to investigate and take appropriate action to prevent further damage or unauthorized access to the Cloud environment, which can include data breaches, unauthorized access to sensitive information, or the deployment of malicious payloads within the cloud environment. False positives might occur since legitimate instances can also have previously unseen image IDs. Next steps include conducting an extensive triage and investigation to determine the nature of the activity. During triage, review the details of the created instances, including the user responsible for the creation, the image ID used, and any associated metadata. Additionally, consider inspecting any relevant on-disk artifacts and analyzing concurrent processes to identify the source of the attack.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Images - Initial` to build the initial table of images observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Images - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_image_filter` macro.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = After a new image is created, the first systems created with that image will cause this alert to fire.  Verify that the image being used was created by a legitimate user.
providing_technologies = null

[savedsearch://ESCU - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule]
type = detection
asset_type = Cloud Compute Instance
confidence = medium
explanation = The following analytic detects the creation of EC2 instances with previously unseen instance types. The detection is made by using a Splunk query to identify the EC2 instances. First, the query searches for changes in the EC2 instance creation action and filters for instances with instance types that are not recognized or previously seen. Next, the query uses the Splunk tstats command to gather the necessary information from the Change data model. Then, it filters the instances with unknown instance types and reviews previously seen instance types to determine if they are new or not. The detection is important because it identifies attackers attempting to create instances with unknown or potentially compromised instance types, which can be an attempt to gain unauthorized access to sensitive data, compromise of systems, exfiltrate data, potential disruption of services, or launch other malicious activities within the environment. False positives might occur since there might be legitimate reasons for creating instances with previously unseen instance types. Therefore, you must carefully review and triage all alerts.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You should run the baseline search `Previously Seen Cloud Compute Instance Types - Initial` to build the initial table of instance types observed and times. You must also enable the second baseline search `Previously Seen Cloud Compute Instance Types - Update` to keep this table up to date and to age out old data. You can also provide additional filtering for this search by customizing the `cloud_compute_instance_created_with_previously_unseen_instance_type_filter` macro.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = It is possible that an admin will create a new system using a new instance type that has never been used before. Verify with the creator that they intended to create the system with the new instance type.
providing_technologies = null

[savedsearch://ESCU - Cloud Instance Modified By Previously Unseen User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for cloud instances being modified by users who have not previously modified them.
how_to_implement = This search has a dependency on other searches to create and update a baseline of users observed to be associated with this activity. The search "Previously Seen Cloud Instance Modifications By User - Update" should be enabled for this detection to properly work.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004", "T1078"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a new user will start to modify EC2 instances when they haven't before for any number of reasons. Verify with the user that is modifying instances that this is the intended behavior.
providing_technologies = null

[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen City - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for cloud provisioning activities from previously unseen cities. Provisioning activities are defined broadly as any event that runs or creates something.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider.  You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_city_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = null

[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen Country - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for cloud provisioning activities from previously unseen countries. Provisioning activities are defined broadly as any event that runs or creates something.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider.  You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_country_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = null

[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen IP Address - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for cloud provisioning activities from previously unseen IP addresses. Provisioning activities are defined broadly as any event that runs or creates something.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider.  You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_ip_address_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = null

[savedsearch://ESCU - Cloud Provisioning Activity From Previously Unseen Region - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for cloud provisioning activities from previously unseen regions. Provisioning activities are defined broadly as any event that runs or creates something.
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider.  You should run the baseline search `Previously Seen Cloud Provisioning Activity Sources - Initial` to build the initial table of source IP address, geographic locations, and times. You must also enable the second baseline search `Previously Seen Cloud Provisioning Activity Sources - Update` to keep this table up to date and to age out old data. You can adjust the time window for this search by updating the `previously_unseen_cloud_provisioning_activity_window` macro. You can also provide additional filtering for this search by customizing the `cloud_provisioning_activity_from_previously_unseen_region_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = null

[savedsearch://ESCU - Cloud Security Groups Modifications by User - Rule]
type = detection
asset_type = Cloud Instance
confidence = medium
explanation = The following analytic identifies users who are unsually modifying security group in your cloud enriovnment,focusing on actions such as modifications, deletions, or creations performed by users over 30-minute intervals. Analyzing patterns of modifications to security groups can help in identifying anomalous behavior that may indicate a compromised account or an insider threat.\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will only trigger on all user and service accounts that have created/modified/deleted a security group .\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and values of the security objects affected.
how_to_implement = This search requries the Cloud infrastructure logs such as AWS Cloudtrail, GCP Pubsub Message logs, Azure Audit logs to be ingested into an accelerated Change datamodel. It is also recommended that users can try different combinations of the `bucket` span time and outlier conditions to better suit with their environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1578.005"], "nist": ["DE.AE"]}
known_false_positives = It is possible that legitimate user/admin may modify a number of security groups
providing_technologies = null

[savedsearch://ESCU - Detect AWS Console Login by New User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1552"], "nist": ["DE.AE"]}
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
providing_technologies = null

[savedsearch://ESCU - Detect AWS Console Login by User from New City - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_city_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]}
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
providing_technologies = null

[savedsearch://ESCU - Detect AWS Console Login by User from New Country - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_country_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]}
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
providing_technologies = null

[savedsearch://ESCU - Detect AWS Console Login by User from New Region - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour
how_to_implement = You must install and configure the Splunk Add-on for AWS (version 5.1.0 or later) and Enterprise Security 6.2, which contains the required updates to the Authentication data model for cloud use cases. Run the `Previously Seen Users in AWS CloudTrail - Initial` support search only once to create a baseline of previously seen IAM users within the last 30 days. Run `Previously Seen Users in AWS CloudTrail - Update` hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines. You can also provide additional filtering for this search by customizing the `detect_aws_console_login_by_user_from_new_region_filter` macro.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1535"], "nist": ["DE.AE"]}
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
providing_technologies = null

[savedsearch://ESCU - Detect GCP Storage access from a new IP - Rule]
type = detection
asset_type = GCP Storage Bucket
confidence = medium
explanation = This search looks at GCP Storage bucket-access logs and detects new or previously unseen remote IP addresses that have successfully accessed a GCP Storage bucket.
how_to_implement = This search relies on the Splunk Add-on for Google Cloud Platform, setting up a Cloud Pub/Sub input, along with the relevant GCP PubSub topics and logging sink to capture GCP Storage Bucket events (https://cloud.google.com/logging/docs/routing/overview). In order to capture public GCP Storage Bucket access logs, you must also enable storage bucket logging to your PubSub Topic as per https://cloud.google.com/storage/docs/access-logs.  These logs are deposited into the nominated Storage Bucket on an hourly basis and typically show up by 15 minutes past the hour.  It is recommended to configure any saved searches or correlation searches in Enterprise Security to run on an hourly basis at 30 minutes past the hour (cron definition of 30 * * * *).  A lookup table (previously_seen_gcp_storage_access_from_remote_ip.csv) stores the previously seen access requests, and is used by this search to determine any newly seen IP addresses accessing the Storage Buckets.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1530"], "nist": ["DE.AE"]}
known_false_positives = GCP Storage buckets can be accessed from any IP (if the ACLs are open to allow it), as long as it can make a successful connection. This will be a false postive, since the search is looking for a new IP within the past two hours.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Detect New Open GCP Storage Buckets - Rule]
type = detection
asset_type = GCP Storage Bucket
confidence = medium
explanation = This search looks for GCP PubSub events where a user has created an open/public GCP Storage bucket.
how_to_implement = This search relies on the Splunk Add-on for Google Cloud Platform, setting up a Cloud Pub/Sub input, along with the relevant GCP PubSub topics and logging sink to capture GCP Storage Bucket events (https://cloud.google.com/logging/docs/routing/overview).
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1530"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that a GCP admin has legitimately created a public bucket for a specific purpose. That said, GCP strongly advises against granting full control to the "allUsers" group.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Detect New Open S3 buckets - Rule]
type = detection
asset_type = S3 Bucket
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user has created an open/public S3 bucket.
how_to_implement = You must install the AWS App for Splunk.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1530"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a public bucket for a specific purpose. That said, AWS strongly advises against granting full control to the "All Users" group.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect New Open S3 Buckets over AWS CLI - Rule]
type = detection
asset_type = S3 Bucket
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user has created an open/public S3 bucket over the aws cli.
how_to_implement = 
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1530"], "nist": ["DE.CM"]}
known_false_positives = While this search has no known false positives, it is possible that an AWS admin has legitimately created a public bucket for a specific purpose. That said, AWS strongly advises against granting full control to the "All Users" group.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect S3 access from a new IP - Rule]
type = detection
asset_type = S3 Bucket
confidence = medium
explanation = This search looks at S3 bucket-access logs and detects new or previously unseen remote IP addresses that have successfully accessed an S3 bucket.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your S3 access logs' inputs. This search works best when you run the "Previously Seen S3 Bucket Access by Remote IP" support search once to create a history of previously seen remote IPs and bucket names.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1530"], "nist": ["DE.AE"]}
known_false_positives = S3 buckets can be accessed from any IP, as long as it can make a successful connection. This will be a false postive, since the search is looking for a new IP within the past hour
providing_technologies = null

[savedsearch://ESCU - Detect Spike in AWS Security Hub Alerts for EC2 Instance - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for a spike in number of of AWS security Hub alerts for an EC2 instance in 4 hours intervals
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your Security Hub inputs. The threshold_value should be tuned to your environment and schedule these searches according to the bucket span interval.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = None
providing_technologies = null

[savedsearch://ESCU - Detect Spike in AWS Security Hub Alerts for User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for a spike in number of of AWS security Hub alerts for an AWS IAM User in 4 hours intervals.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your Security Hub inputs. The threshold_value should be tuned to your environment and schedule these searches according to the bucket span interval.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = None
providing_technologies = null

[savedsearch://ESCU - Detect Spike in blocked Outbound Traffic from your AWS - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search will detect spike in blocked outbound network connections originating from within your AWS environment.  It will also update the cache file that factors in the latest data.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your VPC Flow logs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the number of data points required to meet the definition of "spike." The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike. This search works best when you run the "Baseline of Blocked Outbound Connection" support search once to create a history of previously seen blocked outbound connections.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = The false-positive rate may vary based on the values of`dataPointThreshold` and `deviationThreshold`. Additionally, false positives may result when AWS administrators roll out policies enforcing network blocks, causing sudden increases in the number of blocked outbound connections.
providing_technologies = null

[savedsearch://ESCU - Detect Spike in S3 Bucket deletion - Rule]
type = detection
asset_type = S3 Bucket
confidence = medium
explanation = This search detects users creating spikes in API activity related to deletion of S3 buckets in your AWS environment. It will also update the cache file that factors in the latest data.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike. This search works best when you run the "Baseline of S3 Bucket deletion activity by ARN" support search once to create a baseline of previously seen S3 bucket-deletion activity.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1530"], "nist": ["DE.AE"]}
known_false_positives = Based on the values of`dataPointThreshold` and `deviationThreshold`, the false positive rate may vary. Please modify this according the your environment.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - GCP Authentication Failed During MFA Challenge - Rule]
type = detection
asset_type = Google Cloud Platform tenant
confidence = medium
explanation = The following analytic identifies an authentication attempt event against a Google Cloud Platform tenant that fails during the Multi Factor Authentication challenge. This behavior may represent an adversary trying to authenticate with compromised credentials for an account that has multi-factor authentication enabled. 
how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the User log events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004", "T1621"], "nist": ["DE.CM"]}
known_false_positives = Legitimate users may miss to reply the MFA challenge within the time window or deny it by mistake.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Detect gcploit framework - Rule]
type = detection
asset_type = GCP Account
confidence = medium
explanation = This search provides detection of GCPloit exploitation framework. This framework can be used to escalate privileges and move laterally from compromised high privilege accounts.
how_to_implement = You must install splunk GCP add-on. This search works with gcp:pubsub:message logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.CM"]}
known_false_positives = Payload.request.function.timeout value can possibly be match with other functions or requests however the source user and target request account may indicate an attempt to move laterally accross acounts or projects
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Kubernetes cluster pod scan detection - Rule]
type = detection
asset_type = GCP Kubernetes cluster
confidence = medium
explanation = This search provides information of unauthenticated requests via user agent, and authentication data against Kubernetes cluster's pods
how_to_implement = You must install the GCP App for Splunk (version 2.0.0 or later), then configure stackdriver and set a Pub/Sub subscription to be imported to Splunk.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]}
known_false_positives = Not all unauthenticated requests are malicious, but frequency, User Agent, source IPs and pods  will provide context.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Multi-Factor Authentication Disabled - Rule]
type = detection
asset_type = GCP
confidence = medium
explanation = The following analytic identifies an attempt to disable multi-factor authentication for a GCP user. An adversary who has obtained access to an GCP tenant may disable multi-factor authentication as a way to plant a backdoor and maintain persistence using a valid account. This way the attackers can keep persistance in the environment without adding new users.
how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the Admin log events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1556", "T1556.006"], "nist": ["DE.CM"]}
known_false_positives = Legitimate use case may require for users to disable MFA. Filter as needed.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Multiple Failed MFA Requests For User - Rule]
type = detection
asset_type = Google Cloud Platform tenant
confidence = medium
explanation = The following analytic identifies multiple failed multi-factor authentication requests for a single user within a Google Cloud Platform tenant. Specifically, the analytic triggers when 10 or more MFA user prompts fail within 5 minutes. Google CLoud tenants can be very different depending on the organization, Security teams should test this detection and customize these arbitrary thresholds. The detected behavior may represent an adversary who has obtained legitimate credentials for a user and continuously repeats login attempts in order to bombard users with MFA push notifications, SMS messages, and phone calls potentially resulting in the user finally accepting the authentication request. Threat actors like the Lapsus team and APT29 have leveraged this technique to bypass multi-factor authentication controls as reported by Mandiant and others.
how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `mfa_prompts` threshold values according to your environment. Specifically, this analytic leverages the User log events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1621", "T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Multiple Users Failing To Authenticate From Ip - Rule]
type = detection
asset_type = Google Cloud Platform tenant
confidence = medium
explanation = The following analytic identifies one source Ip failing to authenticate into the Google Workspace user accounts with more than 20 unique valid users within 5 minutes. These user accounts may have other privileges with respect to access to other sensitive resources in the Google Cloud Platform. This behavior could represent an adversary performing a Password Spraying attack against an Google Workspace environment to obtain initial access or elevate privileges.
how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = No known false postives for this detection. Please review this alert.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Successful Single-Factor Authentication - Rule]
type = detection
asset_type = Google Cloud Platform tenant
confidence = medium
explanation = The following analytic identifies a successful authentication event against Google Cloud Platform for an account without Multi-Factor Authentication enabled. This could be evidence of a missconfiguration, a policy violation or an account take over attempt that should be investigated
how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. Specifically, this analytic leverages the User log events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1586", "T1586.003", "T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = Although not recommended, certain users may be required without multi-factor authentication. Filter as needed
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Unusual Number of Failed Authentications From Ip - Rule]
type = detection
asset_type = Google Cloud Platform tenant
confidence = medium
explanation = The following analytic identifies one source IP failing to authenticate into the Google Workspace with multiple valid users. This behavior could represent an adversary performing a Password Spraying attack against a Google Workspace enviroment to obtain initial access or elevate privileges. The detection calculates the standard deviation for source IP and leverages the 3-sigma statistical rule to identify an unusual number of failed authentication attempts. To customize this analytic, users can try different combinations of the bucket span time and the calculation of the upperBound field. This logic can be used for real time security monitoring as well as threat hunting exercises.  While looking for anomalies using statistical methods like the standard deviation can have benefits, we also recommend using threshold-based detections to complement coverage. A similar analytic following the threshold model is `GCP Multiple Users Failing To Authenticate From Ip`
how_to_implement = You must install the latest version of Splunk Add-on for Google Workspace from Splunkbase (https://splunkbase.splunk.com/app/5556) which allows Splunk administrators to collect Google Workspace event data in Splunk using Google Workspace APIs. We would also recommend tuning the detection by adjusting the window `span` and `unique_accounts` threshold values according to your environment. Specifically, this analytic leverages the User log events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = No known false positives for this detection. Please review this alert
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Gdrive suspicious file sharing - Rule]
type = detection
asset_type = GDrive
confidence = medium
explanation = This search can help the detection of compromised accounts or internal users sharing potentially malicious/classified documents with users outside your organization via GSuite file sharing .
how_to_implement = Need to implement Gsuite logging targeting Google suite drive activity. In order for the search to work for your environment please update `yourdomain.com` value in the query with the domain relavant for your organization.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = This is an anomaly search, you must specify your domain in the parameters so it either filters outside domains or focus on internal domains. This search may also help investigate compromise of accounts. By looking at for example source ip addresses, document titles and abnormal number of shares and shared target users.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GitHub Actions Disable Security Workflow - Rule]
type = detection
asset_type = GitHub
confidence = medium
explanation = This search detects a disabled security workflow in GitHub Actions. An attacker can disable a security workflow in GitHub actions to hide malicious code in it.
how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs. Sometimes GitHub logs are truncated, make sure to disable it in props.conf. Replace *security-testing* with the name of your security testing workflow in GitHub Actions.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.002", "T1195"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Github Commit Changes In Master - Rule]
type = detection
asset_type = GitHub
confidence = medium
explanation = This search is to detect a pushed or commit to master or main branch. This is to avoid unwanted modification to master without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch
how_to_implement = To successfully implement this search, you need to be ingesting logs related to github logs having the fork, commit, push metadata that can be use to monitor the changes in a github project.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"]}
known_false_positives = admin can do changes directly to master branch
providing_technologies = null

[savedsearch://ESCU - Github Commit In Develop - Rule]
type = detection
asset_type = GitHub
confidence = medium
explanation = This search is to detect a pushed or commit to develop branch. This is to avoid unwanted modification to develop without a review to the changes. Ideally in terms of devsecops the changes made in a branch and do a PR for review. of course in some cases admin of the project may did a changes directly to master branch
how_to_implement = To successfully implement this search, you need to be ingesting logs related to github logs having the fork, commit, push metadata that can be use to monitor the changes in a github project.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1199"], "nist": ["DE.AE"]}
known_false_positives = admin can do changes directly to develop branch
providing_technologies = null

[savedsearch://ESCU - GitHub Dependabot Alert - Rule]
type = detection
asset_type = GitHub
confidence = medium
explanation = The following analytic is made by first searching for logs that contain the action "create" and renames certain fields for easier analysis. Then, this analytic uses the "stats" command to calculate the first and last occurrence of the alert based on the timestamp. The fields included in the output are the action, affected package name, affected range, created date, external identifier, external reference, fixed version, severity, repository, repository URL, and user. The "phase" field is set to "code" to indicate that the alert pertains to code-related issues. The detection is important because dependabot Alerts can indicate vulnerabilities in the codebase that can be exploited by attackers. Detecting and investigating these alerts can help a SOC to proactively address security risks and prevent potential breaches or unauthorized access to sensitive information. False positives might occur since there are legitimate actions that trigger the "create" action or if other factors exist that can generate similar log entries. Next steps include reviewing the details of the alert, such as the affected package, severity, and fixed version to determine the appropriate response and mitigation steps.
how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - GitHub Pull Request from Unknown User - Rule]
type = detection
asset_type = GitHub
confidence = medium
explanation = The following analytic detects pull requests from unknown users on GitHub. The detection is made by using a Splunk query to search for pull requests in the `check_suite.pull_requests` field where the `id` is not specified. Next, the analytic retrieves information such as the author's name, the repository's full name, the head reference of the pull request, and the commit message from the `check_suite.head_commit` field. The analytic also includes a step to exclude known users by using the `github_known_users` lookup table, which helps to filter out pull requests from known users and focus on the pull requests from unknown users. The detection is important because it locates potential malicious activity or unauthorized access since unknown users can introduce malicious code or gain unauthorized access to repositories leading to unauthorized code changes, data breaches, or other security incidents. Next steps include reviewing the author's name, the repository involved, the head reference of the pull request, and the commit message upon triage of a potential pull request from an unknown user. You must also analyze any relevant on-disk artifacts and investigate any concurrent processes to determine the source and intent of the pull request."
how_to_implement = You must index GitHub logs. You can follow the url in reference to onboard GitHub logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.001", "T1195"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Gsuite Drive Share In External Email - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This search is to detect suspicious google drive or google docs files shared outside or externally. This behavior might be a good hunting query to monitor exfitration of data made by an attacker or insider to a targetted machine.
how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. In order for the search to work for your environment, please edit the query to use your company specific email domain instead of `internal_test_email.com`.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567.002", "T1567"], "nist": ["DE.AE"]}
known_false_positives = network admin or normal user may share files to customer and external team.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GSuite Email Suspicious Attachment - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This search is to detect a suspicious attachment file extension in Gsuite email that may related to spear phishing attack. This file type is commonly used by malware to lure user to click on it to execute malicious code to compromised targetted machine. But this search can also catch some normal files related to this file type that maybe send by employee or network admin.
how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = network admin and normal user may send this file attachment as part of their day to day work. having a good protocol in attaching this file type to an e-mail may reduce the risk of having a spear phishing attack.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Gsuite Email Suspicious Subject With Attachment - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This search is to detect a gsuite email contains suspicious subject having known file type used in spear phishing. This technique is a common and effective entry vector of attacker to compromise a network by luring the user to click or execute the suspicious attachment send from external email account because of the effective social engineering of subject related to delivery, bank and so on. On the other hand this detection may catch a normal email traffic related to legitimate transaction so better to check the email sender, spelling and etc. avoid click link or opening the attachment if you are not expecting this type of e-mail.
how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = normal user or normal transaction may contain the subject and file type attachment that this detection try to search.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Gsuite Email With Known Abuse Web Service Link - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This analytics is to detect a gmail containing a link that are known to be abused by malware or attacker like pastebin, telegram and discord to deliver malicious payload. This event can encounter some normal email traffic within organization and external email that normally using this application and services.
how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = normal email contains this link that are known application within the organization or network can be catched by this detection.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Gsuite Outbound Email With Attachment To External Domain - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This search is to detect a suspicious outbound e-mail from internal email to external email domain. This can be a good hunting query to monitor insider or outbound email traffic for not common domain e-mail. The idea is to parse the domain of destination email check if there is a minimum outbound traffic < 20 with attachment.
how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]}
known_false_positives = network admin and normal user may send this file attachment as part of their day to day work. having a good protocol in attaching this file type to an e-mail may reduce the risk of having a spear phishing attack.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Gsuite suspicious calendar invite - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This search can help the detection of compromised accounts or internal users sending suspcious calendar invites via GSuite calendar. These invites may contain malicious links or attachments.
how_to_implement = In order to successfully implement this search, you need to be ingesting logs related to gsuite (gsuite:calendar:json) having the file sharing metadata like file type, source owner, destination target user, description, etc. This search can also be made more specific by selecting specific emails, subdomains timeframe, organizational units, targeted user, etc. In order for the search to work for your environment please update `yourdomain.com` value in the query with the domain relavant for your organization.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = This search will also produce normal activity statistics. Fields such as email, ip address, name, parameters.organizer_calendar_id, parameters.target_calendar_id and parameters.event_title may give away phishing intent.For more specific results use email parameter.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Gsuite Suspicious Shared File Name - Rule]
type = detection
asset_type = GSuite
confidence = medium
explanation = This search is to detect a shared file in google drive with suspicious file name that are commonly used by spear phishing campaign. This technique is very popular to lure the user by running a malicious document or click a malicious link within the shared file that will redirected to malicious website. This detection can also catch some normal email communication between organization and its external customer.
how_to_implement = To successfully implement this search, you need to be ingesting logs related to gsuite having the file attachment metadata like file type, file extension, source email, destination email, num of attachment and etc. In order for the search to work for your environment, please edit the query to use your company specific email domain instead of `internal_test_email.com`.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = normal user or normal transaction may contain the subject and file type attachment that this detection try to search
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - High Number of Login Failures from a single source - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This analytic detects multiple failed login attempts in Office365 Azure Active Directory from a single source IP address. Specifically, it identifies scenarios where there are more than 10 unsuccessful login attempts within a short time frame. The detection leverages Office365 management activity logs, specifically the AzureActiveDirectoryStsLogon records from the AzureActiveDirectory workload. It aggregates these logs in 5-minute intervals to count the number of failed login attempts and associates them with the originating source IP address. Multiple failed login attempts from a single source can be indicative of brute-force attacks, password spraying, or other malicious authentication attempts. Identifying and responding to these patterns promptly can prevent unauthorized access and potential breaches. If this detection represents a true positive, an attacker might be attempting to gain unauthorized access to an Office365 account. Successful compromise could lead to unauthorized access to sensitive data, potential lateral movement within the organization, or further malicious activities using the compromised account.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. Adjust the threshold value to suit the specific environment, as environments with naturally higher login failures might generate false positives at a lower threshold.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.001", "T1110"], "nist": ["DE.AE"]}
known_false_positives = An Ip address with more than 10 failed authentication attempts in the span of 5 minutes may also be triggered by a broken application.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - Kubernetes Abuse of Secret by Unusual Location - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by country. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Abuse of Secret by Unusual User Agent - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user agent. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Abuse of Secret by Unusual User Group - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user group. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Abuse of Secret by Unusual User Name - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It identifies anomalies in access patterns by segmenting and analyzing the source of requests by user name. Kubernetes Secrets, which store sensitive information like passwords, OAuth tokens, and SSH keys, are critical assets, and their misuse can lead to significant security breaches. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to exfiltrate or misuse these secrets. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.007"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Access Scanning - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects potential scanning activities within a Kubernetes environment. It identifies unauthorized access attempts, probing of public APIs, or attempts to exploit known vulnerabilities. The analytic detects this behavior by monitoring Kubernetes audit logs for patterns indicative of scanning, such as repeated failed access attempts or unusual API requests. This behavior is worth identifying for a SOC as it could indicate an attackers preliminary step in an attack, aiming to gather information about the system to find potential vulnerabilities. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Anomalous Inbound Network Activity from Process - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This detection detects inbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly.This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for destination (receiving) workload process pairs over the last 1 hour, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high inbound network activity. Anomalies in inbound network traffic may suggest that the container is receiving unexpected or unauthorized data, potentially indicative of a breach, a vulnerability exploitation attempt, an attempt to overload the service, or propagation of malware. Successful compromise of a containerised application resulting in the ability to upload data, can result in installation of command and control software or other malware, data integrity damage, container escape, and further compromise of the environment. Additionally this kind of activity may result in resource contention, performance degradation and disruption to the normal operation of the environment.
how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head.  Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default:\
* Name sim_npm_metrics_to_metrics_index \
* Org ID <Your O11y Cloud Org Id> \
* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \
* Metric Resolution 10000
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Anomalous Inbound Outbound Network IO - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic identifies high Inbound or Outbound Network IO anomalies in a Kubernetes container. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, service disruptions, or unauthorized data transfers. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, financial losses, and reputational damage.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Anomalous Inbound to Outbound Network IO Ratio - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic identifies changes in network communication behavior in a Kubernetes container by examining inbound to outbound network IO ratios. It uses process metrics from an OTEL collector and Kubelet Stats Receiver, and data from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. A lookup table containing average and standard deviation for network IO is used to evaluate anomalies for each container. An event is generated if the anomaly persists over a 1 hour period. These anomalies may indicate security threats such as data exfiltration, command and control communication, or compromised container behavior. They can compromise the confidentiality, availability, and integrity of applications and data, necessitating rapid detection and response. Anomalous network utilization may suggest a compromised container, potentially leading to data breaches, service outages, and unauthorized access within the Kubernetes cluster.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Anomalous Outbound Network Activity from Process - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This detection detects outbound network traffic volume anomalies from processes running within containerised workloads. Anomalies are provided with context identifying the Kubernetes cluster, the workload name, and the type of anomaly. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics for source (transmitting) workload process pairs over the last 1 hout, with the average of those metrics for those pairs over the last 30 days in order to detect any anonymously high outbound network activity. Anonymously high outbound network traffic from a process running in a container is a potential indication of data exfiltration, or an indication that the process has been modified. Anomalously high outbound network activity from a process running within a container suggests the potential compromise, which may lead to unauthorized data exfiltration, communication with malicious entities, or the propagation of malware to external systems. The compromised container could also serve as a pivot point for further attacks within the containerized environment.
how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head.  Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default:\
* Name sim_npm_metrics_to_metrics_index \
* Org ID <Your O11y Cloud Org Id> \
* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \
* Metric Resolution 10000
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Anomalous Traffic on Network Edge - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This detection detects network traffic volume anomalies between workloads in a microservices hosted application, or between a workload and the outside world if the workload is shown as (unknown). This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on (https://splunkbase.splunk.com/app/5247). This detection compares the tcp.bytes, tcp.new_sockets, tcp.packets, udp.bytes, udp.packets metrics between workloads over the last 1 hour, with the average of those metrics over the last 30 days in order to detect any anonymously high inbound or outbound network activity. Unexpected spikes in network traffic may signify unauthorized data transfers, or abnormal behavior within the microservices ecosystem. Such activity might signify data exfiltration, unauthorized lateral movement, within the microservices environment. If a bad actor is responsible for this traffic they could compromise additional services or extract sensitive data, potentially leading to data breaches.
how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head.  Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default:\
* Name sim_npm_metrics_to_metrics_index \
* Org ID <Your O11y Cloud Org Id> \
* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \
* Metric Resolution 10000
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes AWS detect suspicious kubectl calls - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects anonymous and unauthenticated requests to a Kubernetes cluster. It identifies this behavior by monitoring for API calls from users who have not provided any token or password in their request. This is a significant behavior to identify for a SOC as it indicates a severe misconfiguration that allows unfettered access to a cluster with no traceability to a user or service. The impact of such an attack could be substantial, potentially granting an attacker access to sensitive data or control over the cluster. This detection rule is crucial for maintaining the security and integrity of your Kubernetes infrastructure.
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Kubectl calls are not malicious by nature. However source IP, verb and Object can reveal potential malicious activity, specially anonymous suspicious IPs and sensitive objects such as configmaps or secrets
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Create or Update Privileged Pod - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects the creation of privileged pods in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation of pods with root privileges. This behavior is worth identifying for a SOC as it could potentially allow an attacker to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Cron Job Creation - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects the creation of a Kubernetes cron job, a task scheduled to run automatically at specified intervals. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a cron job. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute malicious tasks repeatedly and automatically, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.007"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes DaemonSet Deployed - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. A DaemonSet ensures the presence of a specific pod on every node in the cluster, making it an ideal avenue for persistent access. This behavior is identified by monitoring Kubernetes Audit logs for the creation of a DaemonSet. The identified behavior is worth noting for a SOC as it could potentially allow an attacker to maintain persistent access to the Kubernetes infrastructure. The impact of such an attack could be severe, leading to persistent attacks, service disruptions, or unauthorized access to sensitive information.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Falco Shell Spawned - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects instances where a shell is spawned within a Kubernetes container, a behavior often indicative of an attacker gaining unauthorized access. Leveraging Falco, a cloud-native runtime security tool, this analytic monitors system calls within the Kubernetes environment, flagging when a shell is spawned in a container. This behavior is worth identifying for a SOC as it could potentially allow an attacker to execute arbitrary commands, manipulate container processes, or escalate privileges, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information.
how_to_implement = The detection is based on data that originates from Falco, a cloud native runtime security tool. Falco is designed to detect anomalous activity in your applications and is a crucial component of this detection rule. To implement this detection rule, you need to install and configure Falco in your Kubernetes environment. Once Falco is set up, it will monitor the system calls in your Kubernetes infrastructure and generate logs for any suspicious activity. These logs are then ingested by Splunk for analysis. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes newly seen TCP edge - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic detects TCP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk.
how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head.  Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default:\
* Name sim_npm_metrics_to_metrics_index \
* Org ID <Your O11y Cloud Org Id> \
* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \
* Metric Resolution 10000
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes newly seen UDP edge - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic detects UDP communication between a newly seen source and destination workload pair. This is done to identify changes in network behavior between workloads in a kubernetes cluster. This detection leverages Network performance Monitoring metrics harvested using an OTEL collector, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares network activity between workloads over the last 1 hour, with those over the last 30 days in order to detect newly seen inter workload communication. Newly seen network connections in a microservices based app indicate a change in behavior which could indicate potential security threats or anomalies. Distributed applications typically have common established network connection topologies, and new connections are often either an indication of a change in the application or an active threat. Unauthorized connections may enable the attacker to infiltrate the applications ecosystem, potentially leading to data breaches, manipulation of sensitive information, or disruption of critical services. Bad actors may exploit these connections to gain access, escalate privileges, move laterally within the microservices, or introduce malicious code or payloads, putting the applications integrity, availability, and confidentiality at risk.
how_to_implement = To gather NPM metrics the Open Telemetry to the Kubernetes Cluster and enable Network Performance Monitoring according to instructions found in Splunk Docs https://docs.splunk.com/observability/en/infrastructure/network-explorer/network-explorer-setup.html#network-explorer-setup In order to access those metrics from within Splunk Enterprise and ES, the Splunk Infrastructure Monitoring add-on must be installed and configured on a Splunk Search Head.  Once installed, first configure the add-on with your O11y Cloud Org ID and Access Token. Lastly set up the add-on to ingest metrics from O11y cloud using the following settings, and any other settings left at default:\
* Name sim_npm_metrics_to_metrics_index \
* Org ID <Your O11y Cloud Org Id> \
* Signal Flow Program data('tcp.packets').publish(label='A'); data('tcp.bytes').publish(label='B'); data('tcp.new_sockets').publish(label='C'); data('udp.packets').publish(label='D'); data('udp.bytes').publish(label='E') \
* Metric Resolution 10000
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Nginx Ingress LFI - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This search uses the Kubernetes logs from a nginx ingress controller to detect local file inclusion attacks.
how_to_implement = You must ingest Kubernetes logs through Splunk Connect for Kubernetes.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1212"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Nginx Ingress RFI - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This search uses the Kubernetes logs from a nginx ingress controller to detect remote file inclusion attacks.
how_to_implement = You must ingest Kubernetes logs through Splunk Connect for Kubernetes.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1212"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Node Port Creation - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects the creation of a Kubernetes node port service, an action that exposes a service to the external network. It identifies this behavior by monitoring Kubernetes Audit logs for creation of a Node Port service. This behavior is worth identifying for a SOC as it could potentially allow an attacker to access internal services, posing a significant threat to the integrity and security of the Kubernetes infrastructure. The impact of such an attack could be severe, leading to data breaches, service disruptions, or unauthorized access to sensitive information.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Pod Created in Default Namespace - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects the creation of pods in the default, kube-system, or kube-public namespaces. It identifies this behavior by monitoring Kubernetes audit logs for pod creation events in these namespaces. This behavior is worth identifying for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Only administrators should typically create pods in the kube-system namespace, and the default and kube-public namespaces should not be used in production. The impact of the attack could be significant, as it may indicate a successful cluster breach and ongoing malicious activity.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Pod With Host Network Attachment - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects the creation of a pod with host network attachment in Kubernetes. It identifies this behavior by monitoring Kubernetes Audit logs for the creation or update of pods with host network configuration. This behavior is worth identifying for a SOC as it could potentially allow an attacker to listen to all network traffic on the node and other compute on the network namespace, capturing secrets passed in arguments or connections to escalate their privileges. The impact of such an attack could be severe, leading to unauthorized access to sensitive information, data breaches, and service disruptions.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Previously Unseen Container Image Name - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic identifies containerised workloads that have been created using a previously unseen image. This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected. When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Previously Unseen Process - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic detects newly seen process within the Kubernetes scope on a master or worker node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour. The specific metric used by this detection is process.memory.utilization. Newly seen processes on a Kubernetes worker node are concerning as they may represent security risks and anomalies that could be related to unauthorized activity. New processes may be introduced  in an attempt to compromise the node or gain control of the Kubernetes cluster. By detecting these processes, they can be investigated, and correlated with other anomalous activity for that host. Newly seen processes may be part of an attacker's strategy to compromise the node, gain unauthorized access, and subsequently extend their control to the entire Kubernetes cluster. These processes could facilitate activities such as data exfiltration, privilege escalation, denial-of-service attacks, or the introduction of malware and backdoors, putting sensitive data, applications, and the entire infrastructure at risk. The consequences may include data breaches, service disruptions, financial losses, and reputational damage, underscoring the need to identify anomalous process and associate them with any concurrent risk activity.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Process Running From New Path - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic detects processes running within the same scope as Kubernetes that have been run from a newly seen path. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiever, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection compares the processes seen for each node over the previous 1 hour with those over the previous 30 days up until the previous 1 hour, and alerts if the path for that process was not seen over the previous 30 days. The specific metric used by this detection is process.memory.utilization. Processes running from a newly seen path can signify potential security risks and anomalies. A process executing from an unfamiliar file path may indicate unauthorized changes to the file system, a compromised node, or the introduction of malicious software. If the presence of a process running from a newly seen file path on a Kubernetes node indicates malicious activity, the security implications could be severe. It suggests that an attacker has potentially compromised the node, allowing them to execute unauthorized processes and potentially gain control over critical resources. This could lead to further exploitation, data exfiltration, privilege escalation, or the introduction of malware and backdoors within the Kubernetes cluster.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Process with Anomalous Resource Utilisation - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic identifies high resource utilization anomalies in Kubernetes processes. It uses process metrics from an OTEL collector and hostmetrics receiver, fetched from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The detection uses a lookup table with average and standard deviation values for various process metrics to identify anomalies. High resource utilization can indicate security threats or operational issues, such as cryptojacking, unauthorized data exfiltration, or compromised containers. These anomalies can disrupt services, exhaust resources, increase costs, and allow attackers to evade detection or maintain access.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Process with Resource Ratio Anomalies - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic detects anomalously changes in the ratio between specific process resources on a Kubernetes node, based on the past behavior for each process running in the Kubernetes scope on that node. This detection leverages process metrics harvested using an OTEL collector and hostmetrics receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection also leverages a lookup table that contains average and standard deviation for the cpu:disk operations, cpu:mem, cpu:thread count, disk operations:thread count, and mem:disk operations ratios. This is used to indicate an anomalous change in resource ratios that indicate the workload has changed behavior irrespective of load. Changes in the relationship between utilization of different resources can indicate a change in behavior of the monitored process, which can indicate a potentially compromised application. Deviations in resource ratios, such as memory-to-CPU or CPU-to-disk utilization, may signify compromised processes, malicious activity, or misconfigurations that could pose risks. A change in process behavior could signify a potential security breach within the Kubernetes environment, where an attacker may have compromised a process either on the node or running within a container.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Scanner Image Pulling - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This search uses the Kubernetes logs from Splunk Connect from Kubernetes to detect Kubernetes Security Scanner.
how_to_implement = You must ingest Kubernetes logs through Splunk Connect for Kubernetes.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Scanning by Unauthenticated IP Address - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This detection rule is designed to identify potential scanning activities within a Kubernetes environment. Scanning is a common preliminary step in an attack, where the attacker tries to gather information about the system to find potential vulnerabilities. In the context of Kubernetes, scanning could involve activities like unauthorized access attempts, probing public APIs, or trying to exploit known vulnerabilities. This rule triggers an alert when such suspicious activities are detected, helping to ensure the security of your Kubernetes infrastructure.
how_to_implement = You must ingest Kubernetes audit logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1046"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Shell Running on Worker Node - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic identifies shell activity within the Kubernetes privilege scope on a worker node, returning a list of shell processes regardless of CPU resource consumption. It uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. Metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized or suspicious activity, posing a security threat. Shell access to worker nodes can provide attackers an entry point to compromise the node and the entire Kubernetes cluster. Monitoring and detecting shell processes is crucial for anomaly identification, security policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node can severely compromise the cluster's security and integrity. Such access can lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. It may also enable attackers to manipulate configurations, deploy malicious containers, and execute arbitrary code, posing a severe risk to the confidentiality, availability, and integrity of applications and sensitive data.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Shell Running on Worker Node with CPU Activity - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = This analytic identifies shell activity within the Kubernetes privilege scope on a worker node. It returns shell processes only if they're consuming CPU resources. The detection uses process metrics from an OTEL collector hostmetrics receiver, pulled from Splunk Observability cloud via the Splunk Infrastructure Monitoring Add-on. The metrics used are process.cpu.utilization and process.memory.utilization. Shell processes can indicate unauthorized activity, posing a security threat. Attackers could compromise the node and the entire Kubernetes cluster via shell access to worker nodes. Monitoring shell processes is crucial for anomaly detection, policy enforcement, and breach mitigation. Unauthorized shell processes on a Kubernetes worker node could severely impact the cluster's security and integrity. Attackers could gain full control over the host's resources and file system, compromising all hosted workloads and data. This access could lead to data theft, service disruption, privilege escalation, lateral movement, and further attacks within the cluster. Attackers could also manipulate configurations, deploy malicious containers, and execute arbitrary code, severely risking the confidentiality, availability, and integrity of applications and sensitive data. A rapid and comprehensive incident response is required to mitigate and recover from such a breach.
how_to_implement = To implement this detection, follow these steps: \
* Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
* Enable the hostmetrics/process receiver in the OTEL configuration.\
* Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
* Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
* Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
* Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
* In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
* Set the Signal Flow Program to the following: data('process.threads').publish(label='A'); data('process.cpu.utilization').publish(label='B'); data('process.cpu.time').publish(label='C'); data('process.disk.io').publish(label='D'); data('process.memory.usage').publish(label='E'); data('process.memory.virtual').publish(label='F'); data('process.memory.utilization').publish(label='G'); data('process.cpu.utilization').publish(label='H'); data('process.disk.operations').publish(label='I'); data('process.handles').publish(label='J'); data('process.threads').publish(label='K')\
* Set the Metric Resolution to 10000.\
* Leave all other settings at their default values.\
* Run the Search Baseline Of Kubernetes Container Network IO Ratio 
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Suspicious Image Pulling - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects instances of suspicious image pulling in Kubernetes. It identifies this behavior by monitoring Kubernetes audit logs for image pull requests that do not match a predefined list of allowed images. This behavior is worth identifying for a SOC as it could indicate an attacker attempting to deploy malicious software or infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Unauthorized Access - Rule]
type = detection
asset_type = Kubernetes
confidence = medium
explanation = The following analytic detects unauthorized access to Kubernetes by monitoring Kubernetes audit logs. It identifies anomalies in access patterns by segmenting and analyzing the source of requests. Unauthorized access is worth identifying for a SOC as it could indicate an attacker attempting to infiltrate the system. The impact of such an attack could be severe, potentially leading to unauthorized access to sensitive systems or data.
how_to_implement = The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - O365 Add App Role Assignment Grant User - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This search is designed to detect the creation of a new Federation setting by alerting on a specific event associated with its creation. By monitoring for this event, the search can identify any instances where a Federation setting is being created within the system. This can help in detecting and monitoring any unauthorized or suspicious changes to the Federation settings, providing an additional layer of security for your environment.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]}
known_false_positives = The creation of a new Federation is not necessarily malicious, however this events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Added Service Principal - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic detects addition of new service principal accounts added to O365 tenants. Attackers can abuse service principals in Office 365 (now known as Microsoft 365) to gain unauthorized access and perform malicious actions within an organization's environment. Service principals are essentially non-human accounts used by applications, services, or scripts to access resources and interact with APIs on behalf of the organization.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]}
known_false_positives = The creation of a new Federation is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a different cloud provider.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Admin Consent Bypassed by Service Principal - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This detection targets situations where a service principal in Office 365 Azure Active Directory assigns app roles without the standard admin consent, a potential security breach. Using o365_management_activity logs, it examines the 'Add app role assignment to service principal' operation, focusing on service principals and extracting details like role ID and description. This is critical for SOCs to detect potential bypassing of crucial administrative controls, which could lead to unauthorized access or privilege escalation. A true positive implies a service principal might be misusing automated processes to assign sensitive permissions.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Service Principals are sometimes configured to legitimately bypass the consent process for purposes of automation. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Advanced Audit Disabled - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic identifies instances where the O365 advanced audit is disabled for a specific user within the Office 365 tenant. It leverages O365 audit logs, specifically events related to audit license changes or modifications within the AzureActiveDirectory workloads. The O365 advanced audit provides granular logging and insights into user and administrator activities, making it a crucial tool for security monitoring and incident response. Disabling this audit for a user can blind security teams to potential malicious or unauthorized activities related to that user's mailbox or account. Attackers may disable these audits to obscure their actions and reduce the chances of detection. If an attacker successfully disables the O365 advanced audit for a user, they can operate within that user's mailbox or account with reduced risk of detection. This can lead to unauthorized data access, data exfiltration, account compromise, or other malicious activities without leaving a detailed audit trail.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.008"], "nist": ["DE.CM"]}
known_false_positives = Administrators might temporarily disable the advanced audit for troubleshooting, performance reasons, or other administrative tasks. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Application Registration Owner Added - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic identifies instances where a new owner is assigned to an application registration within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in owner assignments within the AzureActiveDirectory workload for application registrations. Assigning a new owner to an application registration can grant significant control over the application's configuration, permissions, and behavior. An unauthorized or inadvertent change in ownership can lead to misuse of the application, potentially affecting data access, user permissions, or the application's interactions within the tenant. Monitoring for such changes ensures that only legitimate and authorized personnel have control over application registrations. If an attacker successfully assigns themselves or a compromised account as an owner to an application registration, they can modify the application's settings, permissions, and behavior. This can lead to unauthorized data access, escalation of privileges, or the introduction of malicious behavior within the application's operations
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = Application owners may be added for legitimate reasons, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 ApplicationImpersonation Role Assigned - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic identifies the assignment of the ApplicationImpersonation role in Office 365, either to a user or an application. This analytic leverages the Office 365 Management Activity API, specifically monitoring for events related to role assignments and changes within the Azure Active Directory audit logs. The ApplicationImpersonation role allows a security principal to impersonate any user within the organization and perform actions on their behalf, such as accessing or modifying their mailbox. This role, if misused or granted inappropriately, can pose a significant security risk. Monitoring the assignment of this role is crucial as it can be an indicator of potential malicious activity or misconfigurations. If an attacker successfully assigns the ApplicationImpersonation role to a malicious user or application, they can gain the ability to impersonate any user within the organization. This can lead to unauthorized access to sensitive information, manipulation of mailbox data, and other malicious actions. The attacker can effectively masquerade as a legitimate user, making their actions harder to detect and potentially causing significant harm to the organization.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]}
known_false_positives = While infrequent, the ApplicationImpersonation role may be granted for leigimate reasons, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Block User Consent For Risky Apps Disabled - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This analytic detects when the "risk-based step-up consent" security setting in Microsoft 365 is disabled. This setting, when enabled, prevents regular users from granting consent to potentially malicious OAuth applications, requiring an administrative "step-up" for consent instead. Disabling this feature could expose the organization to OAuth phishing threats.The detection operates by monitoring Azure Active Directory logs for events where the "Update authorization policy" operation is performed. It specifically looks for changes to the "AllowUserConsentForRiskyApps" setting, identifying instances where this setting is switched to "true," effectively disabling the risk-based step-up consent. Monitoring for changes to critical security settings like the "risk-based step-up consent" is vital for maintaining the integrity of an organization's security posture. Disabling this feature can make the environment more susceptible to OAuth phishing attacks, where attackers trick users into granting permissions to malicious applications. Identifying when this setting is disabled can help blue teams to quickly respond, investigate, and potentially uncover targeted phishing campaigns against their users. If an attacker successfully disables the "risk-based step-up consent" and subsequently launches an OAuth phishing campaign, they could gain unauthorized access to user data and other sensitive information within the M365 environment. This could lead to data breaches, unauthorized access to emails, and potentially further compromise within the organization.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562"], "nist": ["DE.CM"]}
known_false_positives = Legitimate changes to the 'risk-based step-up consent' setting by administrators, perhaps as part of a policy update or security assessment, may trigger this alert, necessitating verification of the change's intent and authorization.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Bypass MFA via Trusted IP - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This analytic identifies instances where new IP addresses are added to the trusted IPs list in Office 365, potentially allowing users from these IPs to bypass Multi-Factor Authentication (MFA) during login. The detection leverages O365 audit logs, specifically focusing on events related to the modification of trusted IP settings. By monitoring these logs, the analytic captures and alerts on any addition of new trusted IPs. Adding trusted IPs to bypass MFA is a significant security concern. While there might be legitimate reasons to add trusted IPs, such as for a new office location, there's also a risk of attackers or malicious insiders using this to facilitate unauthorized access. Monitoring for changes to the trusted IP list helps ensure that any attempt to bypass MFA is legitimate and authorized. If the detection is a true positive, it suggests that users logging in from the newly added trusted IP can bypass MFA, potentially weakening the security posture of the organization. This could lead to unauthorized access, especially if the IP was added maliciously. Immediate investigation is required to validate the legitimacy of the IP addition and to assess potential security implications.
how_to_implement = You must install Splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Unless it is a special case, it is uncommon to continually update Trusted IPs to MFA configuration.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Compliance Content Search Exported - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection  targets activities where the results of a content search within the Office 365 Security and Compliance Center are exported, a crucial phase in the compliance and investigative workflows. By focusing on the SearchExported operation logged under the SecurityComplianceCenter workload in the o365_management_activity, this analytic flags instances that potentially move sensitive or critical organizational data outside its original storage locations.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]}
known_false_positives = Compliance content searche exports may be executed for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Compliance Content Search Started - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection will trigger when a content search is initiated within the Office 365 Security and Compliance Center, a critical component in the suite's governance, risk management, and compliance (GRC) capabilities. By monitoring the SearchCreated operation within the o365_management_activity logs, specifically under the SecurityComplianceCenter workload, this analytic flags the commencement of searches across the organization's data, including emails, documents, and more, that reside in ExchangeLocations.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]}
known_false_positives = Compliance content searches may be executed for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Concurrent Sessions From Different Ips - Rule]
type = detection
asset_type = O365
confidence = medium
explanation = The following analytic identies scenarios where the same user session is accessed from multiple IP addresses. This situation typically arises in an adversary-in-the-middle (AiTM) phishing attack, where attackers compromise user sessions. The detection method involves analyzing Azure Active Directory logs for 'UserLoggedIn' operations. It focuses on identifying sessions where the number of associated IP addresses exceeds one for the same SessionId. This pattern suggests potential unauthorized concurrent access, which is atypical under normal usage scenarios. If a true positive is identified, it implies that an adversary has gained unauthorized access to a user's Office 365 account. The ramifications of this can be significant, including data theft, account takeover, and launching of internal phishing campaigns.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1185"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Disable MFA - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This analytic identifies instances where Multi-Factor Authentication (MFA) is disabled for a user within the Office 365 environment. Disabling MFA removes a critical security layer, making accounts more vulnerable to unauthorized access. The detection leverages O365 audit logs, specifically focusing on events related to MFA settings. By monitoring these logs, the analytic captures and alerts on any actions that result in the deactivation or disabling of MFA for a user. MFA is a cornerstone of modern security practices, providing an additional layer of protection beyond just a password. Disabling MFA, especially without a valid reason, poses a significant security risk. Attackers, after gaining initial access to an account, might disable MFA to ensure easier re-entry and persistence. Monitoring for such changes is crucial to detect potential security breaches and to ensure that security best practices are consistently applied. If the detection is a true positive, it indicates that a user's account is now at increased risk of unauthorized access, as the added security layer of MFA has been removed. This could be a sign of an attacker trying to maintain persistence or an insider threat. Immediate investigation is required to validate the reason for disabling MFA, potentially re-enable it, and assess any other suspicious activities related to the affected account.
how_to_implement = You must install the Splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556"], "nist": ["DE.CM"]}
known_false_positives = Unless it is a special case, it is uncommon to disable MFA or Strong Authentication
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Elevated Mailbox Permission Assigned - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection triggers on the assignment of elevated mailbox permissions within an Office 365 environment, specifically through the Add-MailboxPermission operation, as logged under the Exchange workload in the o365_management_activity. It is meticulously designed to spotlight instances where critical permissions such as FullAccess, ChangePermission, or ChangeOwner are granted, marking significant alterations in mailbox access controls.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]}
known_false_positives = FullAccess mailbox delegation may be assigned for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Excessive Authentication Failures Alert - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This search detects when an excessive number of authentication failures occur this search also includes attempts against MFA prompt codes
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]}
known_false_positives = The threshold for alert is above 10 attempts and this should reduce the number of false positives.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Excessive SSO logon errors - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic detects accounts with high number of Single Sign ON (SSO) logon errors. Excessive logon errors may indicate attempts to bruteforce of password or single sign on token hijack or reuse.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556"], "nist": ["DE.AE"]}
known_false_positives = Logon errors may not be malicious in nature however it may indicate attempts to reuse a token or password obtained via credential access attack.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 File Permissioned Application Consent Granted by User - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This analytic identifies instances where a user in the Office 365 environment grants consent to an application that requests file permissions, specifically targeting OneDrive or SharePoint. Such permissions mean the application could potentially access, modify, or delete files stored within these services. The detection process leverages O365 audit logs, particularly focusing on events related to OAuth application consents. By examining these logs, the analytic is designed to capture and alert on any actions where users grant consent to applications requesting file-related permissions for OneDrive or SharePoint. The sensitivity of file permissions, especially in platforms as widely utilized as OneDrive and SharePoint, cannot be overstated. While many legitimate applications might require such permissions to operate, there's an inherent risk with malicious or overly permissive applications. Attackers could craft or exploit applications to gain file permissions, aiming to access, exfiltrate, or manipulate sensitive data housed in OneDrive or SharePoint. It's crucial for security operations centers to monitor these consents to ensure that only trustworthy applications gain access and that users aren't inadvertently granting permissions to potentially harmful applications. If this detection flags a true positive, it indicates that an application has been granted permissions that could allow it to interact with OneDrive or SharePoint files in potentially malicious ways. Such actions could lead to data breaches, data loss, or unauthorized data manipulation. Immediate investigation would be required to validate the application's legitimacy, understand the nature of its requested permissions, and assess the potential risks associated with the access it's been granted.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = OAuth applications that require file permissions may be legitimate, investigate and filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 FullAccessAsApp Permission Assigned - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic triggers on the assignment of the 'full_access_as_app' permission to an application registration in Office 365, specifically within Exchange Online. The 'full_access_as_app' permission, identified by its GUID 'dc890d15-9560-4a4c-9b7f-a736ec74ec40', allows an application extensive control over Office 365 operations, including access to all mailboxes and the ability to send mail as any user. The analytic focuses on the ResourceAppId '00000002-0000-0ff1-ce00-000000000000', pinpointing permissions granted to the Office 365 Exchange Online resource. By analyzing Office 365 management activity logs and filtering Azure Active Directory workload events, the query detects when this specific permission is assigned. Monitoring this assignment is vital due to the broad access it provides, which can lead to unauthorized data access or exfiltration if misused. A true positive detection requires immediate attention to prevent potential security risks like account compromise or data loss.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.002", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = The full_access_as_app API permission may be assigned to legitimate applications. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 High Number Of Failed Authentications for User - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = The following analytic identifies an O365 account that has experienced more than 20 failed authentication events within a span of 5 minutes. This could be indicative of an attacker attempting to brute force or guess the password for that particular user account. It leverages the O365 Unified Audit Logs, specifically the "UserLoginFailed" events. By monitoring the frequency and volume of these events for individual users, the analytic can flag accounts that exceed the set threshold of failed attempts within the defined timeframe. Multiple failed login attempts in a short period can be a strong indicator of malicious activity. While there could be benign reasons, such as a user forgetting their password, the rapid succession of failed attempts is often a sign of an attacker trying to gain unauthorized access. By detecting and alerting on this behavior, the SOC can quickly investigate and take appropriate action, potentially stopping an attack in its early stages. Given that environments differ across organizations, security teams should consider customizing the threshold of this detection to better suit their specific needs and risk profile. If an attacker successfully guesses or brute-forces a user's password after numerous attempts, they can gain unauthorized access to the O365 environment. This unauthorized access could allow them to view sensitive emails, documents, and other data.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.001"], "nist": ["DE.CM"]}
known_false_positives = Although unusual, users who have lost their passwords may trigger this detection. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 High Privilege Role Granted - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This analytic detects when high-privilege roles, specifically "Exchange Administrator", "SharePoint Administrator", or "Global Administrator", are granted within Office 365. By monitoring O365 audit logs for events where these administrative roles are assigned to any user or service account, the analytic provides insight into critical role changes. The assignment of these roles is of paramount importance to Security Operations Centers (SOCs) as they grant extensive permissions, allowing for broad access and control over critical organizational resources and data. An unexpected or unauthorized role assignment could indicate potential malicious activity, insider threats, or misconfigurations. If an attacker or unauthorized individual is granted one of these roles, the potential impact includes gaining significant control over O365 resources, accessing, modifying, or deleting critical data, making configuration changes, and potentially compromising the overall security and functionality of the O365 environment.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Privilege roles may be assigned for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Mail Permissioned Application Consent Granted by User - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic identifies instances where a user grants consent to an application that requests mail related permissions within the Office 365 environment. This could involve permissions to read, send, or manage mail settings. It leverages the O365 audit logs, specifically events related to application permissions and user consent actions. By filtering for mail-related permissions and user-granted consents, the analytic pinpoints potential security concerns. While many legitimate applications request mail permissions for valid reasons, malicious actors can exploit these permissions for data exfiltration, spear phishing, or other malicious activities. By monitoring for user-granted mail permissions, security teams can identify and review potentially risky consents, ensuring that only trusted applications have access to sensitive email data. If the detection is a true positive, it indicates that an application now has access to the users mail data as permitted. In the hands of a malicious actor, this could lead to unauthorized data access, email forwarding, or even the sending of malicious emails from the compromised account. Its crucial to validate the legitimacy of the application and the context of the consent to prevent potential data breaches or further malicious activities.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = OAuth applications that require mail permissions may be legitimate, investigate and filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Mailbox Email Forwarding Enabled - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection is designed to identify instances where email forwarding has been enabled on mailboxes within an Office 365 environment. By monitoring for the specific operation Set-Mailbox within the o365_management_activity logs, this analytic hones in on changes made to mailbox configurations that initiate the forwarding of emails. It specifically looks for the activation of ForwardingAddress or ForwardingSmtpAddress parameters, indicating that emails are being automatically sent to another email address from the user's mailbox.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]}
known_false_positives = Email forwarding may be configured for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Mailbox Folder Read Permission Assigned - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection is tailored to capture instances where read permissions are assigned to mailbox folders within an Office 365 environment, utilizing the operations ModifyFolderPermissions and AddFolderPermissions as captured in the o365_management_activity. Unlike other permission modifications, this detection excludes actions related to the Calendar, Contacts, and PersonMetadata objects, focusing on core mailbox folders.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]}
known_false_positives = Mailbox folder permissions may be configured for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Mailbox Folder Read Permission Granted - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection focuses on identifying changes in mailbox folder permissions within an Office 365 environment, specifically pinpointing instances where read permissions are granted. It monitors for two key operations Set-MailboxFolderPermission and Add-MailboxFolderPermission, as logged in the o365_management_activity. These operations are indicative of modifications or additions to the permissions of mailbox folders, potentially altering who can view or interact with the folder contents.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.002"], "nist": ["DE.CM"]}
known_false_positives = Mailbox folder permissions may be configured for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Mailbox Inbox Folder Shared with All Users - Rule]
type = detection
asset_type = Office 365 Tenant
confidence = medium
explanation = The following analytic identifies instances where the inbox folder of a mailbox in Office 365 is shared with all users within the tenant. Sharing the inbox folder with all users is an unusual and risky configuration. Attackers have been known to exploit this setting to surreptitiously read a target user's emails from another account. Such unauthorized access can lead to data breaches, leakage of confidential information, or further compromise based on the information gathered from the emails. Monitoring for this configuration change ensures that inadvertent or malicious sharing is promptly identified and addressed. If an attacker successfully configures the inbox to be shared with all users, they can access and read all emails in the affected mailbox from any account within the tenant. This can lead to data exfiltration, spear-phishing attacks based on the information in the emails, or further malicious activities using sensitive information gathered from the mailbox.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators might temporarily share a mailbox with all users for legitimate reasons, such as troubleshooting, migrations, or other administrative tasks. Some organizations use shared mailboxes for teams or departments where multiple users need access to the same mailbox. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Mailbox Read Access Granted to Application - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic identifies instances where the Mail.Read Graph API permissions are granted to an application registration within an Office 365 tenant. It leverages O365 audit logs, specifically events related to changes in application permissions within the AzureActiveDirectory workload. The Mail.Read permission allows applications to access and read all emails within a user's mailbox. Emails often contain sensitive or confidential information, and unauthorized access can lead to data breaches or leakage. Monitoring the assignment of this permission ensures that only legitimate applications have such access and that any inadvertent or malicious assignments are promptly identified. If an attacker successfully grants this permission to a malicious or compromised application, they can read all emails in the affected mailboxes. This can lead to data exfiltration, spear-phishing attacks, or further compromise based on the information gathered from the emails.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1114.002", "T1114", "T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = There are legitimate scenarios in wich an Application registrations requires Mailbox read access. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multi-Source Failed Authentications Spike - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This analytic detects potential distributed password spraying attacks within an Office 365 environment. It identifies a significant increase in failed authentication attempts characterized by diverse user-and-IP address combinations, originating from multiple source IP addresses, and utilizing various user agents. These patterns may indicate an adversary's attempt to circumvent security controls by employing a spectrum of IP addresses to test commonly used passwords against a wide range of user accounts. The detection examines UserLoginFailed events from O365 Management Activity logs, with a particular focus on events with ErrorNumber 50126, which indicates a failed authentication due to incorrect credentials. By aggregating data over a five-minute interval, the analytic calculates the distinct counts of user-and-IP combinations and unique users and source IPs. It then applies a set of thresholds to these metrics to identify abnormal activities that could suggest a coordinated attack. The predefined thresholds within the analytic (such as unique IPs, unique users, etc.) serve as initial benchmarks and should be tailored to align with the organization's typical user behavior and risk tolerance. Early detection of such distributed activities is crucial for security operations centers (SOCs) to intercept unauthorized access attempts, avert account takeovers, and reduce the risk of subsequent malevolent actions within the organization's systems. A true positive alert from this analytic would indicate an ongoing distributed password spraying campaign targeting the organization's Office 365 tenant. If such an attack is successful, it could lead to unauthorized access, especially to accounts with administrative privileges, resulting in data breaches, privilege escalation, persistent threats, and lateral movement within the organization's digital environment.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events. The thresholds set within the analytic (such as unique IPs, unique users, etc.) are initial guidelines and should be customized based on the organization's user behavior and risk profile. Security teams are encouraged to adjust these thresholds to optimize the balance between detecting genuine threats and minimizing false positives, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.AE"]}
known_false_positives = This detection may yield false positives in scenarios where legitimate bulk sign-in activities occur, such as during company-wide system updates or when users are accessing resources from varying locations in a short time frame, such as in the case of VPNs or cloud services that rotate IP addresses. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multiple AppIDs and UserAgents Authentication Spike - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This analytic is crafted to identify unusual and potentially malicious authentication activity within an O365 environment. It triggers when a single user account is involved in more than 8 authentication attempts, using 3 or more unique application IDs and more than 5 unique user agents within a short timeframe. This pattern is atypical for regular user behavior and may indicate an adversary's attempt to probe the environment, testing for multi-factor authentication requirements across different applications and platforms. The detection is based on analysis of O365 audit logs, specifically focusing on authentication events. It employs statistical thresholds to highlight instances where the volume of authentication attempts and the diversity of application IDs and user agents associated with a single user account exceed normal parameters. Identifying this behavior is crucial as it provides an early indication of potential account compromise. Adversaries, once in possession of user credentials, often conduct reconnaissance to understand the security controls in place, including multi-factor authentication configurations. Tools like Invoke-MFASweep are commonly used for this purpose, automating the process of testing different user agents and application IDs to bypass MFA. By detecting these initial probing attempts, security teams can swiftly respond, potentially stopping an attack in its early stages and preventing further unauthorized access. This proactive stance is vital for maintaining the integrity of the organization's security posture. If validated as a true positive, this detection points to a compromised account, signaling that an attacker is actively attempting to navigate security controls to maintain access and potentially escalate privileges. This could lead to further exploitation, lateral movement within the network, and eventual data exfiltration. Recognizing and responding to this early stage of an attack is vital for preventing substantial harm and safeguarding sensitive organizational data and systems.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Rapid authentication from the same user using more than 5 different user agents and 3 application IDs is highly unlikely under normal circumstances. However, there are potential scenarios that could lead to false positives.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multiple Failed MFA Requests For User - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This analytic identifies potential "MFA fatigue" attacks targeting Office 365 users. Specifically, it detects scenarios where a user experiences more than nine Multi-Factor Authentication (MFA) prompts within a 10-minute timeframe. Attackers may exploit MFA fatigue by repeatedly triggering MFA requests, hoping that the user, out of frustration or oversight, will approve a malicious authentication attempt. The detection leverages O365 management activity logs, focusing on Azure Active Directory events. It looks for the UserLoginFailed operation combined with a Success ResultStatus and an ErrorNumber of 500121, which indicates MFA prompts. By monitoring these specific events and conditions, the analytic captures and alerts on potential MFA fatigue scenarios. With MFA being a cornerstone of modern cybersecurity defenses, attackers are constantly seeking ways to bypass or exploit it. MFA fatigue is one such tactic, where attackers rely on user frustration or confusion caused by frequent MFA prompts. Detecting potential MFA fatigue scenarios allows security teams to proactively investigate and ensure that users aren't inadvertently granting access to malicious actors. If this detection flags a true positive, it suggests a potential attempt by an attacker to exploit MFA mechanisms to gain unauthorized access to an O365 account. Successful exploitation could lead to data breaches, unauthorized data access, or further compromise within the O365 environment. Immediate investigation and response would be crucial to safeguard the affected account and assess the full scope of the potential breach.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1621"], "nist": ["DE.CM"]}
known_false_positives = Multiple Failed MFA requests may also be a sign of authentication or application issues. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multiple Mailboxes Accessed via API - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic is designed to trigger when a high number of Office 365 Exchange mailboxes are accessed via API (Microsoft Graph API or Exchange Web Services) in a short time, hinting at possible unauthorized mass email access. It tracks 'MailItemsAccessed' operations in Exchange, using AppId and regex to identify API interactions. Crucial for SOC teams, this analytic focuses on spotting abnormal access patterns, often signaling data exfiltration or account compromise. Security teams should tailor the threshold  set here to flag over five unique mailboxes accessed within 10 minutes  to align with their environment's norms, ensuring effective detection of potential security incidents while maintaining operational efficiency.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may access multiple mailboxes via an API. You can filter by the ClientAppId or the CLientIpAddress fields.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multiple Service Principals Created by SP - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This detection aims to identify instances where a single service principal creates more than three unique OAuth applications within a 10-minute timeframe, using O365 logs from the Unified Audit Log. The focus is on tracking the 'Add service principal' operation within the Office 365 Azure Active Directory environment. The query effectively buckets events in 10-minute intervals, specifically scrutinizing the actions of service principals. By quantifying the number of distinct OAuth applications each service principal establishes, the analytic provides critical insights for SOC teams into potentially anomalous or malicious activities. These activities could include a compromised or malicious service principal being used to create multiple service principals, which might be indicative of an attempt to expand control or access within the network. Security teams are advised to adapt the threshold of three applications to align with their typical operational baseline
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]}
known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multiple Service Principals Created by User - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This detection is tailored to spot occurrences where a single user, rather than a service principal, creates more than three unique OAuth applications within a 10-minute window in the Office 365 environment. Utilizing O365 logs from the Unified Audit Log, it focuses on the 'Add service principal' operation in Azure Active Directory. The query segments events into 10-minute intervals, exclusively monitoring user activities. It calculates the number of distinct OAuth applications initiated by each user, providing SOC teams with essential data for identifying potential security threats. Such activity could suggest that a user account is either compromised or engaged in unauthorized activities, potentially setting the stage for broader network infiltration or privilege escalation. It's important for security teams to adjust the threshold of three applications to fit their operational context.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003"], "nist": ["DE.AE"]}
known_false_positives = Certain users or applications may create multiple service principals in a short period of time for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Multiple Users Failing To Authenticate From Ip - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This analytic identifies instances where multiple users (more than 10 unique accounts) have failed to authenticate from a single IP address within a short time span (5 minutes). Such a pattern can be indicative of malicious activities, such as brute-force attacks or password spraying attempts. The detection leverages O365 audit logs, specifically focusing on Azure Active Directory login failures (AzureActiveDirectoryStsLogon). By aggregating these failures based on the source IP address and time, the analytic captures patterns where multiple unique user accounts have authentication failures from the same IP within a 5-minute window. Multiple authentication failures from a single IP address targeting various accounts can be a strong indicator of an attacker trying to gain unauthorized access. It could represent a brute-force attack, password spraying, or other malicious login attempts. Identifying and responding to such patterns promptly is crucial to prevent potential account compromises and unauthorized access to organizational resources. If the detection is a true positive, it suggests that an external entity is actively trying to breach the security by targeting multiple user accounts. While the attempts have been unsuccessful (as indicated by the login failures), it's a clear sign of malicious intent. Immediate action is required to block or monitor the suspicious IP, investigate the nature of the attempts, and potentially notify affected users to take precautionary measures like password changes or enabling multi-factor authentication.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization", "Exploitation"], "mitre_attack": ["T1586", "T1586.003", "T1110", "T1110.003", "T1110.004"], "nist": ["DE.CM"]}
known_false_positives = A source Ip failing to authenticate with multiple users in a short period of time is not common legitimate behavior.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 New Email Forwarding Rule Created - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection is crafted to monitor and identify the creation of new email forwarding rules in an Office 365 environment. It specifically targets events logged under New-InboxRule and Set-InboxRule operations within o365_management_activity, indicating the establishment or modification of inbox rules that forward emails. The detection checks for the presence of parameters such as ForwardTo, ForwardAsAttachmentTo, and RedirectTo, which are key indicators of email forwarding behavior.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]}
known_false_positives = Users may create email forwarding rules for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 New Email Forwarding Rule Enabled - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = This detection aims to identify instances where new email forwarding rules are created through the UpdateInboxRules operation within an Office 365 environment. Despite the operation name suggesting an update, this specific scenario involves the addition of new rules that direct emails to external recipients, captured under the ForwardToRecipientsAction. The analytic examines the OperationProperties to extract and validate forwarding addresses, ensuring they adhere to the expected email format.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.003"], "nist": ["DE.CM"]}
known_false_positives = Users may create email forwarding rules for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 New Federated Domain Added - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic identifies the addition of a new federated domain in an organization's Office 365 environment. This behavior is detected by analyzing the Office 365 management activity logs using the Splunk query o365_management_activity, specifically filtering for the Workload=Exchange and Operation="Add-FederatedDomain" parameters. The addition of a new federated domain can be a significant security concern, as it might indicate unauthorized changes or potential compromises within the Office 365 setup. Attackers, upon gaining sufficient privileges, could add a federated domain to establish a backdoor, bypass security measures, or exfiltrate data. Such unauthorized changes can lead to data breaches, unauthorized access to sensitive data, and potential compromise of organizational infrastructure. When this analytic is triggered, immediate steps should include reviewing the details of the added federated domain, such as the organization name, originating server, user ID, and user key. Concurrent processes or other indicators of compromise should also be investigated to pinpoint the source of the potential breach.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.003", "T1136"], "nist": ["DE.CM"]}
known_false_positives = The creation of a new Federated domain is not necessarily malicious, however these events need to be followed closely, as it may indicate federated credential abuse or backdoor via federated identities at a similar or different cloud provider.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 New Forwarding Mailflow Rule Created - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic monitors for the creation of new mail flow rules in Office 365 that could potentially redirect or copy emails to unauthorized or external addresses. This analytic works by querying the Office 365 Management Activity logs for any operation tagged as "New-TransportRule". It specifically looks for parameters indicative of mail forwarding actions, such as "BlindCopyTo", "CopyTo", and "RedirectMessageTo". If any of these parameters are present, indicating that a forwarding rule has been set up, the detection then captures the details of this rule, including the user ID responsible for the creation, the name of the rule, the forwarding target, and the timestamps of the rule's creation and last modification.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"]}
known_false_positives = Forwarding mail flow rules may be created for legitimate reasons, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 New MFA Method Registered - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This analytic detects the registration of a new Multi-Factor Authentication (MFA) method associated with a user account within Office 365 by monitoring O365 audit logs and configurations. While adding a new MFA method can be a routine and legitimate action, it can also be indicative of an attacker's attempt to maintain persistence on a compromised account. By registering a new MFA method, attackers can potentially bypass existing security measures, allowing them to authenticate using stolen credentials without raising alarms. Monitoring for such changes is crucial, especially if the addition is not preceded by a user request or if it deviates from typical user behavior. If an attacker successfully registers a new MFA method on a compromised account, they can solidify their access, making it harder for legitimate users to regain control. The attacker can then operate with the privileges of the compromised account, potentially accessing sensitive data, making unauthorized changes, or even escalating their privileges further. Immediate action would be required to verify the legitimacy of the MFA change and, if malicious, to remediate and secure the affected account.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.005"], "nist": ["DE.CM"]}
known_false_positives = Users may register MFA methods legitimally, investigate and filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 OAuth App Mailbox Access via EWS - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS), as indicated by the ClientInfoString field starting with "Client=WebServices;ExchangeWebServices". It monitors mailbox activities, focusing on OAuth-authenticated applications that interact with EWS. The query aggregates key metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. For defenders, it is critical to keep track of OAuth applications using EWS to access emails, as this information is instrumental in identifying and preventing potential abuse or unauthorized data access.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]}
known_false_positives = OAuth applications may access mailboxes for legitimate purposes, you can use the src_ip to add trusted sources to an allow list.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 OAuth App Mailbox Access via Graph API - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This Splunk analytic detects when emails are accessed in Office 365 Exchange via the Microsoft Graph API, identified by the client ID '00000003-0000-0000-c000-000000000000'. It tracks the 'MailItemsAccessed' operation within the Exchange workload, focusing on OAuth-authenticated applications. The query compiles statistics on access frequency, timing, and client IP addresses, organized by user, client application ID, and AppId. For defenders, it's crucial to maintain an inventory of all OAuth applications that read emails, using this data to scrutinize and identify any potential abusive access patterns.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002"], "nist": ["DE.CM"]}
known_false_positives = OAuth applications may access mailboxes for legitimate purposes, you can use the ClientAppId to add trusted applications to an allow list.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Privileged Graph API Permission Assigned - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = This Splunk analytic detects the assignment of critical Graph API permissions in Azure AD using O365 Unified Audit Log as its data source. It focuses on three permissions, Application.ReadWrite.All (Entitlement ID 1bfefb4e-e0b5-418b-a88f-73c46d2cc8e9), AppRoleAssignment.ReadWrite.All (06b708a9-e830-4db3-a914-8e69da51d44f), and RoleManagement.ReadWrite.Directory (9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8). These permissions, crucial for controlling Azure AD settings, pose a high risk if misused. The query monitors Azure Active Directory workload events in the Office 365 Management Activity, specifically 'Update application' operations. It extracts and analyzes data to spot when these permissions are granted, gathering details about the user, object, and user agent involved. Due to the significant control these permissions provide, immediate investigation is crucial upon detection to prevent unauthorized modifications.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]}
known_false_positives = Privileged Graph API permissions may be assigned for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 PST export alert - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = This analytic detects instances where a user has initiated an eDiscovery search or exported a PST file from the search results in an Office 365 environment. The detection leverages the Office 365 management activity logs, specifically filtering for events categorized under ThreatManagement with the name eDiscovery search started or exported. The initiation of an eDiscovery search or the export of a PST file can be indicative of data exfiltration attempts or unauthorized access to sensitive information. PST files often contain a wealth of sensitive data, including the content of emails. Monitoring for such activities is crucial as they can expose sensitive organizational communications and data. If confirmed as a malicious activity, it suggests that an attacker or insider threat is attempting to gather or exfiltrate data. This can lead to data breaches, loss of intellectual property, or unauthorized access to confidential communications. Immediate investigation is required to determine the scope and intent of the activity and to take appropriate remedial actions.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114"], "nist": ["DE.CM"]}
known_false_positives = PST export can be done for legitimate purposes but due to the sensitive nature of its content it must be monitored.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Security And Compliance Alert Triggered - Rule]
type = detection
asset_type = O365 tenant
confidence = medium
explanation = The following detection is tailored to identify and act upon alerts generated by the Office 365 Security and Compliance Center, encompassing a broad spectrum of security and compliance issues indicative of potential threats or policy violations within the O365 workspace.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.004"], "nist": ["DE.CM"]}
known_false_positives = O365 Security and Compliance may also generate false positives or trigger on legitimate behavior, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Service Principal New Client Credentials - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic identifies the addition of new credentials for Service Principals in addition to existing legitimate credentials within a Office 365 tenant. These credentials include both x509 certificates and passwords. It leverages O365 audit logs, specifically events related to credential modifications or additions within the AzureActiveDirectory workload for service principals. Service principals represent application identities in Office 365 / AzureAD, and their credentials allow applications to authenticate and access resources. Adding new credentials or modifying existing ones can be an indication of configuration changes, but it can also be a sign of malicious intent If an attacker successfully adds or modifies credentials for a service principal, they can potentially use those credentials to authenticate as the application, gaining access to resources and data the application is permitted to access. This can lead to unauthorized data access, data exfiltration, or malicious operations performed under the guise of the application
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.001"], "nist": ["DE.CM"]}
known_false_positives = Service Principal client credential modifications may be part of legitimate administrative operations. Filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Tenant Wide Admin Consent Granted - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = The following analytic identifies instances where admin consent is granted to an application within an Azure AD and Office 365 tenant. It leverages O365 audit logs, specifically events related to the admin consent action within the AzureActiveDirectory workload. The admin consent action allows applications to access data across the entire tenant, potentially encompassing a vast amount of organizational data. Given its broad scope and the sensitivity of some permissions that can only be granted via admin consent, it's crucial to monitor this action. Unauthorized or inadvertent granting of admin consent can lead to significant security risks, including data breaches, unauthorized data access, and potential compliance violations. If an attacker successfully tricks an administrator into granting admin consent to a malicious or compromised application, they can gain extensive and persistent access to organizational data. This can lead to data exfiltration, espionage, further malicious activities within the tenant, and potential breaches of compliance regulations
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098", "T1098.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may be granted tenant wide consent, filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 User Consent Blocked for Risky Application - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This suggests that the application has exhibited behaviors or characteristics that are commonly associated with malicious intent or poses a security risk. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions and system-driven blocks. By filtering for blocked consent actions associated with applications, the analytic highlights instances where O365's built-in security measures have intervened. Applications that are flagged and blocked by O365 typically exhibit suspicious characteristics or behaviors. Monitoring for these blocked consent attempts helps security teams identify potential threats early on and can provide insights into users who might be targeted or susceptible to such risky applications. It's an essential layer of defense in ensuring that malicious or risky applications don't gain access to organizational data. If the detection is a true positive, it indicates that the built-in security measures of O365 successfully prevented a potentially harmful application from gaining access. However, the attempt itself suggests that either a user might be targeted or that there's a presence of malicious applications trying to infiltrate the organization. Immediate investigation is required to understand the context of the block and to take further preventive measures.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = Microsofts algorithm to identify risky applications is unknown and may flag legitimate applications.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 User Consent Denied for OAuth Application - Rule]
type = detection
asset_type = Office 365 tenant
confidence = medium
explanation = The following analytic identifies instances where a user has actively denied consent to an OAuth application seeking permissions within the Office 365 environment. This suggests that the user either recognized something suspicious about the application or chose not to grant it the requested permissions for other reasons. This detection leverages the O365 audit logs, specifically focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, the analytic captures instances where users have actively rejected permission requests. While user-denied consents can be routine, they can also be indicative of users spotting potentially suspicious or unfamiliar applications. By monitoring these denied consent attempts, security teams can gain insights into applications that might be perceived as risky or untrusted by users. It can also serve as a feedback loop for security awareness training, indicating that users are being cautious about granting permissions. If the detection is a true positive, it indicates that a user has actively prevented an OAuth application from gaining the permissions it requested. While this is a proactive security measure on the user's part, it's essential for security teams to review the context of the denial. Understanding why certain applications are being denied can help in refining application whitelisting policies and ensuring that no malicious applications are attempting to gain access.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1528"], "nist": ["DE.CM"]}
known_false_positives = OAuth applications that require mail permissions may be legitimate, investigate and filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - Risk Rule for Dev Sec Ops by Repository - Rule]
type = detection
asset_type = Amazon Elastic Container Registry
confidence = medium
explanation = The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts.
how_to_implement = Ensure that all relevant detections in the Dev Sec Ops analytic stories are enabled and are configured to create risk events in Enterprise Security.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = Unknown
providing_technologies = null

[savedsearch://ESCU - Abnormally High AWS Instances Launched by User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user successfully launches an abnormally high number of instances. This search is deprecated and have been translated to use the latest Change Datamodel
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. The threshold value should be tuned to your environment.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Abnormally High AWS Instances Launched by User - MLTK - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user successfully launches an abnormally high number of instances. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. The threshold value should be tuned to your environment.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Abnormally High AWS Instances Terminated by User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events where an abnormally high number of instances were successfully terminated by a user in a 10-minute window. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured with your AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify whether this search alerted on a human user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Abnormally High AWS Instances Terminated by User - MLTK - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user successfully terminates an abnormally high number of instances. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. The threshold value should be tuned to your environment.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured within an AWS infrastructure are known to exhibit this behavior. Please adjust the threshold values and filter out service accounts from the output. Always verify if this search alerted on a human user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Cloud Provisioning From Previously Unseen City - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS provisioning activities from previously unseen cities.  Provisioning activities are defined broadly as any event that begins with "Run" or "Create." This search is deprecated and have been translated to use the latest Change Datamodel. 
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen AWS Provisioning Activity Sources" support search once to create a history of previously seen locations that have provisioned AWS resources.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1535"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new city is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your city, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Cloud Provisioning From Previously Unseen Country - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS provisioning activities from previously unseen countries. Provisioning activities are defined broadly as any event that begins with "Run" or "Create." This search is deprecated and have been translated to use the latest Change Datamodel. 
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen AWS Provisioning Activity Sources" support search once to create a history of previously seen locations that have provisioned AWS resources.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1535"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching over plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new country is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Cloud Provisioning From Previously Unseen IP Address - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS provisioning activities from previously unseen IP addresses. Provisioning activities are defined broadly as any event that begins with "Run" or "Create." This search is deprecated and have been translated to use the latest Change Datamodel. 
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen AWS Provisioning Activity Sources" support search once to create a history of previously seen locations that have provisioned AWS resources.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new IP address is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your country, there should be few false positives. If you are located in countries where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS Cloud Provisioning From Previously Unseen Region - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS provisioning activities from previously unseen regions. Region in this context is similar to a state in the United States. Provisioning activities are defined broadly as any event that begins with "Run" or "Create." This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen AWS Provisioning Activity Sources" support search once to create a history of previously seen locations that have provisioned AWS resources.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1535"], "nist": ["DE.AE"]}
known_false_positives = This is a strictly behavioral search, so we define "false positive" slightly differently. Every time this fires, it will accurately reflect the first occurrence in the time period you're searching within, plus what is stored in the cache feature. But while there are really no "false positives" in a traditional sense, there is definitely lots of noise.\
 This search will fire any time a new region is seen in the **GeoIP** database for any kind of provisioning activity. If you typically do all provisioning from tools inside of your region, there should be few false positives. If you are located in regions where the free version of **MaxMind GeoIP** that ships by default with Splunk has weak resolution (particularly small countries in less economically powerful regions), this may be much less valuable to you.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - AWS EKS Kubernetes cluster sensitive object access - Rule]
type = detection
asset_type = AWS EKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes accounts accessing sensitve objects such as configmaps or secrets
how_to_implement = You must install Splunk Add-on for Amazon Web Services and Splunk App for AWS. This search works with cloudwatch logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Sensitive object access is not necessarily malicious but user and object context can provide guidance for detection.
providing_technologies = null

[savedsearch://ESCU - Clients Connecting to Multiple DNS Servers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search allows you to identify the endpoints that have connected to more than five DNS servers and made DNS Queries over the time frame of the search.
how_to_implement = This search requires that DNS data is being ingested and populating the `Network_Resolution` data model. This data can come from DNS logs or from solutions that parse network traffic for this data, such as Splunk Stream or Bro.\
This search produces fields (`dest_count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** Distinct DNS Connections, **Field:** dest_count\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.CM"]}
known_false_positives = It's possible that an enterprise has more than five DNS servers that are configured in a round-robin rotation. Please customize the search, as appropriate.
providing_technologies = null

[savedsearch://ESCU - Cloud Network Access Control List Deleted - Rule]
type = detection
asset_type = Instance
confidence = medium
explanation = Enforcing network-access controls is one of the defensive mechanisms used by cloud administrators to restrict access to a cloud instance. After the attacker has gained control of the console by compromising an admin account, they can delete a network ACL and gain access to the instance from anywhere. This search will query the Change datamodel to detect users deleting network ACLs. Deprecated because it's a duplicate
how_to_implement = You must be ingesting your cloud infrastructure logs from your cloud provider. You can also provide additional filtering for this search by customizing the `cloud_network_access_control_list_deleted_filter` macro.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a user has legitimately deleted a network ACL.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Correlation by Repository and Risk - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = This search has been deprecated and updated with Risk Rule for Dev Sec Ops by Repository detection. The following analytic detects by correlating repository and risk score to identify patterns and trends in the data based on the level of risk associated. The analytic adds any null values and calculates the sum of the risk scores for each detection. Then, the analytic captures the source and user information for each detection and sorts the results in ascending order based on the risk score. Finally, the analytic filters the detections with a risk score below 80 and focuses only on high-risk detections.This detection is important because it provides valuable insights into the distribution of high-risk activities across different repositories. It also identifies the most vulnerable repositories that are frequently targeted by potential threats. Additionally, it proactively detects and responds to potential threats, thereby minimizing the impact of attacks and safeguarding critical assets. Finally, it provides a comprehensive view of the risk landscape and helps to make informed decisions to protect the organization's data and infrastructure. False positives might occur so it is important to identify the impact of the attack and prioritize response and mitigation efforts.
how_to_implement = For Dev Sec Ops POC
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Correlation by User and Risk - Rule]
type = detection
asset_type = AWS Account
confidence = medium
explanation = The following analytic detects the correlation between the user and risk score and identifies users with a high risk score that pose a significant security risk such as unauthorized access attempts, suspicious behavior, or potential insider threats. Next, the analytic calculates the sum of the risk scores and groups the results by user, the corresponding signals, and the repository. The results are sorted in descending order based on the risk score and filtered to include records with a risk score greater than 80. Finally, the results are passed through a correlation filter specific to the user and risk. This detection is important because it identifies users who have a high risk score and helps to prioritize investigations and allocate resources. False positives might occur but the impact of such an attack can vary depending on the specific scenario such as data exfiltration, system compromise, or the disruption of critical services. Please investigate this notable event.
how_to_implement = For Dev Sec Ops POC
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.003", "T1204"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Detect Activity Related to Pass the Hash Attacks - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for specific authentication events from the Windows Security Event logs to detect potential attempts at using the Pass-the-Hash technique. This search is DEPRECATED as it is possible for event code 4624 to generate a high level of noise, as legitimate logon events may also trigger this event code. This can be especially true in environments with high levels of user activity, such as those with many concurrent logons or frequent logon attempts.
how_to_implement = To successfully implement this search, you must ingest your Windows Security Event logs and leverage the latest TA for Windows.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.002"], "nist": ["DE.AE"]}
known_false_positives = Legitimate logon activity by authorized NTLM systems may be detected by this search. Please investigate as appropriate.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect API activity from users without MFA - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events where a user logged into the AWS account, is making API calls and has not enabled Multi Factor authentication. Multi factor authentication adds a layer of security by forcing the users to type a unique authentication code from an approved authentication device when they access AWS websites or services. AWS Best Practices recommend that you enable MFA for privileged IAM users.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. Leverage the support search `Create a list of approved AWS service accounts`: run it once every 30 days to create a list of service accounts and validate them.\
This search produces fields (`eventName`,`userIdentity.type`,`userIdentity.arn`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** AWS Event Name, **Field:** eventName\
1. \
1. **Label:** AWS User ARN, **Field:** userIdentity.arn\
1. \
1. **Label:** AWS User Type, **Field:** userIdentity.type\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = Many service accounts configured within an AWS infrastructure do not have multi factor authentication enabled. Please ignore the service accounts, if triggered and instead add them to the aws_service_accounts.csv file to fine tune the detection. It is also possible that the search detects users in your environment using Single Sign-On systems, since the MFA is not handled by AWS.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect AWS API Activities From Unapproved Accounts - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for successful AWS CloudTrail activity by user accounts that are not listed in the identity table or `aws_service_accounts.csv`. It returns event names and count, as well as the first and last time a specific user or service is detected, grouped by users. Deprecated because managing this list can be quite hard.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. You must also populate the `identity_lookup_expanded` lookup shipped with the Asset and Identity framework to be able to look up users in your identity table in Enterprise Security (ES). Leverage the support search called "Create a list of approved AWS service accounts": run it once every 30 days to create and validate a list of service accounts.\
This search produces fields (`eventName`,`firstTime`,`lastTime`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** AWS Event Name, **Field:** eventName\
1. \
1. **Label:** First Time, **Field:** firstTime\
1. \
1. **Label:** Last Time, **Field:** lastTime\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = It's likely that you'll find activity detected by users/service accounts that are not listed in the `identity_lookup_expanded` or ` aws_service_accounts.csv` file. If the user is a legitimate service account, update the `aws_service_accounts.csv` table with that entry.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect DNS requests to Phishing Sites leveraging EvilGinx2 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for DNS requests for phishing domains that are leveraging EvilGinx tools to mimic websites.
how_to_implement = You need to ingest data from your DNS logs in the Network_Resolution datamodel. Specifically you must ingest the domain that is being queried and the IP of the host originating the request. Ideally, you should also be ingesting the answer to the query and the query type. This approach allows you to also create your own localized passive DNS capability which can aid you in future investigations. You will have to add legitimate domain names to the `legit_domains.csv` file shipped with the app. \
 **Splunk>Phantom Playbook Integration**\
If Splunk>Phantom is also configured in your environment, a Playbook called `Lets Encrypt Domain Investigate` can be configured to run when any results are found by this detection search. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search, and set the corresponding Playbook to active. \
(Playbook link:`https://my.phantom.us/4.2/playbook/lets-encrypt-domain-investigate/`).\

annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.003"], "nist": ["DE.CM"]}
known_false_positives = If a known good domain is not listed in the legit_domains.csv file, then the search could give you false postives. Please update that lookup file to filter out DNS requests to legitimate domains.
providing_technologies = null

[savedsearch://ESCU - Detect Long DNS TXT Record Response - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is used to detect attempts to use DNS tunneling, by calculating the length of responses to DNS TXT queries. Endpoints using DNS as a method of transmission for data exfiltration, Command And Control, or evasion of security controls can often be detected by noting unusually large volumes of DNS traffic. Deprecated because this detection should focus on DNS queries instead of DNS responses.
how_to_implement = To successfully implement this search you need to ingest data from your DNS logs, or monitor DNS traffic using Stream, Bro or something similar. Specifically, this query requires that the DNS data model is populated with information regarding the DNS record type that is being returned as well as the data in the answer section of the protocol.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.CM"]}
known_false_positives = It's possible that legitimate TXT record responses can be long enough to trigger this search. You can modify the packet threshold for this search to help mitigate false positives.
providing_technologies = null

[savedsearch://ESCU - Detect Mimikatz Using Loaded Images - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search looks for reading loaded Images unique to credential dumping with Mimikatz. Deprecated because mimikatz libraries changed and very noisy sysmon Event Code.
how_to_implement = This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 7 with powershell.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Other tools can import the same DLLs. These tools should be part of a whitelist. False positives may be present with any process that authenticates or uses credentials, PowerShell included. Filter based on parent process.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Detect Mimikatz Via PowerShell And EventCode 4703 - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search looks for PowerShell requesting privileges consistent with credential dumping. Deprecated, looks like things changed from a logging perspective.
how_to_implement = You must be ingesting Windows Security logs. You must also enable the account change auditing here: http://docs.splunk.com/Documentation/Splunk/7.0.2/Data/MonitorWindowseventlogdata. Additionally, this search requires you to enable your Group Management Audit Logs in your Local Windows Security Policy and to be ingesting those logs.  More information on how to enable them can be found here: http://whatevernetworks.com/auditing-group-membership-changes-in-active-directory/. Finally, please make sure that the local administrator group name is "Administrators" to be able to look for the right group membership changes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001"], "nist": ["DE.CM"]}
known_false_positives = The activity may be legitimate. PowerShell is often used by administrators to perform various tasks, and it's possible this event could be generated in those cases. In these cases, false positives should be fairly obvious and you may need to tweak the search to eliminate noise.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect new API calls from user roles - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search detects new API calls that have either never been seen before or that have not been seen in the previous hour, where the identity type is `AssumedRole`.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously seen API call per user roles in AWS CloudTrail" support search once to create a history of previously seen user roles.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = It is possible that there are legitimate user roles making new or infrequently used API calls in your infrastructure, causing the search to trigger.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect new user AWS Console Login - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events wherein a console login event by a user was recorded within the last hour, then compares the event to a lookup file of previously seen users (by ARN values) who have logged into the console. The alert is fired if the user has logged into the console for the first time within the last hour. Deprecated now this search is updated to use the Authentication datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. Run the "Previously seen users in AWS CloudTrail" support search only once to create a baseline of previously seen IAM users within the last 30 days. Run "Update previously seen users in AWS CloudTrail" hourly (or more frequently depending on how often you run the detection searches) to refresh the baselines.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = When a legitimate new user logins for the first time, this activity will be detected. Check how old the account is and verify that the user activity is legitimate.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect Spike in AWS API Activity - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search will detect users creating spikes of API activity in your AWS environment.  It will also update the cache file that factors in the latest data. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike.\
This search produces fields (`eventName`,`numberOfApiCalls`,`uniqueApisCalled`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** AWS Event Name, **Field:** eventName\
1. \
1. **Label:** Number of API Calls, **Field:** numberOfApiCalls\
1. \
1. **Label:** Unique API Calls, **Field:** uniqueApisCalled\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = 
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect Spike in Network ACL Activity - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search will detect users creating spikes in API activity related to network access-control lists (ACLs)in your AWS environment. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike. This search works best when you run the "Baseline of Network ACL Activity by ARN" support search once to create a lookup file of previously seen Network ACL Activity. To add or remove API event names related to network ACLs, edit the macro `network_acl_events`.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007"], "nist": ["DE.AE"]}
known_false_positives = The false-positive rate may vary based on the values of`dataPointThreshold` and `deviationThreshold`. Please modify this according the your environment.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect Spike in Security Group Activity - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search will detect users creating spikes in API activity related to security groups in your AWS environment.  It will also update the cache file that factors in the latest data.  This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike.This search works best when you run the "Baseline of Security Group Activity by ARN" support search once to create a history of previously seen Security Group Activity. To add or remove API event names for security groups, edit the macro `security_group_api_calls`.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = Based on the values of`dataPointThreshold` and `deviationThreshold`, the false positive rate may vary. Please modify this according the your environment.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Detect USB device insertion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search is used to detect hosts that generate Windows Event ID 4663 for successful attempts to write to or read from a removable storage and Event ID 4656 for failures, which occurs when a USB drive is plugged in. In this scenario we are querying the Change_Analysis data model to look for Windows Event ID 4656 or 4663 where the priority of the affected host is marked as high in the ES Assets and Identity Framework.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663 and 4656. Ensure that the field from the event logs is being mapped to the result_id field in the Change_Analysis data model. To minimize the alert volume, this search leverages the Assets and Identity framework to filter out events from those assets not marked high priority in the Enterprise Security Assets and Identity Framework.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = Legitimate USB activity will also be detected. Please verify and investigate as appropriate.
providing_technologies = null

[savedsearch://ESCU - Detect web traffic to dynamic domain providers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for web connections to dynamic DNS providers.
how_to_implement = This search requires you to be ingesting web-traffic logs. You can obtain these logs from indexing data from a web proxy or by using a network-traffic-analysis tool, such as Bro or Splunk Stream. The web data model must contain the URL being requested, the IP address of the host initiating the request, and the destination IP. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of dynamic DNS providers. Consider periodically updating this local lookup file with new domains.\
This search produces fields (`isDynDNS`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** IsDynamicDNS, **Field:** isDynDNS\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details` Deprecated because duplicate.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.001"], "nist": ["DE.CM"]}
known_false_positives = It is possible that list of dynamic DNS providers is outdated and/or that the URL being requested is legitimate.
providing_technologies = null

[savedsearch://ESCU - Detection of DNS Tunnels - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is used to detect DNS tunneling, by calculating the sum of the length of DNS queries and DNS answers. The search also filters out potential false positives by filtering out queries made to internal systems and the queries originating from internal DNS, Web, and Email servers. Endpoints using DNS as a method of transmission for data exfiltration, Command And Control, or evasion of security controls can often be detected by noting an unusually large volume of DNS traffic. \
NOTE:Deprecated because existing detection is doing the same. This detection is replaced with two other variations, if you are using MLTK then you can use this search `ESCU - DNS Query Length Outliers - MLTK - Rule` or use the standard deviation version `ESCU - DNS Query Length With High Standard Deviation - Rule`, as an alternantive.
how_to_implement = To successfully implement this search, we must ensure that DNS data is being ingested and mapped to the appropriate fields in the Network_Resolution data model. Fields like src_category are automatically provided by the Assets and Identity Framework shipped with Splunk Enterprise Security. You will need to ensure you are using the Assets and Identity Framework and populating the src_category field. You will also need to enable the `cim_corporate_web_domain_search()` macro which will essentially filter out the DNS queries made to the corporate web domains to reduce alert fatigue.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.CM"]}
known_false_positives = It's possible that normal DNS traffic will exhibit this behavior. If an alert is generated, please investigate and validate as appropriate. The threshold can also be modified to better suit your environment.
providing_technologies = null

[savedsearch://ESCU - DNS Query Requests Resolved by Unauthorized DNS Servers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search will detect DNS requests resolved by unauthorized DNS servers. Legitimate DNS servers should be identified in the Enterprise Security Assets and Identity Framework.
how_to_implement = To successfully implement this search you will need to ensure that DNS data is populating the Network_Resolution data model. It also requires that your DNS servers are identified correctly in the Assets and Identity table of Enterprise Security.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.004"], "nist": ["DE.CM"]}
known_false_positives = Legitimate DNS activity can be detected in this search. Investigate, verify and update the list of authorized DNS servers as appropriate.
providing_technologies = null

[savedsearch://ESCU - DNS record changed - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search takes the DNS records and their answers results of the discovered_dns_records lookup and finds if any records have changed by searching DNS response from the Network_Resolution datamodel across the last day.
how_to_implement = To successfully implement this search you will need to ensure that DNS data is populating the `Network_Resolution` data model. It also requires that the `discover_dns_record` lookup table be populated by the included support search "Discover DNS record". \
 **Splunk>Phantom Playbook Integration**\
If Splunk>Phantom is also configured in your environment, a Playbook called "DNS Hijack Enrichment" can be configured to run when any results are found by this detection search. The playbook takes in the DNS record changed and uses Geoip, whois, Censys and PassiveTotal to detect if DNS issuers changed. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search, and set the corresponding Playbook to active. \
(Playbook Link:`https://my.phantom.us/4.2/playbook/dns-hijack-enrichment/`).\

annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.004"], "nist": ["DE.CM"]}
known_false_positives = Legitimate DNS changes can be detected in this search. Investigate, verify and update the list of provided current answers for the domains in question as appropriate.
providing_technologies = null

[savedsearch://ESCU - Dump LSASS via procdump Rename - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Detect a renamed instance of procdump.exe dumping the lsass process. This query looks for both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump file with all process memory. Both are highly suspect and should be reviewed. Modify the query as needed.\
During triage, confirm this is procdump.exe executing. If it is the first time a Sysinternals utility has been ran, it is possible there will be a -accepteula on the command line. Review other endpoint data sources for cross process (injection) into lsass.exe.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001"], "nist": ["DE.AE"]}
known_false_positives = None identified.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - EC2 Instance Modified With Previously Unseen User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for EC2 instances being modified by users who have not previously modified them. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen EC2 Launches By User" support search once to create a history of previously seen ARNs. To add or remove APIs that modify an EC2 instance, edit the macro `ec2_modification_api_calls`.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a new user will start to modify EC2 instances when they haven't before for any number of reasons. Verify with the user that is modifying instances that this is the intended behavior.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - EC2 Instance Started In Previously Unseen Region - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for AWS CloudTrail events where an instance is started in a particular region in the last one hour and then compares it to a lookup file of previously seen regions where an instance was started
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. Run the "Previously seen AWS Regions" support search only once to create of baseline of previously seen regions.  This search is deprecated and have been translated to use the latest Change Datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1535"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a user has unknowingly started an instance in a new region. Please verify that this activity is legitimate.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - EC2 Instance Started With Previously Unseen AMI - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for EC2 instances being created with previously unseen AMIs.  This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen EC2 AMIs" support search once to create a history of previously seen AMIs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = After a new AMI is created, the first systems created with that AMI will cause this alert to fire.  Verify that the AMI being used was created by a legitimate user.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - EC2 Instance Started With Previously Unseen Instance Type - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for EC2 instances being created with previously unseen instance types.  This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen EC2 Instance Types" support search once to create a history of previously seen instance types.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = It is possible that an admin will create a new system using a new instance type never used before. Verify with the creator that they intended to create the system with the new instance type.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - EC2 Instance Started With Previously Unseen User - Rule]
type = detection
asset_type = AWS Instance
confidence = medium
explanation = This search looks for EC2 instances being created by users who have not created them before. This search is deprecated and have been translated to use the latest Change Datamodel.
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your AWS CloudTrail inputs. This search works best when you run the "Previously Seen EC2 Launches By User" support search once to create a history of previously seen ARNs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.004"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a user will start to create EC2 instances when they haven't before for any number of reasons. Verify with the user that is launching instances that this is the intended behavior.
providing_technologies = ["Amazon Web Services - Cloudtrail"]

[savedsearch://ESCU - Execution of File With Spaces Before Extension - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes launched from files with at least five spaces in the name before the extension. This is typically done to obfuscate the file extension by pushing it outside of the default view.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.003"], "nist": ["DE.CM"]}
known_false_positives = None identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Extended Period Without Successful Netbackup Backups - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search returns a list of hosts that have not successfully completed a backup in over a week. Deprecated because it's a infrastructure monitoring.
how_to_implement = To successfully implement this search you need to first obtain data from your backup solution, either from the backup logs on your hosts, or from a central server responsible for performing the backups. If you do not use Netbackup, you can modify this search for your backup solution. Depending on how often you backup your systems, you may want to modify how far in the past to look for a successful backup, other than the default of seven days.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - First time seen command line argument - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for command-line arguments that use a `/c` parameter to execute a command that has not previously been seen.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059.003"], "nist": ["DE.AE"]}
known_false_positives = Legitimate programs can also use command-line arguments to execute. Please verify the command-line arguments to check what command/program is being executed. We recommend customizing the `first_time_seen_cmd_line_filter` macro to exclude legitimate parent_process_name
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GCP Detect accounts with high risk roles by project - Rule]
type = detection
asset_type = GCP Account
confidence = medium
explanation = This search provides detection of accounts with high risk roles by projects. Compromised accounts with high risk roles can move laterally or even scalate privileges at different projects depending on organization schema.
how_to_implement = You must install splunk GCP add-on. This search works with gcp:pubsub:message logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = Accounts with high risk roles should be reduced to the minimum number needed, however specific tasks and setups may be simply expected behavior within organization
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Detect high risk permissions by resource and account - Rule]
type = detection
asset_type = GCP Account
confidence = medium
explanation = This search provides detection of high risk permissions by resource and accounts. These are permissions that can allow attackers with compromised accounts to move laterally and escalate privileges.
how_to_implement = You must install splunk GCP add-on. This search works with gcp:pubsub:message logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = High risk permissions are part of any GCP environment, however it is important to track resource and accounts usage, this search may produce false positives.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - gcp detect oauth token abuse - Rule]
type = detection
asset_type = GCP Account
confidence = medium
explanation = This search provides detection of possible GCP Oauth token abuse. GCP Oauth token without time limit can be exfiltrated and reused for keeping access sessions alive without further control of authentication, allowing attackers to access and move laterally.
how_to_implement = You must install splunk GCP add-on. This search works with gcp:pubsub:message logs
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = GCP Oauth token abuse detection will only work if there are access policies in place along with audit logs.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - GCP Kubernetes cluster scan detection - Rule]
type = detection
asset_type = GCP Kubernetes cluster
confidence = medium
explanation = This search provides information of unauthenticated requests via user agent, and authentication data against Kubernetes cluster
how_to_implement = You must install the GCP App for Splunk (version 2.0.0 or later), then configure stackdriver and set a Pub/Sub subscription to be imported to Splunk. You must also install Cloud Infrastructure data model.Customize the macro kubernetes_gcp_scan_fingerprint_attack_detection to filter out FPs.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.CM"]}
known_false_positives = Not all unauthenticated requests are malicious, but frequency, User Agent and source IPs will provide context.
providing_technologies = ["Google Workspace", "Google Cloud Platform"]

[savedsearch://ESCU - Identify New User Accounts - Rule]
type = detection
asset_type = Domain Server
confidence = medium
explanation = This detection search will help profile user accounts in your environment by identifying newly created accounts that have been added to your network in the past week.
how_to_implement = To successfully implement this search, you need to be populating the Enterprise Security Identity_Management data model in the assets and identity framework.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.002"], "nist": ["DE.AE"]}
known_false_positives = If the Identity_Management data model is not updated regularly, this search could give you false positive alerts. Please consider this and investigate appropriately.
providing_technologies = null

[savedsearch://ESCU - Kubernetes AWS detect most active service accounts by pod - Rule]
type = detection
asset_type = AWS EKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes service accounts,accessing pods by IP address, verb and decision
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all service accounts interactions are malicious. Analyst must consider IP, verb and decision context when trying to detect maliciousness.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes AWS detect RBAC authorization by account - Rule]
type = detection
asset_type = AWS EKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes RBAC authorizations by accounts, this search can be modified by adding top to see both extremes of RBAC by accounts occurrences
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all RBAC Authorications are malicious. RBAC authorizations can uncover malicious activity specially if sensitive Roles have been granted.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes AWS detect sensitive role access - Rule]
type = detection
asset_type = AWS EKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes accounts accessing sensitve objects such as configmpas or secrets
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Sensitive role resource access is necessary for cluster operation, however source IP, namespace and user group may indicate possible malicious use. 
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes AWS detect service accounts forbidden failure access - Rule]
type = detection
asset_type = AWS EKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes service accounts with failure or forbidden access status, this search can be extended by using top or rare operators to find trends or rarities in failure status, user agents, source IPs and request URI
how_to_implement = You must install splunk AWS add on and Splunk App for AWS. This search works with cloudwatch logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = This search can give false positives as there might be inherent issues with authentications and permissions at cluster.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure active service accounts by pod namespace - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes service accounts,accessing pods and namespaces by IP address and verb
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all service accounts interactions are malicious. Analyst must consider IP and verb context when trying to detect maliciousness.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure detect RBAC authorization by account - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes RBAC authorizations by accounts, this search can be modified by adding rare or top to see both extremes of RBAC by accounts occurrences
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all RBAC Authorications are malicious. RBAC authorizations can uncover malicious activity specially if sensitive Roles have been granted.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure detect sensitive object access - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes accounts accessing sensitve objects such as configmpas or secrets
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Sensitive object access is not necessarily malicious but user and object context can provide guidance for detection.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure detect sensitive role access - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes accounts accessing sensitve objects such as configmpas or secrets
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Sensitive role resource access is necessary for cluster operation, however source IP, namespace and user group may indicate possible malicious use. 
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure detect service accounts forbidden failure access - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes service accounts with failure or forbidden access status
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = This search can give false positives as there might be inherent issues with authentications and permissions at cluster.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure detect suspicious kubectl calls - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information on rare Kubectl calls with IP, verb namespace and object access context
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Kubectl calls are not malicious by nature. However source IP, verb and Object can reveal potential malicious activity, specially suspicious IPs and sensitive objects such as configmaps or secrets
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure pod scan fingerprint - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information of unauthenticated requests via source IP user agent, request URI and response status data against Kubernetes cluster pod in Azure
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all unauthenticated requests are malicious, but source IPs, userAgent, verb, request URI and response status will provide context.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes Azure scan fingerprint - Rule]
type = detection
asset_type = Azure AKS Kubernetes cluster
confidence = medium
explanation = This search provides information of unauthenticated requests via source IP user agent, request URI and response status data against Kubernetes cluster in Azure
how_to_implement = You must install the Add-on for Microsoft Cloud Services and Configure Kube-Audit data diagnostics
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1526"], "nist": ["DE.AE"]}
known_false_positives = Not all unauthenticated requests are malicious, but source IPs, userAgent, verb, request URI and response status will provide context.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes GCP detect most active service accounts by pod - Rule]
type = detection
asset_type = GCP GKE Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes service accounts,accessing pods by IP address, verb and decision
how_to_implement = You must install splunk GCP add on. This search works with pubsub messaging service logs
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all service accounts interactions are malicious. Analyst must consider IP, verb and decision context when trying to detect maliciousness.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes GCP detect RBAC authorizations by account - Rule]
type = detection
asset_type = GCP GKE Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes RBAC authorizations by accounts, this search can be modified by adding top to see both extremes of RBAC by accounts occurrences
how_to_implement = You must install splunk AWS add on for GCP. This search works with pubsub messaging service logs
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Not all RBAC Authorications are malicious. RBAC authorizations can uncover malicious activity specially if sensitive Roles have been granted.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes GCP detect sensitive object access - Rule]
type = detection
asset_type = GCP GKE Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes accounts accessing sensitve objects such as configmaps or secrets
how_to_implement = You must install splunk add on for GCP . This search works with pubsub messaging service logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Sensitive object access is not necessarily malicious but user and object context can provide guidance for detection.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes GCP detect sensitive role access - Rule]
type = detection
asset_type = GCP GKE EKS Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes accounts accessing sensitve objects such as configmpas or secrets
how_to_implement = You must install splunk add on for GCP. This search works with pubsub messaging servicelogs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Sensitive role resource access is necessary for cluster operation, however source IP, user agent, decision and reason may indicate possible malicious use. 
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes GCP detect service accounts forbidden failure access - Rule]
type = detection
asset_type = GCP GKE Kubernetes cluster
confidence = medium
explanation = This search provides information on Kubernetes service accounts with failure or forbidden access status, this search can be extended by using top or rare operators to find trends or rarities in failure status, user agents, source IPs and request URI
how_to_implement = You must install splunk add on for GCP. This search works with pubsub messaging service logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = This search can give false positives as there might be inherent issues with authentications and permissions at cluster.
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Kubernetes GCP detect suspicious kubectl calls - Rule]
type = detection
asset_type = GCP GKE Kubernetes cluster
confidence = medium
explanation = This search provides information on anonymous Kubectl calls with IP, verb namespace and object access context
how_to_implement = You must install splunk add on for GCP. This search works with pubsub messaging logs.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Kubectl calls are not malicious by nature. However source IP, source user, user agent, object path, and authorization context can reveal potential malicious activity, specially anonymous suspicious IPs and sensitive objects such as configmaps or secrets
providing_technologies = ["Kubernetes"]

[savedsearch://ESCU - Monitor DNS For Brand Abuse - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for DNS requests for faux domains similar to the domains that you want to have monitored for abuse.
how_to_implement = You need to ingest data from your DNS logs. Specifically you must ingest the domain that is being queried and the IP of the host originating the request. Ideally, you should also be ingesting the answer to the query and the query type. This approach allows you to also create your own localized passive DNS capability which can aid you in future investigations. You also need to have run the search "ESCU - DNSTwist Domain Names", which creates the permutations of the domain that will be checked for. You also need the [`dnstwist`](https://gist.github.com/d1vious/c4c2aae7fa7d5cbb1f24adc5f6303ac1) custom command.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = None at this time
providing_technologies = null

[savedsearch://ESCU - Multiple Okta Users With Invalid Credentials From The Same IP - Rule]
type = detection
asset_type = Okta tenant
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `Okta Multiple Users Failing To Authenticate From Ip`. This analytic identifies multiple failed logon attempts from a single IP in a short period of time. Use this analytic to identify patterns of suspicious logins from a single source and filter as needed or use this to drive tuning for higher fidelity analytics.
how_to_implement = This search is specific to Okta and requires Okta logs are being ingested in your Splunk deployment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1110.003", "T1078", "T1078.001"], "nist": ["DE.CM"]}
known_false_positives = A single public IP address servicing multiple legitmate users may trigger this search. In addition, the threshold of 5 distinct users may be too low for your needs. You may modify the included filter macro `multiple_okta_users_with_invalid_credentials_from_the_same_ip_filter` to raise the threshold or except specific IP adresses from triggering this search.
providing_technologies = ["Okta"]

[savedsearch://ESCU - O365 Suspicious Admin Email Forwarding - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `O365 Mailbox Email Forwarding Enabled`. This search detects when an admin configured a forwarding rule for multiple mailboxes to the same destination.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.003", "T1114"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Suspicious Rights Delegation - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `O365 Elevated Mailbox Permission Assigned`. This analytic identifies instances where potentially suspicious rights are delegated within the Office 365 environment. Specifically, it detects when a user is granted FullAccess, SendAs, or SendOnBehalf permissions on another users mailbox. Such permissions can allow a user to access, send emails from, or send emails on behalf of the target mailbox. The detection leverages O365 audit logs, focusing on the Add-MailboxPermission operation. By parsing the parameters of this operation, the analytic filters for events where FullAccess, SendAs, or SendOnBehalf rights are granted. It then aggregates this data to capture the source user (who was granted the permissions), the destination user (whose mailbox was affected), the specific operation, and the type of access rights granted. Delegating mailbox rights, especially those as powerful as FullAccess, can pose significant security risks. While there are legitimate scenarios for these permissions, such as an executive assistant needing access to an executives mailbox, there are also malicious scenarios where an attacker or a compromised insider might grant themselves unauthorized access to sensitive mailboxes. Monitoring for these permissions changes is crucial to detect potential insider threats, compromised accounts, or other malicious activities.If the detection is a true positive, it indicates that a user has been granted potentially high-risk permissions on another users mailbox. This could lead to unauthorized access to sensitive emails, impersonation through sending emails as or on behalf of the mailbox owner, or data manipulation by altering or deleting emails. Immediate investigation is required to validate the legitimacy of the permission change and to assess the potential risks associated with the granted access.
how_to_implement = You must install the Splunk Microsoft Office 365 Add-on and ingest Office 365 management activity events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1114.002", "T1114", "T1098.002", "T1098"], "nist": ["DE.CM"]}
known_false_positives = While there are legitimate scenarios for these permissions, such as an executive assistant needing access to an executive's mailbox, there are also malicious scenarios. Investigate and filter as needed.
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - O365 Suspicious User Email Forwarding - Rule]
type = detection
asset_type = Office 365
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `O365 Mailbox Email Forwarding Enabled`. The following analytic detects when multiple users have configured a forwarding rule to the same destination to proactively identify and investigate potential security risks related to email forwarding and take appropriate actions to protect the organizations data and prevent unauthorized access or data breaches. This detection is made by a Splunk query to O365 management activity logs with the operation `Set-Mailbox` to gather information about mailbox configurations. Then, the query uses the `spath` function to extract the parameters and rename the "Identity" field as "src_user" and searches for entries where the "ForwardingSmtpAddress" field is not empty, which indicates the presence of a forwarding rule. Next, the analytic uses the `stats` command to group the results by the forwarding email address and count the number of unique source users (`src_user`). Finally, it filters the results and only retains entries where the count of source users (`count_src_user`) is greater than 1, which indicates that multiple users have set up forwarding rules to the same destination. This detection is important because it suggests that multiple users are forwarding emails to the same destination without proper authorization, which can lead to the exposure of sensitive information, loss of data control, or unauthorized access to confidential emails. Investigating and addressing this issue promptly can help prevent data breaches and mitigate potential damage.indicates a potential security risk since multiple users forwarding emails to the same destination can be a sign of unauthorized access, data exfiltration, or a compromised account. Additionally, it also helps to determine if the forwarding rules are legitimate or if they indicate a security incident. False positives can occur if there are legitimate reasons for multiple users to forward emails to the same destination, such as a shared mailbox or a team collaboration scenario. Next steps include further investigation and context analysis to determine the legitimacy of the forwarding rules.
how_to_implement = You must install splunk Microsoft Office 365 add-on. This search works with o365:management:activity
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.003", "T1114"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Office 365"]

[savedsearch://ESCU - Okta Account Locked Out - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `Okta Multiple Accounts Locked Out`. The following analytic utilizes the user.acount.lock event to identify associates who are locked out of Okta. An adversary attempting to brute force or password spray account names may lock accounts out depending on the threshold.
how_to_implement = This analytic is specific to Okta and requires Okta logs to be ingested.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning is complete.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Account Lockout Events - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `Okta Multiple Accounts Locked Out`. The following anomaly will generate based on account lockout events utilizing Okta eventTypes of user.account.lock.limit or user.account.lock. Per the Okta docs site, this event is fired when a user account has reached the lockout limit. The account will not auto-unlock and a user or client cannot gain access to the account. This event indicates an account that will not be able to log in until remedial action is taken by the account admin. This event can be used to understand the specifics of an account lockout. Often this indicates a client application that is repeatedly attempting to authenticate with invalid credentials such as an old password.
how_to_implement = This analytic is specific to Okta and requires Okta logs to be ingested.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.AE"]}
known_false_positives = None. Account lockouts should be followed up on to determine if the actual user was the one who caused the lockout, or if it was an unauthorized actor.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Failed SSO Attempts - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with this detection `Okta Unauthorized Access to Application - DM`.  The following anomaly identifies failed Okta SSO events utilizing the legacy Okta event "unauth app access attempt".
how_to_implement = This search is specific to Okta and requires Okta logs are being ingested in your Splunk deployment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001"], "nist": ["DE.AE"]}
known_false_positives = There may be a faulty config preventing legitmate users from accessing apps they should have access to.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta ThreatInsight Login Failure with High Unknown users - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `Okta ThreatInsight Threat Detected`. The following analytic utilizes Oktas ThreatInsight to identify Login failures with high unknown users count and any included secondary outcome reasons. This event will trigger when a brute force attempt occurs with unknown usernames attempted.
how_to_implement = This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001", "T1110.004"], "nist": ["DE.CM"]}
known_false_positives = Fidelity of this is high as it is Okta ThreatInsight. Filter and modify as needed.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta ThreatInsight Suspected PasswordSpray Attack - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `Okta ThreatInsight Threat Detected`. The following analytic utilizes Oktas ThreatInsight to identify "PasswordSpray" and any included secondary outcome reasons. This event will trigger when a brute force attempt occurs with unknown usernames attempted.
how_to_implement = This search is specific to Okta and requires Okta logs to be ingested in your Splunk deployment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.001", "T1110.003"], "nist": ["DE.CM"]}
known_false_positives = Fidelity of this is high as it is Okta ThreatInsight. Filter and modify as needed.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Okta Two or More Rejected Okta Pushes - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = **DEPRECATION NOTE** - This search has been deprecated and replaced with `Okta Multiple Failed MFA Requests For User`. The following analytic identifies an account that has rejected more than 2 Push notifications in a 10 minute window. Modify this query for your environment by upping the count or time window.
how_to_implement = This analytic is specific to Okta and requires Okta logs to be ingested.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present. Tune Okta and tune the analytic to ensure proper fidelity. Modify risk score as needed. Drop to anomaly until tuning is complete.
providing_technologies = ["Okta"]

[savedsearch://ESCU - Open Redirect in Splunk Web - Rule]
type = detection
asset_type = Splunk Server
confidence = medium
explanation = This search allows you to look for evidence of exploitation for CVE-2016-4859, the Splunk Open Redirect Vulnerability.
how_to_implement = No extra steps needed to implement this search.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - Osquery pack - ColdRoot detection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for ColdRoot events from the osx-attacks osquery pack.
how_to_implement = In order to properly run this search, Splunk needs to ingest data from your osquery deployed agents with the [osx-attacks.conf](https://github.com/facebook/osquery/blob/experimental/packs/osx-attacks.conf#L599) pack enabled. Also the [TA-OSquery](https://github.com/d1vious/TA-osquery) must be deployed across your indexers and universal forwarders in order to have the osquery data populate the Alerts data model
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = There are no known false positives.
providing_technologies = null

[savedsearch://ESCU - Processes created by netsh - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes launching netsh.exe to execute various commands via the netsh command-line utility. Netsh.exe is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper .dll when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe that are executing commands via the command line. Deprecated because we have another detection of the same type.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004"], "nist": ["DE.CM"]}
known_false_positives = It is unusual for netsh.exe to have any child processes in most environments. It makes sense to investigate the child process and verify whether the process spawned is legitimate. We explicitely exclude "C:\Program Files\rempl\sedlauncher.exe" process path since it is a legitimate process by Mircosoft.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Prohibited Software On Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for applications on the endpoint that you have marked as prohibited.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Reg exe used to hide files directories via registry keys - Rule]
type = detection
asset_type = 
confidence = medium
explanation = The search looks for command-line arguments used to hide a file or directory using the reg add command.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.001"], "nist": ["DE.CM"]}
known_false_positives = None at the moment
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Registry Key modifications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search monitors for remote modifications to registry keys.
how_to_implement = To successfully implement this search, you must populate the `Endpoint` data model. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry. Deprecated because I don't think the logic is right.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = This technique may be legitimately used by administrators to modify remote registries, so it's important to filter these events out.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Scheduled tasks used in BadRabbit ransomware - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for flags passed to schtasks.exe on the command-line that indicate that task names related to the execution of Bad Rabbit ransomware were created or deleted. Deprecated because we already have a similar detection
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005"], "nist": ["DE.CM"]}
known_false_positives = No known false positives
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Spectre and Meltdown Vulnerable Systems - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search is used to detect systems that are still vulnerable to the Spectre and Meltdown vulnerabilities.
how_to_implement = The search requires that you are ingesting your vulnerability-scanner data and that it reports the CVE of the vulnerability identified.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = It is possible that your vulnerability scanner is not detecting that the patches have been applied.
providing_technologies = null

[savedsearch://ESCU - Splunk Enterprise Information Disclosure - Rule]
type = detection
asset_type = Splunk Server
confidence = medium
explanation = This search allows you to look for evidence of exploitation for CVE-2018-11409, a Splunk Enterprise Information Disclosure Bug.
how_to_implement = The REST endpoint that exposes system information is also necessary for the proper operation of Splunk clustering and instrumentation. Whitelisting your Splunk systems will reduce false positives.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = Retrieving server information may be a legitimate API request. Verify that the attempt is a valid request for information.
providing_technologies = null

[savedsearch://ESCU - Suspicious Changes to File Associations - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for changes to registry values that control Windows file associations, executed by a process that is not typical for legitimate, routine changes to this area.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.001"], "nist": ["DE.CM"]}
known_false_positives = There may be other processes in your environment that users may legitimately use to modify file associations. If this is the case and you are finding false positives, you can modify the search to add those processes as exceptions.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Email - UBA Anomaly - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection looks for emails that are suspicious because of their sender, domain rareness, or behavior differences. This is an anomaly generated by Splunk User Behavior Analytics (UBA).
how_to_implement = You must be ingesting data from email logs and have Splunk integrated with UBA. This anomaly is raised by a UBA detection model called  "SuspiciousEmailDetectionModel." Ensure that this model is enabled on your UBA instance.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = This detection model will alert on any sender domain that is seen for the first time. This could be a potential false positive. The next step is to investigate and add the URL to an allow list if you determine that it is a legitimate sender.
providing_technologies = null

[savedsearch://ESCU - Suspicious File Write - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for files created with names that have been linked to malicious activity.
how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or via other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report file system reads and writes. In addition, this search leverages an included lookup file that contains the names of the files to watch for, as well as a note to communicate why that file name is being monitored. This lookup file can be edited to add or remove file the file names you want to monitor.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = It's possible for a legitimate file to be created with the same name as one noted in the lookup file. Filenames listed in the lookup file should be unique enough that collisions are rare. Looking at the location of the file and the process responsible for the activity can help determine whether or not the activity is legitimate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Powershell Command-Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for PowerShell processes started with a base64 encoded command-line passed to it, with parameters to modify the execution policy for the process, and those that prevent the display of an interactive prompt to the user. This combination of command-line options is suspicious because it overrides the default PowerShell execution policy, attempts to hide itself from the user, and passes an encoded script to be run on the command-line. Deprecated because almost the same as Malicious PowerShell Process - Encoded Command
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001"], "nist": ["DE.CM"]}
known_false_positives = Legitimate process can have this combination of command-line options, but it's not common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Rundll32 Rename - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies renamed instances of rundll32.exe executing. rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, validate it is the legitimate rundll32.exe executing and what script content it is loading. This query relies on the original filename or internal name from the PE meta data. Expand the query as needed by looking for specific command line arguments outlined in other analytics.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1036", "T1218.011", "T1036.003"], "nist": ["DE.AE"]}
known_false_positives = Although unlikely, some legitimate applications may use a moved copy of rundll32, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious writes to System Volume Information - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search detects writes to the 'System Volume Information' folder by something other than the System process.
how_to_implement = You need to be ingesting logs with both the process name and command-line from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.AE"]}
known_false_positives = It is possible that other utilities or system processes may legitimately write to this folder. Investigate and modify the search to include exceptions as appropriate.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Uncommon Processes On Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for applications on the endpoint that you have marked as uncommon.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.002"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Unsigned Image Loaded by LSASS - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search detects loading of unsigned images by LSASS. Deprecated because too noisy.
how_to_implement = This search needs Sysmon Logs with a sysmon configuration, which includes EventCode 7 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001"], "nist": ["DE.CM"]}
known_false_positives = Other tools could load images into LSASS for legitimate reason. But enterprise tools should always use signed DLLs.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Unsuccessful Netbackup backups - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search gives you the hosts where a backup was attempted and then failed.
how_to_implement = To successfully implement this search you need to obtain data from your backup solution, either from the backup logs on your endpoints or from a central server responsible for performing the backups. If you do not use Netbackup, you can modify this search for your specific backup solution.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - Web Fraud - Account Harvesting - Rule]
type = detection
asset_type = Account
confidence = medium
explanation = This search is used to identify the creation of multiple user accounts using the same email domain name.
how_to_implement = We start with a dataset that provides visibility into the email address used for the account creation. In this example, we are narrowing our search down to the single web page that hosts the Magento2 e-commerce platform (via URI) used for account creation, the single http content-type to grab only the user's clicks, and the http field that provides the username (form_data), for performance reasons.  After we have the username and email domain, we look for numerous account creations per email domain.  Common data sources used for this detection are customized Apache logs or Splunk Stream.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136"], "nist": ["DE.CM"]}
known_false_positives = As is common with many fraud-related searches, we are usually looking to attribute risk or synthesize relevant context with loosely written detections that simply detect anamolous behavior. This search will need to be customized to fit your environment&#151;improving its fidelity by counting based on something much more specific, such as a device ID that may be present in your dataset. Consideration for whether the large number of registrations are occuring from a first-time seen domain may also be important.  Extending the search window to look further back in time, or even calculating the average per hour/day for each email domain to look for an anomalous spikes, will improve this search.  You can also use Shannon entropy or Levenshtein Distance (both courtesy of URL Toolbox) to consider the randomness or similarity of the email name or email domain, as the names are often machine-generated.
providing_technologies = null

[savedsearch://ESCU - Web Fraud - Anomalous User Clickspeed - Rule]
type = detection
asset_type = account
confidence = medium
explanation = This search is used to examine web sessions to identify those where the clicks are occurring too quickly for a human or are occurring with a near-perfect cadence (high periodicity or low standard deviation), resembling a script driven session.
how_to_implement = Start with a dataset that allows you to see clickstream data for each user click on the website. That data must have a time stamp and must contain a reference to the session identifier being used by the website. This ties the clicks together into clickstreams. This value is usually found in the http cookie. With a bit of tuning, a version of this search could be used in high-volume scenarios, such as scraping, crawling, application DDOS, credit-card testing, account takeover, etc. Common data sources used for this detection are customized Apache logs, customized IIS, and Splunk Stream.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = As is common with many fraud-related searches, we are usually looking to attribute risk or synthesize relevant context with loosly written detections that simply detect anamoluous behavior.
providing_technologies = null

[savedsearch://ESCU - Web Fraud - Password Sharing Across Accounts - Rule]
type = detection
asset_type = account
confidence = medium
explanation = This search is used to identify user accounts that share a common password.
how_to_implement = We need to start with a dataset that allows us to see the values of usernames and passwords that users are submitting to the website hosting the Magento2 e-commerce platform (commonly found in the HTTP form_data field). A tokenized or hashed value of a password is acceptable and certainly preferable to a clear-text password. Common data sources used for this detection are customized Apache logs, customized IIS, and Splunk Stream.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = As is common with many fraud-related searches, we are usually looking to attribute risk or synthesize relevant context with loosely written detections that simply detect anamoluous behavior.
providing_technologies = null

[savedsearch://ESCU - Windows connhost exe started forcefully - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for the Console Window Host process (connhost.exe) executed using the force flag -ForceV1. This is not regular behavior in the Windows OS and is often seen executed by the Ryuk Ransomware. DEPRECATED This event is actually seen in the windows 10 client of attack_range_local. After further testing we realized this is not specific to Ryuk. 
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003"], "nist": ["DE.CM"]}
known_false_positives = This process should not be ran forcefully, we have not see any false positives for this detection
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows hosts file modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for modifications to the hosts file on all Windows endpoints across your environment.
how_to_implement = To successfully implement this search, you must be ingesting data that records the file-system activity from your hosts to populate the Endpoint.Filesystem data model node. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or by other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report file-system reads and writes.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = There may be legitimate reasons for system administrators to add entries to this file.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - 3CX Supply Chain Attack Network Indicators - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The analytic provided below employs the Network_Resolution datamodel to detect domain indicators associated with the 3CX supply chain attack. By leveraging this query, you can efficiently conduct retrospective analysis of your data to uncover potential compromises.
how_to_implement = To successfully implement this search you need to be ingesting information into the `Network Resolution` datamodel in the `DNS` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA''s are installed.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.002"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present for accessing the 3cx[.]com website. Remove from the lookup as needed.
providing_technologies = null

[savedsearch://ESCU - 7zip CommandLine To SMB Share Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious 7z process with commandline pointing to SMB network share. This technique was seen in CONTI LEAK tools where it use 7z to archive a sensitive files and place it in network share tmp folder. This search is a good hunting query that may give analyst a hint why specific user try to archive a file pointing to SMB user which is un usual.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Access LSASS Memory for Dump Creation - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The following analytic detects the dumping of the LSASS process memory, which occurs during credential dumping attacks.The detection is made by using Sysmon logs, specifically EventCode 10, which is related to lsass.exe. This helps to search for indicators of LSASS memory dumping such as specific call traces to dbgcore.dll and dbghelp.dll. This detection is important because it prevents credential dumping attacks and the theft of sensitive information such as login credentials, which can be used to gain unauthorized access to systems and data. False positives might occur due to legitimate administrative tasks. Next steps include reviewing and investigating each case, given the high risk associated with potential credential dumping attacks.
how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Administrators can create memory dumps for debugging purposes, but memory dumps of the LSASS process would be unusual.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Account Discovery With Net App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a potential account discovery series of command used by several malware or attack to recon the target machine. This technique is also seen in some note worthy malware like trickbot where it runs a cmd process, or even drop its module that will execute the said series of net command. This series of command are good correlation search and indicator of attacker recon if seen in the machines within a none technical user or department (HR, finance, ceo and etc) network.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Admin or power user may used this series of command.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Active Directory Lateral Movement Identified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The primary objective of this correlation rule is to detect and alert on potential lateral movement activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Lateral Movement analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Lateral Movement analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization.
how_to_implement = Splunk Enterprise Security is required to utilize this correlation. In addition, modify the source_count value to your environment. In our testing, a count of 4 or 5 was decent in a lab, but the number may need to be increased as the analytic story includes over 30 analytics. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]}
known_false_positives = False positives will most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed.
providing_technologies = null

[savedsearch://ESCU - Active Directory Privilege Escalation Identified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The primary objective of this correlation rule is to detect and alert on potential privilege escalation activities within an organization's Active Directory (AD) environment. By identifying multiple analytics associated with the Active Directory Privilege Escalation analytic story, security analysts can gain better insight into possible threats and respond accordingly to mitigate risks. The correlation rule will trigger an alert when multiple analytics from the Active Directory Privilege Escalation analytic story are detected within a specified time frame. The rule will generate an alert if a predetermined threshold of correlated analytics is reached within the specified time frame. This threshold can be customized to suit the needs and risk appetite of the organization.
how_to_implement = Splunk Enterprise Security is required to utilize this correlation. In addition, modify the source_count value to your environment. In our testing, a count of 4 or 5 was decent in a lab, but the number may need to be increased as the analytic story includes over 30 analytics. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484"], "nist": ["DE.AE"]}
known_false_positives = False positives will most likely be present based on risk scoring and how the organization handles system to system communication. Filter, or modify as needed. In addition to count by analytics, adding a risk score may be useful. In our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. Your organization will be different, monitor and modify as needed.
providing_technologies = null

[savedsearch://ESCU - Active Setup Registry Autostart - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious modification of the active setup registry for persistence and privilege escalation. This technique was seen in several malware (poisonIvy), adware and APT to gain persistence to the compromised machine upon boot up. This TTP is a good indicator to further check the process id that do the modification since modification of this registry is not commonly done. check the legitimacy of the file and process involve in this rules to check if it is a valid setup installer that creating or modifying this registry.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.014", "T1547"], "nist": ["DE.CM"]}
known_false_positives = Active setup installer may add or modify this registry.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Add DefaultUser And Password In Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after  triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Add or Set Windows Defender Exclusion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify a suspicious process command-line related to Windows Defender exclusion feature. This command is abused by adversaries, malware authors and red teams to bypass Windows Defender Antivirus products by excluding folder path, file path, process and extensions. From its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Admin or user may choose to use this windows features. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - AdsiSearcher Account Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Allow File And Printing Sharing In Firewall - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious modification of firewall to allow file and printer sharing. This technique was seen in ransomware to be able to discover more machine connected to the compromised host to encrypt more files
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]}
known_false_positives = network admin may modify this firewall feature that may cause this rule to be triggered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a potential suspicious modification of firewall rule registry allowing inbound traffic in specific port with public profile. This technique was identified when an adversary wants to grant remote access to a machine by allowing the traffic in a firewall rule.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]}
known_false_positives = network admin may add/remove/modify public inbound firewall rule that may cause this rule to be triggered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Allow Inbound Traffic In Firewall Rule - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell command to allow inbound traffic inbound to a specific local port within the public profile. This technique was seen in some attacker want to have a remote access to a machine by allowing the traffic in firewall rule.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs  from your endpoints. make sure you enable needed registry to monitor this event.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]}
known_false_positives = administrator may allow inbound traffic in certain network or machine.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Allow Network Discovery In Firewall - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious modification to the firewall to allow network discovery on a machine. This technique was seen in couple of ransomware (revil, reddot) to discover other machine connected to the compromised host to encrypt more files.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.007", "T1562"], "nist": ["DE.CM"]}
known_false_positives = network admin may modify this firewall feature that may cause this rule to be triggered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Allow Operation with Consent Admin - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a potential privilege escalation attempt to perform malicious task. This registry modification is designed to allow the `Consent Admin` to perform an operation that requires elevation without consent or credentials. We also found this in some attacker to gain privilege escalation to the compromise machine.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Anomalous usage of 7zip - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies a 7z.exe spawned from `Rundll32.exe` or `Dllhost.exe`. It is assumed that the adversary has brought in `7z.exe` and `7z.dll`. It has been observed where an adversary will rename `7z.exe`. Additional coverage may be required to identify the behavior of renamed instances of `7z.exe`. During triage, identify the source of injection into `Rundll32.exe` or `Dllhost.exe`. Capture any files written to disk and analyze as needed. Review parallel processes for additional behaviors. Typically, archiving files will result in exfiltration.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited as this behavior is not normal for `rundll32.exe` or `dllhost.exe` to spawn and run 7zip.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Any Powershell DownloadFile - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of PowerShell downloading a file using `DownloadFile` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Command and Control"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering will need to occur by parent process or command line argument. It may be required to modify this query to an EDR product for more granular coverage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Any Powershell DownloadString - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of PowerShell downloading a file using `DownloadString` method. This particular method is utilized in many different PowerShell frameworks to download files and output to disk. Identify the source (IP/domain) and destination file and triage appropriately. If AMSI logging or PowerShell transaction logs are available, review for further details of the implant.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Command and Control"], "mitre_attack": ["T1059", "T1059.001", "T1105"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering will need to occur by parent process or command line argument. It may be required to modify this query to an EDR product for more granular coverage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Attacker Tools On Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the use of tools that are commonly exploited by cybercriminals since these tools are usually associated with malicious activities such as unauthorized access, network scanning, or data exfiltration and pose a significant threat to an organization's security infrastructure. It also provides enhanced visibility into potential security threats and helps to proactively detect and respond to mitigate the risks associated with cybercriminal activities. This detection is made by examining the process activity on the host, specifically focusing on processes that are known to be associated with attacker tool names. This detection is important because it acts as an early warning system for potential security incidents that allows you to respond to security incidents promptly. False positives might occur due to legitimate administrative activities that can resemble malicious actions. You must develop a comprehensive understanding of typical endpoint activities and behaviors within the organization to accurately interpret and respond to the alerts generated by this analytic. This ensures a proper balance between precision and minimizing false positives.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Reconnaissance"], "mitre_attack": ["T1036.005", "T1036", "T1003", "T1595"], "nist": ["DE.CM"]}
known_false_positives = Some administrator activity can be potentially triggered, please add those users to the filter macro.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Attempt To Add Certificate To Untrusted Store - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects whether a process is attempting to add a certificate to the untrusted certificate store, which might result in security tools being disabled. The detection is made by focusing on process activities and command-line arguments that are related to the 'certutil -addstore' command. This detection is important because it helps to identify attackers who might add a certificate to the untrusted certificate store to disable security tools and gain unauthorized access to a system. False positives might occur since legitimate reasons might exist for a process to add a certificate to the untrusted certificate store, such as system administration tasks. Next steps include conducting an extensive triage and investigation prior to taking any action. Additionally, you must understand the importance of trust and its subversion in system security.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.004", "T1553"], "nist": ["DE.CM"]}
known_false_positives = There may be legitimate reasons for administrators to add a certificate to the untrusted certificate store. In such cases, this will typically be done on a large number of systems.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Attempt To Stop Security Service - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects attempts to stop security-related services on the endpoint and helps to mitigate potential threats earlier, thereby minimizing the impact on the organization's security. The detection is made by using a Splunk query that searches for processes that involve the "sc.exe" command and include the phrase "stop" in their command. The query collects information such as the process name, process ID, parent process, user, destination, and timestamps. The detection is important because attempts to stop security-related services can indicate malicious activity or an attacker's attempt to disable security measures. This can impact the organization's security posture and can lead to the compromise of the endpoint and potentially the entire network. Disabling security services can allow attackers to gain unauthorized access, exfiltrate sensitive data, or launch further attacks, such as malware installation or privilege escalation. False positives might occur since there might be legitimate reasons for stopping these services in certain situations. Therefore, you must exercise caution and consider the context of the activity before taking any action. Next steps include reviewing the identified process and its associated details. You must also investigate any on-disk artifacts related to the process and review concurrent processes to determine the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = None identified. Attempts to disable security-related services should be identified and understood.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Attempted Credential Dump From Registry via Reg exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Monitor for execution of reg.exe with parameters specifying an export of keys that contain hashed credentials that attackers may try to crack offline.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]}
known_false_positives = None identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Auto Admin Logon Registry Entry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to detect a suspicious registry modification to implement auto admin logon to a host. This technique was seen in BlackMatter ransomware to automatically logon to the compromise host after  triggering a safemode boot to continue encrypting the whole network. This behavior is not a common practice and really a suspicious TTP or alert need to be consider if found within then network premise.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Batch File Write to System32 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for a batch file (.bat) written to the Windows system directory tree.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.CM"]}
known_false_positives = It is possible for this search to generate a notable event for a batch file write to a path that includes the string "system32", but is not the actual Windows system directory. As such, you should confirm the path of the batch file identified by the search. In addition, a false positive may be generated by an administrator copying a legitimate batch file in this directory tree. You should confirm that the activity is legitimate and modify the search to add exclusions, as necessary.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Bcdedit Command Back To Normal Mode Boot - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious bcdedit commandline to configure the host from safe mode back to normal boot configuration. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - BCDEdit Failure Recovery Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for flags passed to bcdedit.exe modifications to the built-in Windows error recovery boot configurations. This is typically used by ransomware to prevent recovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = Administrators may modify the boot configuration.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - BITS Job Persistence - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` scheduling a BITS job to persist on an endpoint. The query identifies the parameters used to create, resume or add a file to a BITS job. Typically seen combined in a oneliner or ran in sequence. If identified, review the BITS job created and capture any files written to disk. It is possible for BITS to be used to upload files and this may require further network data analysis to identify. You can use `bitsadmin /list /verbose` to list out the jobs during investigation.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1197"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives will be present. Typically, applications will use `BitsAdmin.exe`. Any filtering should be done based on command-line arguments (legitimate applications) or parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - BITSAdmin Download File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following query identifies Microsoft Background Intelligent Transfer Service utility `bitsadmin.exe` using the `transfer` parameter to download a remote object. In addition, look for `download` or `upload` on the command-line, the switches are not required to perform a transfer. Capture any files downloaded. Review the reputation of the IP or domain used. Typically once executed, a follow on command will be used to execute the dropped file. Note that the network connection or file modification events related will not spawn or create from `bitsadmin.exe`, but the artifacts will appear in a parallel process of `svchost.exe` with a command-line similar to `svchost.exe -k netsvcs -s BITS`. It's important to review all parallel and child processes to capture any behaviors and artifacts. In some suspicious and malicious instances, BITS jobs will be created. You can use `bitsadmin /list /verbose` to list out the jobs during investigation.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation", "Command and Control"], "mitre_attack": ["T1197", "T1105"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives, however it may be required to filter based on parent process name or network connection.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CertUtil Download With URLCache and Split Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Certutil.exe may download a file from a remote destination using `-urlcache`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. However, it is uncommon for `certutil.exe` to write files to world writeable paths.\ During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives in most environments, however tune as needed based on parent-child relationship or network connection.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Certutil.exe may download a file from a remote destination using `-VerifyCtl`. This behavior does require a URL to be passed on the command-line. In addition, `-f` (force) and `-split` (Split embedded ASN.1 elements, and save to files) will be used. It is not entirely common for `certutil.exe` to contact public IP space. \ During triage, capture any files on disk and review. Review the reputation of the remote IP or domain in question. Using `-VerifyCtl`, the file will either be written to the current working directory or `%APPDATA%\..\LocalLow\Microsoft\CryptnetUrlCache\Content\<hash>`. 
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives in most environments, however tune as needed based on parent-child relationship or network connection.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Certutil exe certificate extraction - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for arguments to certutil.exe indicating the manipulation or extraction of Certificate. This certificate can then be used to sign new authentication tokens specially inside Federated environments such as Windows ADFS.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = Unless there are specific use cases, manipulating or exporting certificates using certutil is uncommon. Extraction of certificate has been observed during attacks such as Golden SAML and other campaigns targeting Federated services.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CertUtil With Decode Argument - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = CertUtil.exe may be used to `encode` and `decode` a file, including PE and script code. Encoding will convert a file to base64 with `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` tags. Malicious usage will include decoding a encoded file that was downloaded. Once decoded, it will be loaded by a parallel process. Note that there are two additional command switches that may be used - `encodehex` and `decodehex`. Similarly, the file will be encoded in HEX and later decoded for further execution. During triage, identify the source of the file being decoded. Review its contents or execution behavior for further analysis.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1140"], "nist": ["DE.CM"]}
known_false_positives = Typically seen used to `encode` files, but it is possible to see legitimate use of `decode`. Filter based on parent-child relationship, file paths, endpoint or user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Change Default File Association - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect suspicious registry modification to change the default file association of windows to malicious payload. This technique was seen in some APT where it modify the default process to run file association, like .txt to notepad.exe. Instead notepad.exe it will point to a Script or other payload that will load malicious commands to the compromised host.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.001", "T1546"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Change To Safe Mode With Network Config - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious bcdedit commandline to configure the host to boot in safe mode with network config. This technique was seen in blackMatter ransomware where it force the compromised host to boot in safe mode to continue its encryption and bring back to normal boot using bcdedit deletevalue command. This TTP can be a good alert for host that booted from safe mode forcefully since it need to modify the boot configuration to bring it back to normal.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CHCP Command Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect execution of chcp.exe application. this utility is used to change the active code page of the console. This technique was seen in icedid malware to know the locale region/language/country of the compromise host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]}
known_false_positives = other tools or script may used this to change code page to UTF-* or others
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Check Elevated CMD using whoami - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious whoami execution to check if the cmd or shell instance process is with elevated privileges. This technique was seen in FIN7 js implant where it execute this as part of its data collection to the infected machine to check if the running shell cmd process is elevated or not. This TTP is really a good alert for known attacker that recon on the targetted host. This command is not so commonly executed by a normal user or even an admin to check if a process is elevated.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Child Processes of Spoolsv exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for child processes of spoolsv.exe. This activity is associated with a POC privilege-escalation exploit associated with CVE-2018-8440. Spoolsv.exe is the process associated with the Print Spooler service in Windows and typically runs as SYSTEM.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = Some legitimate printer-related processes may show up as children of spoolsv.exe. You should confirm that any activity as legitimate and may be added as exclusions in the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Clear Unallocated Sector Using Cipher App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to detect execution of `cipher.exe` to clear the unallocated sectors of a specific disk. This technique was seen in some ransomware to make it impossible to forensically recover deleted files.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070.004", "T1070"], "nist": ["DE.CM"]}
known_false_positives = administrator may execute this app to manage disk
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Clop Common Exec Parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytics are designed to identifies some CLOP ransomware variant that using arguments to execute its main code or feature of its code. In this variant if the parameter is "runrun", CLOP ransomware will try to encrypt files in network shares and if it is "temp.dat", it will try to read from some stream pipe or file start encrypting files within the infected local machines. This technique can be also identified as an anti-sandbox technique to make its code non-responsive since it is waiting for some parameter to execute properly.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.CM"]}
known_false_positives = Operators can execute third party tools using these parameters.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Clop Ransomware Known Service Name - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection is to identify the common service name created by the CLOP ransomware as part of its persistence and high privilege code execution in the infected machine. Ussually CLOP ransomware use StartServiceCtrlDispatcherW API in creating this service entry.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - CMD Carry Out String Command Parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies command-line arguments where `cmd.exe /c` is used to execute a program. `cmd /c` is used to run commands in MS-DOS and terminate after command or process completion. This technique is commonly seen in adversaries and malware to execute batch command using different shell like PowerShell or different process other than `cmd.exe`. This is a good hunting query for suspicious command-line made by a script or relative process execute it.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003", "T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives may be high based on legitimate scripted code in any environment. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CMD Echo Pipe - Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a common behavior by Cobalt Strike and other frameworks where the adversary will escalate privileges, either via `jump` (Cobalt Strike PTH) or `getsystem`, using named-pipe impersonation. A suspicious event will look like `cmd.exe /c echo 4sgryt3436 > \\.\Pipe\5erg53`.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1059", "T1059.003", "T1543.003", "T1543"], "nist": ["DE.CM"]}
known_false_positives = Unknown. It is possible filtering may be required to ensure fidelity.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Cmdline Tool Not Executed In CMD Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a non-standard parent process (not matching CMD, PowerShell, or Explorer) spawning `ipconfig.exe` or `systeminfo.exe`. This particular behavior was seen in FIN7's JSSLoader .NET payload. This is also typically seen when an adversary is injected into another process performing different discovery techniques. This event stands out as a TTP since these tools are commonly executed with a shell application or Explorer parent, and not by another application. This TTP is a good indicator for an adversary gathering host information, but one possible false positive might be an automated tool used by a system administator.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.CM"]}
known_false_positives = A network operator or systems administrator may utilize an automated host discovery application that may generate false positives. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CMLUA Or CMSTPLUA UAC Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a potential process using COM Object like CMLUA or CMSTPLUA to bypass UAC. This technique has been used by ransomware adversaries to gain administrative privileges to its running process.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate windows application that are not on the list loading this dll. Filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Cobalt Strike Named Pipes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of default or publicly known named pipes used with Cobalt Strike. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. Cobalt Strike uses named pipes in many ways and has default values used with the Artifact Kit and Malleable C2 Profiles. The following query assists with identifying these default named pipes. Each EDR product presents named pipes a little different. Consider taking the values and generating a query based on the product of choice. \
Upon triage, review the process performing the named pipe. If it is explorer.exe, It is possible it was injected into by another process. Review recent parallel processes to identify suspicious patterns or behaviors. A parallel process may have a network connection, review and follow the connection back to identify any file modifications.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = The idea of using named pipes with Cobalt Strike is to blend in. Therefore, some of the named pipes identified and added may cause false positives. Filter by process name or pipe name to reduce false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Common Ransomware Extensions - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects Searches for file modifications that commonly occur with Ransomware to detect modifications to files with extensions that are commonly used by Ransomware. The detection is made by searches for changes in the datamodel=Endpoint.Filesystem, specifically modifications to file extensions that match those commonly used by Ransomware. The detection is important because it suggests that an attacker is attempting to encrypt or otherwise modify files in the environment using malware, potentially leading to data loss that can cause significant damage to an organization's data and systems. False positives might occur so the SOC must investigate the affected system to determine the source of the modification and take appropriate action to contain and remediate the attack.
how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint Filesystem data model node. To see the additional metadata, add the following fields, if not already present, please review the detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"]}
known_false_positives = It is possible for a legitimate file with these extensions to be created. If this is a true ransomware attack, there will be a large number of files created with these extensions.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Common Ransomware Notes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for files created with names matching those typically used in ransomware notes that tell the victim how to get their data back.
how_to_implement = You must be ingesting data that records file-system activity from your hosts to populate the Endpoint Filesystem data-model node. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or via other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report file-system reads and writes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a legitimate file could be created with the same name used by ransomware note files.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - ConnectWise ScreenConnect Path Traversal - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers.
how_to_implement = This analytic utilizes the Endpoint datamodel Filesystem node to identify path traversal attempts against ScreenConnect. Note that using SACL auditing or other file system monitoring tools may also be used to detect path traversal attempts. Typically the data for this analytic will come from EDR or other properly CIM mapped data sources.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected, as the detection is based on the presence of file system events that indicate path traversal attempts. The analytic may be modified to look for any file writes to this path as it is not common for files to write here.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - ConnectWise ScreenConnect Path Traversal Windows SACL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1708 vulnerability utilizing Windows SACL EventCode 4663, which allows an attacker to perform path traversal attacks by manipulating the file_path and file_name parameters in the URL. The vulnerability, identified as critical with a CVSS score of 9.8, enables unauthorized users to access sensitive files and directories on the host system, potentially leading to the exfiltration of sensitive data or the execution of arbitrary code. The search query provided looks for file system events that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers.
how_to_implement = To implement the following query, enable SACL auditing for the ScreenConnect directory(ies). With this data, the following analytic will work correctly. A GIST is provided in the references to assist with enabling SACL Auditing.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as the analytic is specific to ScreenConnect path traversal attempts. Tune as needed, or restrict to specific hosts if false positives are encountered.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Conti Common Exec parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search detects the suspicious commandline argument of revil ransomware to encrypt specific or all local drive and network shares of the compromised machine or host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.CM"]}
known_false_positives = 3rd party tool may have commandline parameter that can trigger this detection.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Control Loading from World Writable Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies control.exe loading either a .cpl or .inf from a writable directory. This is related to CVE-2021-40444. During triage, review parallel processes, parent and child, for further suspicious behaviors. In addition, capture file modifications and analyze.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.002"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives will be present as control.exe does not natively load from writable paths as defined. One may add .cpl or .inf to the command-line if there is any false positives. Tune as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Create local admin accounts using net exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of local administrator accounts using the net.exe command to mitigate the risks associated with unauthorized access and prevent further damage to the environment by responding to potential threats earlier and taking appropriate actions to protect the organization's systems and data. This detection is made by a Splunk query to search for processes with the name net.exe or net1.exe that include the "/add" parameter and have specific keywords related to administrator accounts in their process name. This detection is important because the creation of unauthorized local administrator accounts might indicate that an attacker has successfully created a new administrator account and is trying to gain persistent access to a system or escalate their privileges for data theft, or other malicious activities. False positives might occur since there might be legitimate uses of the net.exe command and the creation of administrator accounts in certain circumstances. You must consider the context of the activity and other indicators of compromise before taking any action. For next steps, review the details of the identified process, including the user, parent process, and parent process name. Examine any relevant on-disk artifacts and look for concurrent processes to determine the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]}
known_false_positives = Administrators often leverage net.exe to create admin accounts.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Create or delete windows shares using net exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation or deletion of hidden shares using the net.exe command for prompt response and mitigation to enhance the overall security posture of the organization and protect against potential data breaches, malware infections, and other damaging outcomes. This detection is made by searching for processes that involve the use of net.exe and filters for actions related to creation or deletion of shares. This detection is important because it suggests that an attacker is attempting to manipulate or exploit the network by creating or deleting hidden shares. The creation or deletion of hidden shares can indicate malicious activity since attackers might use hidden shares to exfiltrate data, distribute malware, or establish persistence within a network. The impact of such an attack can vary, but it often involves unauthorized access to sensitive information, disruption of services, or the introduction of malware. False positives might occur since legitimate actions can also involve the use of net.exe. An extensive triage and investigation is necessary to determine the intent and nature of the detected activity. Next steps include reviewing the details of the process involving the net.exe command, including the user, parent process, and timestamps during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.005"], "nist": ["DE.CM"]}
known_false_positives = Administrators often leverage net.exe to create or delete network shares. You should verify that the activity was intentional and is legitimate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Create Remote Thread In Shell Application - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect suspicious process injection in command shell. This technique was seen in IcedID where it execute cmd.exe process to inject its shellcode as part of its execution as banking trojan. It is really uncommon to have a create remote thread execution in the following application.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Create Remote Thread into LSASS - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The following analytic detects the creation of a remote thread in the Local Security Authority Subsystem Service (LSASS), which is a common tactic used by adversaries to steal user authentication credentials, known as credential dumping. The detection is made by leveraging Sysmon Event ID 8 logs and searches for processes that create remote threads in lsass.exe. This is an unusual activity that is generally linked to credential theft or credential dumping, which is a significant threat to network security. The detection is important because it helps to detect potential credential dumping attacks, which can result in significant damage to an organization's security. False positives might occur though the confidence level of this alert is high. There might be cases where legitimate tools can access LSASS and generate similar logs. Therefore, you must understand the broader context of such events and differentiate between legitimate activities and possible threats.
how_to_implement = This search needs Sysmon Logs with a Sysmon configuration, which includes EventCode 8 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Other tools can access LSASS for legitimate reasons and generate an event. In these cases, tweaking the search may help eliminate noise.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Creation of lsass Dump with Taskmgr - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = Detect the hands on keyboard behavior of Windows Task Manager creating a process dump of lsass.exe. Upon this behavior occurring, a file write/modification will occur in the users profile under \AppData\Local\Temp. The dump file, lsass.dmp, cannot be renamed, however if the dump occurs more than once, it will be named lsass (2).dmp.
how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 11 for detecting file create of lsass.dmp. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Administrators can create memory dumps for debugging purposes, but memory dumps of the LSASS process would be unusual.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Creation of Shadow Copy - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Monitor for signs that Vssadmin or Wmic has been used to create a shadow copy.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate administrator usage of Vssadmin or Wmic will create false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Creation of Shadow Copy with wmic and powershell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the use of two specific tools, wmic and Powershell, to create a shadow copy to identify potential threats earlier and take appropriate actions to mitigate the risks. This detection is made by a Splunk query that searches for processes in the Endpoint.Processes data model where either the process name contains "wmic" or "Powershell" and the process command contains "shadowcopy" and "create". This detection is important because it suggests that an attacker is attempting to manipulate or access data in an unauthorized manner, which can lead to data theft, data manipulation, or other malicious activities. Attackers might use shadow copies to backup and exfiltrate sensitive data or to hide their tracks by restoring files to a previous state after an attack. Next steps include reviewing the user associated with the process, the process name, the original file name, the process command, and the destination of the process. Additionally, examine any relevant on-disk artifacts and review other concurrent processes to determine the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Legtimate administrator usage of wmic to create a shadow copy.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Credential Dumping via Copy Command from Shadow Copy - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the use of the copy command to dump credentials from a shadow copy so that you can detect potential threats earlier and mitigate the risks associated with credential dumping. The detection is made by using a Splunk query to search for specific processes that indicate credential dumping activity. The query looks for processes with command lines that include references to certain files, such as "sam", "security", "system", and "ntds.dit", located in system directories like "system32" or "windows". The detection is important because it suggests that an attacker is attempting to extract credentials from a shadow copy. Credential dumping is a common technique used by attackers to obtain sensitive login information and gain unauthorized access to systems to escalate privileges, move laterally within the network, or gain unauthorized access to sensitive data. False positives might occur since legitimate processes might also reference these files. During triage, it is crucial to review the process details, including the source and the command that is run. Additionally, you must capture and analyze any relevant on-disk artifacts and investigate concurrent processes to determine the source of the attack
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Credential Dumping via Symlink to Shadow Copy - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of a symlink to a shadow copy to identify potential threats earlier and mitigate the risks associated with symlink creation to shadow copies.  The detection is made by using a Splunk query that searches for processes with commands containing "mklink" and "HarddiskVolumeShadowCopy". This analytic retrieves information such as the destination, user, process name, process ID, parent process, original file name, and parent process ID from the Endpoint.Processes data model.  The detection is important because it indicates potential malicious activity since attackers might use this technique to manipulate or delete shadow copies, which are used for system backup and recovery. This detection helps to determine if an attacker is attempting to cover their tracks or prevent data recovery in the event of an incident. The impact of such an attack can be significant since it can hinder incident response efforts, prevent data restoration, and potentially lead to data loss or compromise. Next steps include reviewing the details of the process, such as the destination and the user responsible for creating the symlink. Additionally, you must examine the parent process, any relevant on-disk artifacts, and concurrent processes to identify the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - CSC Net On The Fly Compilation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this analytic is to detect a suspicious compile before delivery approach of .net compiler csc.exe. This technique was seen in several adversaries, malware and even in red teams to take advantage the csc.exe .net compiler tool to compile on the fly a malicious .net code to evade detection from security product. This is a good hunting query to check further the file or process created after this event and check the file path that passed to csc.exe which is the .net code. Aside from that, powershell is capable of using this compiler in executing .net code in a powershell script so filter on that case is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.004", "T1027"], "nist": ["DE.AE"]}
known_false_positives = A network operator or systems administrator may utilize an automated powershell script taht execute .net code that may generate false positive. filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Curl Download and Bash Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of curl on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, however filtering may be required.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Delete ShadowCopy With PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This following analytic detects PowerShell command to delete shadow copy using the WMIC PowerShell module. This technique was seen used by a recent adversary to deploy DarkSide Ransomware where it executed a child process of PowerShell to execute a hex encoded command to delete shadow copy. This hex encoded command was able to be decrypted by PowerShell log.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs  from your endpoints. make sure you enable needed registry to monitor this event.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Deleting Of Net Users - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will detect a suspicious net.exe/net1.exe command-line to delete a user on a system. This technique may be use by an administrator for legitimate purposes, however this behavior has been used in the wild to impair some user or deleting adversaries tracks created during its lateral movement additional systems. During triage, review parallel processes for additional behavior. Identify any other user accounts created before or after.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.CM"]}
known_false_positives = System administrators or scripts may delete user accounts via this technique. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Deleting Shadow Copies - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The vssadmin.exe utility is used to interact with the Volume Shadow Copy Service.  Wmic is an interface to the Windows Management Instrumentation.  This search looks for either of these tools being used to delete shadow copies.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = vssadmin.exe and wmic.exe are standard applications shipped with modern versions of windows. They may be used by administrators to legitimately delete old backup copies, although this is typically rare.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect AzureHound Command-Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the common command-line argument used by AzureHound `Invoke-AzureHound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = Unknown.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect AzureHound File Modifications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is similar to SharpHound file modifications, but this instance covers the use of Invoke-AzureHound. AzureHound is the SharpHound equivilent but for Azure. It's possible this may never be seen in an environment as most attackers may execute this tool remotely. Once execution is complete, a zip file with a similar name will drop `20210601090751-azurecollection.zip`. In addition to the zip, multiple .json files will be written to disk, which are in the zip.
how_to_implement = To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as the analytic is specific to a filename with extension .zip. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Baron Samedit CVE-2021-3156 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a specific type of vulnerability known as a heap-based buffer overflow in the sudoedit command, commonly referred to as Baron Samedit CVE-2021-3156. The detection is made by a Splunk query that searches for instances of the sudoedit command with the "-s" flag followed by a double quote. This combination of parameters is indicative of the vulnerability being exploited. The detection is important because it suggests that an attacker is attempting to exploit the Baron Samedit vulnerability. The Baron Samedit vulnerability allows an attacker to gain elevated privileges on a Linux system and run arbitrary code with root privileges, potentially leading to complete control over the affected system. The impact of a successful attack can be severe since it allows the attacker to bypass security measures and gain unauthorized access to sensitive data or systems. This can result in data breaches, unauthorized modifications, or even complete system compromise. Next steps include being aware of this vulnerability and actively monitoring any attempts to exploit it. By detecting and responding to such attacks in a timely manner, you can prevent or minimize the potential damage caused by the heap-based buffer overflow of sudoedit.
how_to_implement = Splunk Universal Forwarder running on Linux systems, capturing logs from the /var/log directory. The vulnerability is exposed when a non privledged user tries passing in a single \ character at the end of the command while using the shell and edit flags.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Detect Baron Samedit CVE-2021-3156 Segfault - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the occurrence of a heap-based buffer overflow in sudoedit.The detection is made by using a Splunk query to identify Linux hosts where the terms "sudoedit" and "segfault" appear in the logs. The detection is important because the heap-based buffer overflow vulnerability in sudoedit can be exploited by attackers to gain elevated root privileges on a vulnerable system, which might lead to the compromise of sensitive data, unauthorized access, and other malicious activities. False positives might occur. Therefore, you must review the logs and investigate further before taking any action.
how_to_implement = Splunk Universal Forwarder running on Linux systems (tested on Centos and Ubuntu), where segfaults are being logged.  This also captures instances where the exploit has been compiled into a binary. The detection looks for greater than 5 instances of sudoedit combined with segfault over your search time period on a single host
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = If sudoedit is throwing segfaults for other reasons this will pick those up too.
providing_technologies = null

[savedsearch://ESCU - Detect Baron Samedit CVE-2021-3156 via OSQuery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the heap-based buffer overflow for the sudoedit command and identifies instances where the command "sudoedit -s *" is run using the osquery_process data source. This indicates that the sudoedit command is used with the "-s" flag, which is associated with the heap-based buffer overflow vulnerability. The detection is important because it indicates a potential security vulnerability, specifically Baron Samedit CVE-2021-3156, which helps to identify and respond to potential heap-based buffer overflow attacks to enhance the security posture of the organization. This vulnerability allows an attacker to escalate privileges and potentially gain unauthorized access to the system. If the attack is successful, the attacker can gain full control of the system, run arbitrary code, or access sensitive data. Such attacks can lead to data breaches, unauthorized access, and potential disruption of critical systems. False positives might occur since the legitimate use of the sudoedit command with the "-s" flag can also trigger this detection. You must carefully review and validate the findings before taking any action. Next steps include investigating all true positive detections promptly, reviewing the associated processes, gather relevant artifacts, identifying the source of the attack to contain the threat, mitigate the risks, and prevent further damage to the environment.
how_to_implement = OSQuery installed and configured to pick up process events (info at https://osquery.io) as well as using the Splunk OSQuery Add-on https://splunkbase.splunk.com/app/4402. The vulnerability is exposed when a non privledged user tries passing in a single \ character at the end of the command while using the shell and edit flags.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Detect Certify Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when the attacker tool Certify or Certipy are used to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments of these tools are similar and perform near identical enumeration or exploitation functions.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Command and Control"], "mitre_attack": ["T1649", "T1105"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Certify With PowerShell Script Block Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when the attacker tool  Certify is used through an in-memory PowerShell function to enumerate Active Directory Certificate Services (AD CS) environments. The default command line arguments for the binary version of this tools are similar to PowerShell calls and perform near identical enumeration or exploitation functions.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell..
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1649", "T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = Unknown, partial script block matches.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect Certipy File Modifications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when the attacker tool Certipy is used to enumerate Active Directory Certificate Services (AD CS) environments. The default behavior of this toolkit drops a number of file uniquely named files or file extensions related to it's information gathering and exfiltration process.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints as well as file creation or deletion events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649", "T1560"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Computer Changed with Anonymous Account - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search looks for Event Code 4742 (Computer Change) or EventCode 4624 (An account was successfully logged on) with an anonymous account.
how_to_implement = This search requires audit computer account management to be enabled on the system in order to generate Event ID 4742. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Event Logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1210"], "nist": ["DE.AE"]}
known_false_positives = None thus far found
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect Copy of ShadowCopy with Script Block Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies `copy` or `[System.IO.File]::Copy` being used to capture the SAM, SYSTEM or SECURITY hives identified in script block. This will catch the most basic use cases for credentials being taken for offline cracking. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives as the scope is limited to SAM, SYSTEM and SECURITY hives.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect Credential Dumping through LSASS access - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The following analytic detects the reading of lsass memory, which is consistent with credential dumping. Reading lsass memory is a common technique used by attackers to steal credentials from the Windows operating system. The detection is made by monitoring the sysmon events and filtering for specific access permissions (0x1010 and 0x1410) on the lsass.exe process helps identify potential instances of credential dumping.The detection is important because it suggests that an attacker is attempting to extract credentials from the lsass memory, which can lead to unauthorized access, data breaches, and compromise of sensitive information. Credential dumping is often a precursor to further attacks, such as lateral movement, privilege escalation, or data exfiltration. False positives can occur due to legitimate actions that involve accessing lsass memory. Therefore, extensive triage and investigation are necessary to differentiate between malicious and benign activities.
how_to_implement = This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 10 with lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = The activity may be legitimate. Other tools can access lsass for legitimate reasons, and it's possible this event could be generated in those cases. In these cases, false positives should be fairly obvious and you may need to tweak the search to eliminate noise.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Detect Empire with PowerShell Script Block Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies the common PowerShell stager used by PowerShell-Empire. Each stager that may use PowerShell all uses the same pattern. The initial HTTP will be base64 encoded and use `system.net.webclient`. Note that some obfuscation may evade the analytic. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may only pertain to it not being related to Empire, but another framework. Filter as needed if any applications use the same pattern.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect Excessive Account Lockouts From Endpoint - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search identifies endpoints that have caused a relatively high number of account lockouts in a short period.
how_to_implement = You must ingest your Windows security event logs in the `Change` datamodel under the nodename is `Account_Management`, for this search to execute successfully. Please consider updating the cron schedule and the count of lockouts you want to monitor, according to your environment. \
 **Splunk>Phantom Playbook Integration**\
If Splunk>Phantom is also configured in your environment, a Playbook called "Excessive Account Lockouts Enrichment and Response" can be configured to run when any results are found by this detection search. The Playbook executes the Contextual and Investigative searches in this Story, conducts additional information gathering on Windows endpoints, and takes a response action to shut down the affected endpoint. To use this integration, install the Phantom App for Splunk `https://splunkbase.splunk.com/app/3411/`, add the correct hostname to the "Phantom Instance" field in the Adaptive Response Actions when configuring this detection search, and set the corresponding Playbook to active. \
(Playbook Link:`https://my.phantom.us/4.1/playbook/excessive-account-lockouts-enrichment-and-response/`).\

annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.AE"]}
known_false_positives = It's possible that a widely used system, such as a kiosk, could cause a large number of account lockouts.
providing_technologies = null

[savedsearch://ESCU - Detect Excessive User Account Lockouts - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = This search detects user accounts that have been locked out a relatively high number of times in a short period.
how_to_implement = ou must ingest your Windows security event logs in the `Change` datamodel under the nodename is `Account_Management`, for this search to execute successfully. Please consider updating the cron schedule and the count of lockouts you want to monitor, according to your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.003"], "nist": ["DE.AE"]}
known_false_positives = It is possible that a legitimate user is experiencing an issue causing multiple account login failures leading to lockouts.
providing_technologies = null

[savedsearch://ESCU - Detect Exchange Web Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell and ProxyNotShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505", "T1505.003", "T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect HTML Help Renamed - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a renamed instance of hh.exe (HTML Help) executing a Compiled HTML Help (CHM). This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Validate it is the legitimate version of hh.exe by reviewing the PE metadata. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.AE"]}
known_false_positives = Although unlikely a renamed instance of hh.exe will be used legitimately, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect HTML Help Spawn Child Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) that spawns a child process. This particular technique will load Windows script code from a compiled help file. CHM files may contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review child process events and investigate further. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications (ex. web browsers) may spawn a child process. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect HTML Help URL in Command Line - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file from a remote url. This particular technique will load Windows script code from a compiled help file. CHM files may  contain nearly any file type embedded, but only execute html/htm. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. Review reputation of remote IP and domain. Some instances, it is worth decompiling the .chm file to review its original contents. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may retrieve a CHM remotely, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect HTML Help Using InfoTech Storage Handlers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies hh.exe (HTML Help) execution of a Compiled HTML Help (CHM) file using InfoTech Storage Handlers. This particular technique will load Windows script code from a compiled help file, using InfoTech Storage Handlers. itss.dll will load upon execution. Three InfoTech Storage handlers are supported - ms-its, its, mk:@MSITStore. ITSS may be used to launch a specific html/htm file from within a CHM file. CHM files may contain nearly any file type embedded. Upon a successful execution, the following script engines may be used for execution - JScript, VBScript, VBScript.Encode, JScript.Encode, JScript.Compact. Analyst may identify vbscript.dll or jscript.dll loading into hh.exe upon execution. The "htm" and "html" file extensions were the only extensions observed to be supported for the execution of Shortcut commands or WSH script code. During investigation, identify script content origination. hh.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.001"], "nist": ["DE.CM"]}
known_false_positives = It is rare to see instances of InfoTech Storage Handlers being used, but it does happen in some legitimate instances. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \
This analytic identifies common Mimikatz functions that may be identified in the script block, including `mimikatz`. This will catch the most basic use cases for Pass the Ticket, Pass the Hash and `-DumprCreds`. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1003", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as the commands being identifies are quite specific to EventCode 4104 and Mimikatz. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect mshta inline hta execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies "mshta.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "mshta.exe" and its parent process.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect mshta renamed - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies renamed instances of mshta.exe executing. Mshta.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. This analytic utilizes the internal name of the PE to identify if is the legitimate mshta binary. Further analysis should be performed to review the executed content and validation it is the real mshta.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.AE"]}
known_false_positives = Although unlikely, some legitimate applications may use a moved copy of mshta.exe, but never renamed, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect MSHTA Url in Command Line - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies when Microsoft HTML Application Host (mshta.exe) utility is used to make remote http connections. Adversaries may use mshta.exe to proxy the download and execution of remote .hta files. The analytic identifies command line arguments of http and https being used. This technique is commonly used by malicious software to bypass preventative controls. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]}
known_false_positives = It is possible legitimate applications may perform this behavior and will need to be filtered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect New Local Admin account - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The following analytic detects the creation of new accounts that have been elevated to local administrators so that you can take immediate action to mitigate the risks and prevent further unauthorized access or malicious activities. This detection is made by using the Splunk query `wineventlog_security` EventCode=4720 OR (EventCode=4732 Group_Name=Administrators) to search for relevant security events in the Windows event log. When a new account is created or an existing account is added to the Administrators group, this analytic identifies this behavior by looking for EventCode 4720 (A user account was created) or EventCode 4732 (A member was added to a security-enabled global group). This analytic specifically focuses on events where the Group_Name is set to Administrators. This detection is important because it suggests that an attacker has gained elevated privileges and can perform malicious actions with administrative access. This can lead to significant impact, such as unauthorized access to sensitive data, unauthorized modifications to systems or configurations, and potential disruption of critical services. identifying this behavior is crucial for a Security Operations Center (SOC). Next steps include reviewing the details of the security event, including the user account that was created or added to the Administrators group. Also, examine the time span between the first and last occurrence of the event to determine if the behavior is ongoing. Additionally, consider any contextual information, such as the destination where the account was created or added to understand the scope and potential impact of the attack.
how_to_implement = You must be ingesting Windows event logs using the Splunk Windows TA and collecting event code 4720 and 4732
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]}
known_false_positives = The activity may be legitimate. For this reason, it's best to verify the account with an administrator and ask whether there was a valid service request for the account creation. If your local administrator group name is not "Administrators", this search may generate an excessive number of false positives
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Detect Outlook exe writing a zip file - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for execution of process `outlook.exe` where the process is writing a `.zip` file to the disk.
how_to_implement = You must be ingesting data that records filesystem and process activity from your hosts to populate the Endpoint data model. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or endpoint data sources, such as Sysmon.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = It is not uncommon for outlook to write legitimate zip files to the disk.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Path Interception By Creation Of program exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The detection Detect Path Interception By Creation Of program exe is detecting the abuse of unquoted service paths, which is a popular technique for privilege escalation. 
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.009", "T1574"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect processes used for System Network Configuration Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for fast execution of processes used for system network configuration discovery on the endpoint.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016"], "nist": ["DE.CM"]}
known_false_positives = It is uncommon for normal users to execute a series of commands used for network discovery. System administrators often use scripts to execute these commands. These can generate false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Prohibited Applications Spawning cmd exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for executions of cmd.exe spawned by a process that is often abused by attackers and that does not typically launch cmd.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.AE"]}
known_false_positives = There are circumstances where an application may legitimately execute and interact with the Windows command-line interface. Investigate and modify the lookup file, as appropriate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect PsExec With accepteula Flag - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for events where `PsExec.exe` is run with the `accepteula` flag in the command line. PsExec is a built-in Windows utility that enables you to execute processes on other systems. It is fully interactive for console applications. This tool is widely used for launching interactive command prompts on remote systems. Threat actors leverage this extensively for executing code on compromised systems. If an attacker is running PsExec for the first time, they will be prompted to accept the end-user license agreement (EULA), which can be passed as the argument `accepteula` within the command line.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators can leverage PsExec for accessing remote systems and might pass `accepteula` as an argument if they are running this tool for the first time. However, it is not likely that you'd see multiple occurrences of this event on a machine
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Rare Executables - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search will return a table of processes in the a given window, remove process names which are in the allowed list and list out the top 30 rare processes discovered on different hosts.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Some legitimate processes may be only rarely executed in your environment. As these are identified, update `rare_process_allow_list_local.csv` to filter them out of your search results.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect RClone Command-Line Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies commonly used command-line arguments used by `rclone.exe` to initiate a file transfer. Some arguments were negated as they are specific to the configuration used by adversaries. In particular, an adversary may list the files or directories of the remote file share using `ls` or `lsd`, which is not indicative of malicious behavior. During triage, at this stage of a ransomware event, exfiltration is about to occur or has already. Isolate the endpoint and continue investigating by review file modifications and parallel processes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this is restricted to the Rclone process name. Filter or tune the analytic as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Regasm Spawning a Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies regasm.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Regasm with Network Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies regasm.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances of regasm.exe with a network connection may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Detect Regasm with no Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies regasm.exe with no command line arguments. This particular behavior occurs when another process injects into regasm.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in `C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe` and `C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe`.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances of regasm.exe or may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Regsvcs Spawning a Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies regsvcs.exe spawning a process. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. Spawning of a child process is rare from either process and should be investigated further. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances of regasm.exe or regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Regsvcs with Network Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies Regsvcs.exe with a network connection to a public IP address, exluding private IP space. This particular technique has been used in the wild to bypass application control products. Regasm.exe and Regsvcs.exe are signed by Microsoft. By contacting a remote Command And Control server, the adversary will have the ability to escalate privileges and complete the objectives. During investigation, identify and retrieve the content being loaded. Review parallel processes for additional suspicious behavior. Gather any other file modifications and review accordingly. Review the reputation of the remote IP or domain and block as needed. regsvcs.exe and regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances of regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Detect Regsvcs with No Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies regsvcs.exe with no command line arguments. This particular behavior occurs when another process injects into regsvcs.exe, no command line arguments will be present. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Regasm.exe are natively found in C:\Windows\Microsoft.NET\Framework\v*\regasm|regsvcs.exe and C:\Windows\Microsoft.NET\Framework64\v*\regasm|regsvcs.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.009"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances of regsvcs.exe may cause a false positive. Filter based endpoint usage, command line arguments, or process lineage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Regsvr32 Application Control Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. Regsvr32.exe is also a Microsoft signed binary.This variation of the technique is often referred to as a "Squiblydoo" attack. \
Upon investigating, look for network connections to remote destinations (internal or external). Be cautious to modify the query to look for "scrobj.dll", the ".dll" is not required to load scrobj. "scrobj.dll" will be loaded by "regsvr32.exe" upon execution. 
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives related to third party software registering .DLL's.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Remote Access Software Usage File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when a file from a known remote access software is written to disk within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the file path, file name, and the user that created the file. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Filesystem` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = Known or approved applications used by the organization or usage of built-in functions.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Remote Access Software Usage FileInfo - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when process with file or code signing attributes from a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = This analytic relies on Sysmon to be properly installed and utilized in the environment. Ensure that proper logging is setup for Sysmon and data is being ingested into Splunk.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = Known or approved applications used by the organization or usage of built-in functions.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Detect Remote Access Software Usage Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when a known remote access software is executed within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Renamed 7-Zip - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies renamed 7-Zip usage using Sysmon. At this stage of an attack, review parallel processes and file modifications for data that is staged or potentially have been exfiltrated. This analytic utilizes the OriginalFileName to capture the renamed process. During triage, validate this is the legitimate version of `7zip` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]}
known_false_positives = Limited false positives, however this analytic will need to be modified for each environment if Sysmon is not used.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Renamed PSExec - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies renamed instances of `PsExec.exe` being utilized on an endpoint. Most instances, it is highly probable to capture `Psexec.exe` or other SysInternal utility usage with the command-line argument of `-accepteula`. During triage, validate this is the legitimate version of `PsExec` by reviewing the PE metadata. In addition, review parallel processes for further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]}
known_false_positives = Limited false positives should be present. It is possible some third party applications may use older versions of PsExec, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Renamed RClone - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the usage of `rclone.exe`, renamed, being used to exfiltrate data to a remote destination. RClone has been used by multiple ransomware groups to exfiltrate data. In many instances, it will be downloaded from the legitimate site and executed accordingly. During triage, isolate the endpoint and begin to review parallel processes for additional behavior. At this stage, the adversary may have staged data to be exfiltrated.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1020"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited as this analytic identifies renamed instances of `rclone.exe`. Filter as needed if there is a legitimate business use case.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Renamed WinRAR - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analtyic identifies renamed instances of `WinRAR.exe`. In most cases, it is not common for WinRAR to be used renamed, however it is common to be installed by a third party application and executed from a non-standard path. During triage, validate additional metadata from the binary that this is `WinRAR`. Review parallel processes and file modifications.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]}
known_false_positives = Unknown. It is possible third party applications use renamed instances of WinRAR.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect RTLO In File Name - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse.
how_to_implement = To successfully implement this search you need to be ingesting information on process that includes the full command line of the process being launched on your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"]}
known_false_positives = Implementation in regions that use right to left in native language.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect RTLO In Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is used to detect the abuse of the right-to-left override (RTLO or RLO) character (U+202E) RTLO. This technique is used by adversaries to disguise a string and/or file name to make it appear benign. The RTLO character is a non-printing Unicode character that causes the text that follows it to be displayed in reverse.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.002", "T1036"], "nist": ["DE.CM"]}
known_false_positives = Implementation in regions that use right to left in native language.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Rundll32 Application Control Bypass - advpack - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe loading advpack.dll and ieadvpack.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may use advpack.dll or ieadvpack.dll, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Rundll32 Application Control Bypass - setupapi - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe loading setupapi.dll and iesetupapi.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may use setupapi triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Rundll32 Application Control Bypass - syssetup - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe loading syssetup.dll by calling the LaunchINFSection function on the command line. This particular technique will load script code from a file. Upon a successful execution, the following module loads may occur - clr.dll, jscript.dll and scrobj.dll. During investigation, identify script content origination. Generally, a child process will spawn from rundll32.exe, but that may be bypassed based on script code contents. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, review any network connections and obtain the script content executed. It's possible other files are on disk.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may use syssetup.dll, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Rundll32 Inline HTA Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies "rundll32.exe" execution with inline protocol handlers. "JavaScript", "VBScript", and "About" are the only supported options when invoking HTA content directly on the command-line. This type of behavior is commonly observed with fileless malware or application whitelisting bypass techniques. The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "rundll32.exe" and its parent process.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect SharpHound Command-Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies common command-line arguments used by SharpHound `-collectionMethod` and `invoke-bloodhound`. Being the script is FOSS, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. This analytic works to identify the common command-line attributes used. It does not cover the entirety of every argument in order to avoid false positives.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as the arguments used are specific to SharpHound. Filter as needed or add more command-line arguments as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect SharpHound File Modifications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = SharpHound is used as a reconnaissance collector, ingestor, for BloodHound. SharpHound will query the domain controller and begin gathering all the data related to the domain and trusts. For output, it will drop a .zip file upon completion following a typical pattern that is often not changed. This analytic focuses on the default file name scheme. Note that this may be evaded with different parameters within SharpHound, but that depends on the operator. `-randomizefilenames` and `-encryptzip` are two examples. In addition, executing SharpHound via .exe or .ps1 without any command-line arguments will still perform activity and dump output to the default filename. Example default filename `20210601181553_BloodHound.zip`. SharpHound creates multiple temp files following the same pattern `20210601182121_computers.json`, `domains.json`, `gpos.json`, `ous.json` and `users.json`. Tuning may be required, or remove these json's entirely if it is too noisy. During traige, review parallel processes for further suspicious behavior. Typically, the process executing the `.ps1` ingestor will be PowerShell.
how_to_implement = To successfully implement this search you need to be ingesting information on file modifications that include the name of the process, and file, responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as the analytic is specific to a filename with extension .zip. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect SharpHound Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies SharpHound binary usage by using the original filena,e. In addition to renaming the PE, other coverage is available to detect command-line arguments. This particular analytic looks for the original_file_name of `SharpHound.exe` and the process name. It is possible older instances of SharpHound.exe have different original filenames. Dependent upon the operator, the code may be re-compiled and the attributes removed or changed to anything else. During triage, review the metadata of the binary in question. Review parallel processes for suspicious behavior. Identify the source of this binary.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this is specific to a file attribute not used by anything else. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect suspicious processnames using pretrained model in DSDL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses a pre-trained Deep Learning model to predict whether a processname is suspicious or not. Malwares and malicious programs such as ransomware often use tactics, techniques, and procedures (TTPs) such as copying malicious files to the local machine to propagate themselves across the network. A key indicator of compromise is that after a successful execution of the malware, it copies itself as an executable file with a randomly generated filename and places this file in one of the directories. Such techniques are seen in several malwares such as TrickBot. We develop machine learning model that uses a Recurrent Neural Network (RNN) to distinguish between malicious and benign processnames. The model is trained independently and is then made available for download. We use a character level RNN to classify malicious vs. benign processnames. The higher is_malicious_prob, the more likely is the processname to be suspicious (between [0,1]). The threshold for flagging a processname as suspicious is set as 0.5.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if a suspicious processname is similar to a benign processname.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for the execution of the cscript.exe or wscript.exe processes, with a parent of cmd.exe. The search will return the count, the first and last time this execution was seen on a machine, the user, and the destination of the machine
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.CM"]}
known_false_positives = This detection may also be triggered by legitimate applications and numerous service accounts, which often end with a $ sign. To manage this, it's advised to check the service account's activities and, if they are valid, modify the filter macro to exclude them.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect Webshell Exploit Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is used to detect the abuse of web applications by adversaries. Adversaries may install a backdoor or script onto web servers by exploiting known vulnerabilities or misconfigruations. Web shells are used to establish persistent access to systems and provide a set of executable functions or a command-line interface on the system hosting the Web server.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate OS functions called by vendor applications, baseline the environment and filter before enabling. Recommend throttle by dest/process_name
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect WMI Event Subscription Persistence - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation.  WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions.\
All event subscriptions have three components \
1. Filter - WQL Query for the events we want. EventID equals 19 \
1. Consumer - An action to take upon triggering the filter. EventID equals 20 \
1. Binding - Registers a filter to a consumer. EventID equals 21 \
Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription.
how_to_implement = To successfully implement this search, you need to be ingesting logs with that provide WMI Event Subscription from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA and have enabled EventID 19, 20 and 21. Tune and filter known good to limit the volume.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.003", "T1546"], "nist": ["DE.CM"]}
known_false_positives = It is possible some applications will create a consumer and may be required to be filtered. For tuning, add any additional LOLBin's for further depth of coverage.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Detection of tools built by NirSoft - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for specific command-line arguments that may indicate the execution of tools made by Nirsoft, which are legitimate, but may be abused by attackers.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1072"], "nist": ["DE.CM"]}
known_false_positives = While legitimate, these NirSoft tools are prone to abuse. You should verfiy that the tool was used for a legitimate purpose.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable AMSI Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to identify modification in registry to disable AMSI windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = network operator may disable this feature of windows but not so common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Defender AntiVirus Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable windows defender product
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Defender BlockAtFirstSeen Feature - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the BlockAtFirstSeen feature where it blocks suspicious files the first time seen on the host.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable windows defender product
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Defender Enhanced Notification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is intended to detect a suspicious modification of registry to disable windows defender features. This technique attempts to bypass or evade detection from Windows Defender AV, specifically the Enhanced Notification feature where a user or admin would receive alerts.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = user may choose to disable windows defender AV
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Defender MpEngine Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This particular behavior is typically executed when an adversary or malware gains access to an endpoint and begins to perform execution and to evade detections. Usually, a batch (.bat) file will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable windows defender product
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Defender Spynet Reporting - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is intended to detect a suspicious modification of registry to disable Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV product, specifically the spynet reporting for Defender telemetry.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable windows defender product
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Defender Submit Samples Consent Feature - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is intended to detect a suspicious modification of the Windows registry to disable a Windows Defender feature. This technique is intended to bypass or evade detection from Windows Defender AV, specifically the feature that submits samples for further analysis.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable windows defender product
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable ETW Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identify modification in registry to disable ETW windows feature to evade detections. This technique was seen in several ransomware, RAT and even APT to impaire defenses of the compromise machine and to be able to execute payload with minimal alert as much as possible.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = network operator may disable this feature of windows but not so common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Logs Using WevtUtil - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect execution of wevtutil.exe to disable logs. This technique was seen in several ransomware to disable the event logs to evade alerts and detections.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.001"], "nist": ["DE.CM"]}
known_false_positives = network operator may disable audit event logs for debugging purposes.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Registry Tool - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search identifies modification of registry to disable the regedit or registry tools of the windows operating system. Since registry tool is a swiss knife in analyzing registry, malware such as RAT or trojan Spy disable this application to prevent the removal of their registry entry such as persistence, file less components and defense evasion.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]}
known_false_positives = admin may disable this application for non technical user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Schedule Task - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious commandline to disable existing schedule task. This technique is used by adversaries or commodity malware like IcedID to disable security application (AV products) in the targetted host to evade detections. This TTP is a good pivot to check further why and what other process run before and after this detection. check which process execute the commandline and what task is disabled. parent child process is quite valuable in this scenario too.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin may disable problematic schedule task
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Security Logs Using MiniNt Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to disable security audit logs. This technique was shared by a researcher to disable Security logs of windows by adding this registry. The Windows will think it is WinPE and will not log any event to the Security Log
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Unknown.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Show Hidden Files - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows registry to prevent users from seeing all the files with hidden attributes. This event or techniques are known on some worm and trojan spy malware that will drop hidden files on the infected machine.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.001", "T1562.001", "T1564", "T1562", "T1112"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable UAC Remote Restriction - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious modification of registry to disable UAC remote restriction. This technique was well documented in Microsoft page where attacker may modify this registry value to bypassed UAC feature of windows host. This is a good indicator that some tries to bypassed UAC to suspicious process or gain privilege escalation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = admin may set this policy for non-critical machine.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Windows App Hotkeys - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a suspicious registry modification to disable Windows hotkey (shortcut keys) for native Windows applications. This technique is commonly used to disable certain or several Windows applications like `taskmgr.exe` and `cmd.exe`. This technique is used to impair the analyst in analyzing and removing the attacker implant in compromised systems.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Windows Behavior Monitoring - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identifies a modification in registry to disable the windows denfender real time behavior monitoring. This event or technique is commonly seen in RAT, bot, or Trojan to disable AV to evade detections.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable this windows features.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disable Windows SmartScreen Protection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following search identifies a modification of registry to disable the smartscreen protection of windows machine. This is windows feature provide an early warning system against website that might engage in phishing attack or malware distribution. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable this windows features.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabled Kerberos Pre-Authentication Discovery With Get-ADUser - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUser` commandlet with specific parameters. `Get-ADUser` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Get-ADUser` is used to query for domain users. With the appropiate parameters, Get-ADUser allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries alike use may abuse Get-ADUSer to enumerate these accounts and attempt to crack their passwords offline.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use search for accounts with Kerberos Pre Authentication disabled for legitimate purposes.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Disabled Kerberos Pre-Authentication Discovery With PowerView - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet with specific parameters. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows Active Directory networks. As the name suggests, `Get-DomainUser` is used to identify domain users and combining it with `-PreauthNotRequired` allows adversaries to discover domain accounts with Kerberos Pre Authentication disabled.\ Red Teams and adversaries alike use may leverage PowerView to enumerate these accounts and attempt to crack their passwords offline.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use PowerView for troubleshooting
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Disabling CMD Application - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identify modification in registry to disable cmd prompt application. This technique is commonly seen in RAT, Trojan or WORM to prevent triaging or deleting there samples through cmd application which is one of the tool of analyst to traverse on directory and files.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]}
known_false_positives = admin may disable this application for non technical user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling ControlPanel - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to identify registry modification to disable control panel window. This technique is commonly seen in malware to prevent their artifacts , persistence removed on the infected machine.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]}
known_false_positives = admin may disable this application for non technical user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling Defender Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This particular behavior is typically executed when an adversaries or malware gains access to an endpoint and beings to perform execution and to evade detections. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to disable windows defender product
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling Firewall with Netsh - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identifies suspicious firewall disabling using netsh application. this technique is commonly seen in malware that tries to communicate or download its component or other payload to its C2 server.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = admin may disable firewall during testing or fixing network problem.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling FolderOptions Windows Feature - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identify registry modification to disable folder options feature of windows to show hidden files, file extension and etc. This technique used by malware in combination if disabling show hidden files feature to hide their files and also to hide the file extension to lure the user base on file icons or fake file extensions.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin may disable this application for non technical user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling Net User Account - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify a suspicious command-line that disables a user account using the `net.exe` utility native to Windows. This technique may used by the adversaries to interrupt availability of such users to do their malicious act.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling NoRun Windows App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identify modification of registry to disable run application in window start menu. this application is known to be a helpful shortcut to windows OS user to run known application and also to execute some reg or batch script. This technique is used malware to make cleaning of its infection more harder by preventing known application run easily through run shortcut.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562", "T1112"], "nist": ["DE.CM"]}
known_false_positives = admin may disable this application for non technical user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling Remote User Account Control - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for modifications to registry keys that control the enforcement of Windows User Account Control (UAC).
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or via other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report registry modifications.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = This registry key may be modified via administrators to implement a change in system policy. This type of change should be a very rare occurrence.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling SystemRestore In Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following search identifies the modification of registry related in disabling the system restore of a machine. This event or behavior are seen in some RAT malware to make the restore of the infected machine  difficult and keep their infection on the box.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = in some cases admin can disable systemrestore on a machine.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling Task Manager - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to identifies modification of registry to disable the task manager of windows operating system. this event or technique are commonly seen in malware such as RAT, Trojan, TrojanSpy or worm to prevent the user to terminate their process.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin may disable this application for non technical user.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Disabling Windows Local Security Authority Defences via Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection looks for the deletion of registry keys which disable LSA protection and MS Defender Device Guard.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1556"], "nist": ["DE.CM"]}
known_false_positives = Potential to be triggered by an administrator disabling protections for troubleshooting purposes.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - DLLHost with no Command Line Arguments with Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies DLLHost.exe with no command line arguments with a network connection. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate third party applications may use a moved copy of dllhost, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - DNS Exfiltration Using Nslookup App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type, TXT, A, AAAA, that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.CM"]}
known_false_positives = admin nslookup usage
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Account Discovery with Dsquery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to discover  domain users. The `user` argument returns a list of all users registered in the domain. Red Teams and adversaries alike engage in remote system discovery for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Account Discovery With Net App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for domain users. Red Teams and adversaries alike may use net.exe to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Account Discovery with Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for domain users. Red Teams and adversaries alike use wmic.exe to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Controller Discovery with Nltest - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `nltest.exe` with command-line arguments utilized to discover remote systems. The arguments `/dclist:` and '/dsgetdc:', can be used to return a list of all domain controllers. Red Teams and adversaries alike may use nltest.exe to identify domain controllers in a Windows Domain for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Controller Discovery with Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to discover remote systems. The arguments utilized in this command line return a list of all domain controllers in a Windows domain. Red Teams and adversaries alike use *.exe to identify remote systems for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Group Discovery with Adsisearcher - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use Adsisearcher for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Domain Group Discovery With Dsquery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to query for domain groups. The argument `group`, returns a list of all domain groups. Red Teams and adversaries alike use may leverage dsquery.exe to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Group Discovery With Net - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` with command-line arguments utilized to query for domain groups. The argument `group /domain`, returns a list of all domain groups. Red Teams and adversaries alike use net.exe to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Domain Group Discovery With Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for domain groups. The arguments utilized in this command return a list of all domain groups. Red Teams and adversaries alike use wmic.exe to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Download Files Using Telegram - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic will identify a suspicious download by the Telegram application on a Windows system. This behavior was identified on a honeypot where the adversary gained access, installed Telegram and followed through with downloading different network scanners (port, bruteforcer, masscan) to the system and later used to mapped the whole network and further move laterally.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and TargetFilename from your endpoints or Events that monitor filestream events which is happened when process download something. (EventCode 15) If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = normal download of file in telegram app. (if it was a common app in network)
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Drop IcedID License dat - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect dropping a suspicious file named as "license.dat" in %appdata%. This behavior seen in latest IcedID malware that contain the actual core bot that will be injected in other process to do banking stealing.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - DSQuery Domain Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies "dsquery.exe" execution with arguments looking for `TrustedDomain` query directly on the command-line. This is typically indicative of an Administrator or adversary perform domain trust discovery. Note that this query does not identify any other variations of "Dsquery.exe" usage.\
Within this detection, it is assumed `dsquery.exe` is not moved or renamed.\
The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, process "dsquery.exe" and its parent process.\
DSQuery.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64` and only on Server operating system.\
The following DLL(s) are loaded when DSQuery.exe is launched `dsquery.dll`. If found loaded by another process, it is possible dsquery is running within that process context in memory.\
In addition to trust discovery, review parallel processes for additional behaviors performed. Identify the parent process and capture any files (batch files, for example) being used.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives. If there is a true false positive, filter based on command-line or parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Dump LSASS via comsvcs DLL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the behavior of dumping credentials from memory, a tactic commonly used by adversaries to exploit the Local Security Authority Subsystem Service (LSASS) in Windows, which manages system-level authentication. The detection is made by monitoring logs with process information from endpoints and identifying instances where the rundll32 process is used in conjunction with the comsvcs.dll and MiniDump. This indicates potential LSASS dumping attempts used by threat actors to obtain valuable credentials. The detection is important because credential theft can lead to broader system compromise, persistence, lateral movement, and escalated privileges. No legitimate use of this technique has been identified yet. This behavior is often part of more extensive attack campaigns and is associated with numerous threat groups that use the stolen credentials to access sensitive information or systems, leading to data theft, ransomware attacks, or other damaging outcomes. False positives can occur since legitimate uses of the LSASS process can cause benign activities to be flagged. Next steps include reviewing the processes involved in the LSASS dumping attempt after triage and inspecting any relevant on-disk artifacts and concurrent processes to identify the attack source.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = None identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Dump LSASS via procdump - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Detect procdump.exe dumping the lsass process. This query looks for both -mm and -ma usage. -mm will produce a mini dump file and -ma will write a dump file with all process memory. Both are highly suspect and should be reviewed. This query does not monitor for the internal name (original_file_name=procdump) of the PE or look for procdump64.exe. Modify the query as needed.\
During triage, confirm this is procdump.exe executing. If it is the first time a Sysinternals utility has been ran, it is possible there will be a -accepteula on the command line. Review other endpoint data sources for cross process (injection) into lsass.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = None identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Elevated Group Discovery With Net - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` or `net1.exe`  with command-line arguments utilized to query for specific elevated domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Elevated Group Discovery with PowerView - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainGroupMember` commandlet. `Get-DomainGroupMember` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. As the name suggests, `Get-DomainGroupMember` is used to list the members of an specific domain group. Red Teams and adversaries alike use PowerView to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerView for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Elevated Group Discovery With Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for specific domain groups. Red Teams and adversaries alike use net.exe to enumerate elevated domain groups for situational awareness and Active Directory Discovery to identify high privileged users.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Enable RDP In Other Port Number - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a modification to registry to enable rdp to a machine with different port number. This technique was seen in some atttacker tries to do lateral movement and remote access to a compromised machine to gain control of it.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Enable WDigest UseLogonCredential Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to enable plain text credential feature of windows. This technique was used by several malware and also by mimikatz to be able to dumpe the a plain text credential to the compromised or target host. This TTP is really a good indicator that someone wants to dump the crendential of the host so it must be a good pivot for credential dumping techniques.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112", "T1003"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Enumerate Users Local Group Using Telegram - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will detect a suspicious Telegram process enumerating all network users in a local group. This technique was seen in a Monero infected honeypot to mapped all the users on the compromised system. EventCode 4798 is generated when a process enumerates a user's security-enabled local groups on a computer or device.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Task Schedule (Exa. Security Log EventCode 4798) endpoints. Tune and filter known instances of process like logonUI used in your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Esentutl SAM Copy - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the process - `esentutl.exe` - being used to capture credentials stored in ntds.dit or the SAM file on disk. During triage, review parallel processes and determine if legitimate activity. Upon determination of illegitimate activity, take further action to isolate and contain the threat.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - ETW Registry Disabled - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a registry modification to disable ETW feature of windows. This technique is to evade EDR appliance to evade detections and hide its execution from audit logs.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.006", "T1127", "T1562"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Eventvwr UAC Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following search identifies Eventvwr bypass by identifying the registry modification into a specific path that eventvwr.msc looks to (but is not valid) upon execution. A successful attack will include a suspicious command to be executed upon eventvwr.msc loading. Upon triage, review the parallel processes that have executed. Identify any additional registry modifications on the endpoint that may look suspicious. Remediate as necessary.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = Some false positives may be present and will need to be filtered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excel Spawning PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies Microsoft Excel spawning PowerShell. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, but if any are present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excel Spawning Windows Script Host - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies Microsoft Excel spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Excel.exe. Excel.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64`. `cscript.exe` or `wscript.exe` spawning from Excel.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, but if any are present, filter as needed. In some instances, `cscript.exe` is used for legitimate business practices.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive Attempt To Disable Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious series of command-line to disable several services. This technique is seen where the adversary attempts to disable security app services or other malware services to complete the objective on the compromised system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive distinct processes from Windows Temp - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious series of process executions.  We have observed that post exploit framework tools like Koadic and Meterpreter will launch an excessive number of processes with distinct file paths from Windows\Temp to execute actions on objective.  This behavior is extremely anomalous compared to typical application behaviors that use Windows\Temp.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = Many benign applications will create processes from executables in Windows\Temp, although unlikely to exceed the given threshold.  Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive File Deletion In WinDefender Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies excessive file deletion events in the Windows Defender folder. This technique was observed in the WhisperGate malware campaign, where adversaries exploited Nirsoft's advancedrun.exe to gain administrative privileges and then executed PowerShell commands to delete files within the Windows Defender application folder. Such behavior is a strong indicator that the offending process is attempting to corrupt a Windows Defender installation.
how_to_implement = To successfully implement this search, you must ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are utilizing Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = Windows Defender AV updates may trigger this alert. Please adjust the filter macros to mitigate false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Excessive number of service control start as disabled - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection targets behaviors observed when threat actors have used sc.exe to modify services. We observed malware in a honey pot spawning numerous sc.exe processes in a short period of time, presumably to impair defenses, possibly to block others from compromising the same machine.  This detection will alert when we see both an excessive number of sc.exe processes launched with specific commandline arguments to disable the start of certain services.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = Legitimate programs and administrators will execute sc.exe with the start disabled flag.  It is possible, but unlikely from the telemetry of normal Windows operation we observed, that sc.exe will be called more than seven times in a short period of time.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive number of taskhost processes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection targets behaviors observed in post exploit kits like Meterpreter and Koadic that are run in memory.  We have observed that these tools must invoke an excessive number of taskhost.exe and taskhostex.exe processes to complete various actions (discovery, lateral movement, etc.).  It is extremely uncommon in the course of normal operations to see so many distinct taskhost and taskhostex processes running concurrently in a short time frame.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = Administrators, administrative actions or certain applications may run many instances of taskhost and taskhostex concurrently.  Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive Service Stop Attempt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious series of attempt to kill multiple services on a system using either `net.exe` or `sc.exe`. This technique is use by adversaries to terminate security services or other related services to continue there objective and evade detections.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive Usage Of Cacls App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies excessive usage of `cacls.exe`, `xcacls.exe` or `icacls.exe` application to change file or folder permission. This behavior is commonly seen where the adversary attempts to impair some users from deleting or accessing its malware components or artifact from the compromised system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.AE"]}
known_false_positives = Administrators or administrative scripts may use this application. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive Usage Of Net App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies excessive usage of `net.exe` or `net1.exe` within a bucket of time (1 minute). This behavior was seen in a Monero incident where the adversary attempts to create many users, delete and disable users as part of its malicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1531"], "nist": ["DE.AE"]}
known_false_positives = unknown. Filter as needed. Modify the time span as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Excessive Usage of NSLOOKUP App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect potential DNS exfiltration using nslookup application. This technique are seen in couple of malware and APT group to exfiltrated collected data in a infected machine or infected network. This detection is looking for unique use of nslookup where it tries to use specific record type (TXT, A, AAAA) that are commonly used by attacker and also the retry parameter which is designed to query C2 DNS multiple tries.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of nslookup.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Excessive Usage Of SC Service Utility - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious excessive usage of sc.exe in a host machine. This technique was seen in several ransomware , xmrig and other malware to create, modify, delete or disable a service may related to security application or to gain privilege escalation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed taskkill.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]}
known_false_positives = excessive execution of sc.exe is quite suspicious since it can modify or execute app in high privilege permission.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Excessive Usage Of Taskkill - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies excessive usage of `taskkill.exe` application. This application is commonly used by adversaries to evade detections by killing security product processes or even other processes to evade detection.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = Unknown. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Exchange PowerShell Abuse via SSRF - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious behavior related to ProxyShell against on-premise Microsoft Exchange servers. This analytic has been replaced by GUID d436f9e7-0ee7-4a47-864b-6dea2c4e2752 which utilizes the Web Datamodel. \
Modification of this analytic is requried to ensure fields are mapped accordingly. \
A suspicious event will have `PowerShell`, the method `POST` and `autodiscover.json`. This is indicative of accessing PowerShell on the back end of Exchange with SSRF. \
An event will look similar to `POST /autodiscover/autodiscover.json a=dsxvu@fnsso.flq/powershell/?X-Rps-CAT=VgEAVAdXaW5kb3d...` (abbreviated) \
Review the source attempting to perform this activity against your environment. In addition, review PowerShell logs and access recently granted to Exchange roles.
how_to_implement = The following analytic requires on-premise Exchange to be logging to Splunk using the TA - https://splunkbase.splunk.com/app/3225. Ensure logs are parsed correctly, or tune the analytic for your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives, however, tune as needed.
providing_technologies = null

[savedsearch://ESCU - Exchange PowerShell Module Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the usage of Exchange PowerShell modules that were recently used for a proof of concept related to ProxyShell. Adversaries may abuse a limited set of PwSh Modules related to Exchange once gained access via ProxyShell or ProxyNotShell.\
Inherently, the usage of the modules is not malicious, but reviewing parallel processes, and user, of the session will assist with determining the intent. \
Module - New-MailboxExportRequest will begin the process of exporting contents of a primary mailbox or archive to a .pst file. \
Module - New-managementroleassignment can assign a management role to a management role group, management role assignment policy, user, or universal security group (USG). \
Module - New-MailboxSearch cmdlet to create a mailbox search and either get an estimate of search results, place search results on In-Place Hold or copy them to a Discovery mailbox. You can also place all contents in a mailbox on hold by not specifying a search query, which accomplishes similar results as Litigation Hold. \ Module - Get-Recipient cmdlet to view existing recipient objects in your organization. This cmdlet returns all mail-enabled objects (for example, mailboxes, mail users, mail contacts, and distribution groups).
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Executable File Written in Administrative SMB Share - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies executable files (.exe or .dll) being written to Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The Trickbot malware family also implements this behavior to try to infect other machines in the infected network.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.002"], "nist": ["DE.CM"]}
known_false_positives = System Administrators may use looks like PsExec for troubleshooting or administrations tasks. However, this will typically come only from certain users and certain systems that can be added to an allow list.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Executables Or Script Creation In Suspicious Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies potentially malicious executables or scripts by examining a list of suspicious file paths on Windows Operating System. The purpose of this technique is to uncover files with known file extensions that could be used by adversaries to evade detection and persistence. The suspicious file paths selected for investigation are typically uncommon and uncommonly associated with executable or script files. By scrutinizing these paths, we can proactively identify potential security threats and enhance overall system security.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.AE"]}
known_false_positives = Administrators may allow creation of script or exe in the paths specified. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Execute Javascript With Jscript COM CLSID - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious process of cscript.exe where it tries to execute javascript using jscript.encode CLSID (COM OBJ). This technique was seen in ransomware (reddot ransomware) where it execute javascript with this com object with combination of amsi disabling technique.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.005"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Execution of File with Multiple Extensions - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes launched from files that have double extensions in the file name. This is typically done to obscure the "real" file extension and make it appear as though the file being accessed is a data file, as opposed to executable content.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003"], "nist": ["DE.CM"]}
known_false_positives = None identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Extraction of Registry Hives - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of `reg.exe` exporting Windows Registry hives containing credentials. Adversaries may use this technique to export registry hives for offline credential access attacks. Typically found executed from a untrusted process or script. Upon execution, a file will be written to disk.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.CM"]}
known_false_positives = It is possible some agent based products will generate false positives. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - File with Samsam Extension - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects file writes with extensions that are consistent with a SamSam ransomware attack to proactively detect and respond to potential SamSam ransomware attacks, minimizing the impact and reducing the likelihood of successful ransomware infections. This detection is made by a Splunk query to search for specific file extensions that are commonly associated with SamSam ransomware, such as .stubbin, .berkshire, .satoshi, .sophos, and .keyxml. This identifies file extensions in the file names of the written files. If any file write events with these extensions are found, it suggests a potential SamSam ransomware attack. This detection is important because SamSam ransomware is a highly destructive and financially motivated attack and suggests that the organization is at risk of having its files encrypted and held for ransom, which can lead to significant financial losses, operational disruptions, and reputational damage. False positives might occur since legitimate files with these extensions can exist in the environment. Therefore, next steps include conducting a careful analysis and triage to confirm the presence of a SamSam ransomware attack. Next steps include taking immediate action to contain the attack, mitigate the impact, and prevent further spread of the ransomware. This might involve isolating affected systems, restoring encrypted files from backups, and conducting a thorough investigation to identify the attack source and prevent future incidents.
how_to_implement = You must be ingesting data that records file-system activity from your hosts to populate the Endpoint file-system data-model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = Because these extensions are not typically used in normal operations, you should investigate all results.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Firewall Allowed Program Enable - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a potential suspicious modification of firewall rule allowing to execute specific application. This technique was identified when an adversary and red teams to bypassed firewall file execution restriction in a targetted host. Take note that this event or command can run by administrator during testing or allowing legitimate tool or application.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]}
known_false_positives = A network operator or systems administrator may utilize an automated or manual execution of this firewall rule that may generate false positives. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - First Time Seen Child Process of Zoom - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for child processes spawned by zoom.exe or zoom.us that has not previously been seen.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.AE"]}
known_false_positives = A new child process of zoom isn't malicious by that fact alone. Further investigation of the actions of the child process is needed to verify any malicious behavior is taken.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - First Time Seen Running Windows Service - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for the first and last time a Windows service is seen running in your environment. This table is then cached.
how_to_implement = While this search does not require you to adhere to Splunk CIM, you must be ingesting your Windows system event logs in order for this search to execute successfully. You should run the baseline search `Previously Seen Running Windows Services - Initial` to build the initial table of child processes and hostnames for this search to work. You should also schedule at the same interval as this search the second baseline search `Previously Seen Running Windows Services - Update` to keep this table up to date and to age out old Windows Services. Please update the `previously_seen_windows_services_window` macro to adjust the time window. Please ensure that the Splunk Add-on for Microsoft Windows is version 8.0.0 or above.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.AE"]}
known_false_positives = A previously unseen service is not necessarily malicious. Verify that the service is legitimate and that was installed by a legitimate process.
providing_technologies = null

[savedsearch://ESCU - FodHelper UAC Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Fodhelper.exe has a known UAC bypass as it attempts to look for specific registry keys upon execution, that do not exist. Therefore, an attacker can write its malicious commands in these registry keys to be executed by fodhelper.exe with the highest privilege. \
1. `HKCU:\Software\Classes\ms-settings\shell\open\command`\
1. `HKCU:\Software\Classes\ms-settings\shell\open\command\DelegateExecute`\
1. `HKCU:\Software\Classes\ms-settings\shell\open\command\(default)`\
Upon triage, fodhelper.exe will have a child process and read access will occur on the registry keys. Isolate the endpoint and review parallel processes for additional behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112", "T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = Limited to no false positives are expected.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Fsutil Zeroing File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious fsutil process to zeroing a target file. This technique was seen in lockbit ransomware where it tries to zero out its malware path as part of its defense evasion after encrypting the compromised host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get ADDefaultDomainPasswordPolicy with Powershell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` executing the Get-ADDefaultDomainPasswordPolicy commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get ADDefaultDomainPasswordPolicy with Powershell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADDefaultDomainPasswordPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get ADUser with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to enumerate domain users. The `Get-AdUser' commandlet returns a list of all domain users. Red Teams and adversaries alike may use this commandlet to identify remote systems for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get ADUser with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-AdGUser` commandlet. The `Get-AdUser` commandlet is used to return a list of all domain users. Red Teams and adversaries may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get ADUserResultantPasswordPolicy with Powershell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` executing the Get ADUserResultantPasswordPolicy commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get ADUserResultantPasswordPolicy with Powershell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-ADUserResultantPasswordPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get DomainPolicy with Powershell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` executing the `Get-DomainPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get DomainPolicy with Powershell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get DomainPolicy` commandlet used to obtain the password policy in a Windows domain. Red Teams and adversaries alike may use PowerShell to enumerate domain policies for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get-DomainTrust with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies Get-DomainTrust from PowerView in order to gather domain trust information. Typically, this is utilized within a script being executed and used to enumerate the domain trust information. This grants the adversary an understanding of how large or small the domain is. During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives as this requires an active Administrator or adversary to bring in, import, and execute.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get-DomainTrust with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies Get-DomainTrust from PowerView in order to gather domain trust information. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]}
known_false_positives = It is possible certain system management frameworks utilize this command to gather trust information.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get DomainUser with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to enumerate domain users. `Get-DomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get DomainUser with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` commandlet. `GetDomainUser` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may use PowerView to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get-ForestTrust with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies Get-ForestTrust from PowerSploit in order to gather domain trust information. Typically, this is utilized within a script being executed and used to enumerate the domain trust information. This grants the adversary an understanding of how large or small the domain is. During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives as this requires an active Administrator or adversary to bring in, import, and execute.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get-ForestTrust with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies Get-ForestTrust from PowerSploit in order to gather domain trust information. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1482", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present. Tune as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Get WMIObject Group Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies the use of `Get-WMIObject Win32_Group` being used with PowerShell to identify local groups on the endpoint. \ Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \ During triage, review parallel processes and identify any further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Get WMIObject Group Discovery with Script Block Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies the usage of `Get-WMIObject Win32_Group`, which is typically used as a way to identify groups on the endpoint.  Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetAdComputer with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. The `Get-AdComputer' commandlet returns a list of all domain computers. Red Teams and adversaries alike may use this commandlet to identify remote systems for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetAdComputer with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-AdGroup` commandlet. The `Get-AdGroup` commandlet is used to return a list of all domain computers. Red Teams and adversaries may leverage this commandlet to enumerate domain computers for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetAdGroup with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain groups. The `Get-AdGroup` commandlnet is used to return a list of all groups available in a Windows Domain. Red Teams and adversaries alike may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetAdGroup with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-AdGroup` commandlet. The `Get-AdGroup` commandlet is used to return a list of all domain groups. Red Teams and adversaries may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetCurrent User with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powerhsell.exe` with command-line arguments that execute the `GetCurrent` method of the WindowsIdentity .NET class. This method returns an object that represents the current Windows user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetCurrent User with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `GetCurrent` method of the WindowsIdentity .NET class. This method returns an object that represents the current Windows user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetDomainComputer with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. `Get-DomainComputer` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use PowerView for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetDomainComputer with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainComputer` commandlet. `GetDomainComputer` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may use PowerView to enumerate domain computers for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use PowerView for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetDomainController with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. `Get-DomainController` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use PowerView for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetDomainController with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainController` commandlet. `Get-DomainController` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may use PowerView to enumerate domain computers for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetDomainGroup with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain groups. `Get-DomainGroup` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. Red Teams and adversaries alike may leverage PowerView to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetDomainGroup with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainGroup` commandlet. `Get-DomainGroup` is part of PowerView, a PowerShell tool used to perform enumeration on Windows domains. As the name suggests, `Get-DomainGroup` is used to query domain groups. Red Teams and adversaries may leverage this function to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this PowerView functions for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetLocalUser with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for local users. The `Get-LocalUser` commandlet is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetLocalUser with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-LocalUser` commandlet. The `Get-LocalUser` commandlet is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1087", "T1087.001", "T1059.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetNetTcpconnection with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line utilized to get a listing of network connections on a compromised system. The `Get-NetTcpConnection` commandlet lists the current TCP connections. Red Teams and adversaries alike may use this commandlet for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetNetTcpconnection with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-NetTcpconnection ` commandlet. This commandlet is used to return a listing of network connections on a compromised system. Red Teams and adversaries alike may use this commandlet for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetWmiObject Ds Computer with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to discover remote systems. The `Get-WmiObject` commandlet combined with the `DS_Computer` parameter can be used to return a list of all domain computers. Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetWmiObject Ds Computer with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet. The `DS_Computer` class parameter leverages WMI to query for all domain computers. Red Teams and adversaries may leverage this commandlet to enumerate domain computers for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetWmiObject Ds Group with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain groups. The `Get-WmiObject` commandlet combined with the `-class ds_group` parameter can be used to return the full list of groups in a Windows domain. Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetWmiObject Ds Group with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet used with specific parameters . The `DS_Group` parameter leverages WMI to query for all domain groups. Red Teams and adversaries may leverage this commandlet to enumerate domain groups for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetWmiObject DS User with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query for domain users. The `Get-WmiObject` commandlet combined with the `-class ds_user` parameter can be used to return the full list of users in a Windows domain. Red Teams and adversaries alike may leverage WMI in this case, using PowerShell, to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetWmiObject DS User with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet. The `DS_User` class parameter leverages WMI to query for all domain users. Red Teams and adversaries may leverage this commandlet to enumerate domain users for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GetWmiObject User Account with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments utilized to query local users. The `Get-WmiObject` commandlet combined with the `Win32_UserAccount` parameter is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - GetWmiObject User Account with PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-WmiObject` commandlet used with specific parameters. The `Win32_UserAccount` parameter is used to return a list of all local users. Red Teams and adversaries may leverage this commandlet to enumerate users for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1087", "T1087.001", "T1059.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - GPUpdate with no Command Line Arguments with Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies gpupdate.exe with no command line arguments and with a network connection. It is unusual for gpupdate.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. gpupdate.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Headless Browser Mockbin or Mocky Request - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic identifies headless browser activity accessing mockbin.org or mocky.io. Mockbin.org and mocky.io are web services that allow users to mock HTTP requests and responses. The detection is based on the presence of "--headless" and "--disable-gpu" command line arguments which are commonly used in headless browsing and the presence of mockbin.org or mocky.io in the process.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.003"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected with this detection, unless within the organization there is a legitimate need for headless browsing accessing mockbin.org or mocky.io.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Headless Browser Usage - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following hunting analytic is designed to detect the usage of headless browsers in an organization. Headless browsers are web browsers without a graphical user interface and are operated via a command line interface or network requests. They are often used for automating tasks but can also be utilized by adversaries for malicious activities such as web scraping, automated testing, and performing actions on web pages without detection. The detection is based on the presence of "--headless" and "--disable-gpu" command line arguments which are commonly used in headless browsing.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.003"], "nist": ["DE.AE"]}
known_false_positives = This hunting analytic is meant to assist with baselining and understanding headless browsing in use. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Hide User Account From Sign-In Screen - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a suspicious registry modification to hide a user account on the Windows Login screen. This technique was seen in some tradecraft where the adversary will create a hidden user account with Admin privileges in login screen to avoid noticing by the user that they already compromise and to persist on that said machine.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Unknown. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Hiding Files And Directories With Attrib exe - Rule]
type = detection
asset_type = 
confidence = medium
explanation = Attackers leverage an existing Windows binary, attrib.exe, to mark specific as hidden by using specific flags so that the victim does not see the file.  The search looks for specific command-line arguments to detect the use of attrib.exe to hide files.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222", "T1222.001"], "nist": ["DE.CM"]}
known_false_positives = Some applications and users may legitimately use attrib.exe to interact with the files.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - High Frequency Copy Of Files In Network Share - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious high frequency copying/moving of files in network share as part of information sabotage. This anomaly event can be a good indicator of insider trying to sabotage data by transfering classified or internal files within network share to exfitrate it after or to lure evidence of insider attack to other user. This behavior may catch several noise if network share is a common place for classified or internal document processing.
how_to_implement = o successfully implement this search, you need to be ingesting Windows Security Event Logs with 5145 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1537"], "nist": ["DE.AE"]}
known_false_positives = this behavior may seen in normal transfer of file within network if network share is common place for sharing documents.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - High Process Termination Frequency - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify a high frequency of process termination events on a computer in a short period of time, which is a common behavior of ransomware malware before encrypting files. This technique is designed to avoid an exception error while accessing (docs, images, database and etc..) in the infected machine for encryption.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Image (process full path of terminated process) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]}
known_false_positives = admin or user tool that can terminate multiple process.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Hunting 3CXDesktopApp Software - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The hunting analytic outlined below is designed to detect any version of the 3CXDesktopApp, also known as the 3CX Desktop App, operating on either Mac or Windows systems. It is important to note that this particular analytic employs the Endpoint datamodel Processes node, which means that the file version information is not provided. Recently, 3CX has identified a vulnerability specifically in versions 18.12.407 and 18.12.416 of the desktop app.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.002"], "nist": ["DE.AE"]}
known_false_positives = There may be false positives generated due to the reliance on version numbers for identification purposes. Despite this limitation, the primary goal of this approach is to aid in the detection of the software within the environment.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Icacls Deny Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies instances where an adversary modifies the security permissions of a particular file or directory. This technique is frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. The purpose of this behavior is to actively evade detection and impede access to their associated files. By identifying these security permission changes, we can enhance our ability to detect and respond to potential threats, mitigating the impact of malicious activities on the system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.CM"]}
known_false_positives = Unknown. It is possible some administrative scripts use ICacls. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - ICACLS Grant Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies adversaries who manipulate the security permissions of specific files or directories by granting additional access. This technique is frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. The objective behind this behavior is to actively evade detection mechanisms and tightly control access to their associated files. By identifying these security permission modifications, we can improve our ability to identify and respond to potential threats, thereby minimizing the impact of malicious activities on the system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.CM"]}
known_false_positives = Unknown. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - IcedID Exfiltrated Archived File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious file creation namely passff.tar and cookie.tar. This files are possible archived of stolen browser information like history and cookies in a compromised machine with IcedID.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Impacket Lateral Movement Commandline Parameters - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the presence of suspicious commandline parameters typically present when using Impacket tools. Impacket is a collection of python classes meant to be used with Microsoft network protocols. There are multiple scripts that leverage impacket libraries like `wmiexec.py`, `smbexec.py`, `dcomexec.py` and `atexec.py` used to execute commands on remote endpoints. By default, these scripts leverage administrative shares and hardcoded parameters that can be used as a signature to detect its use. Red Teams and adversaries alike may leverage Impackets tools for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.002", "T1021.003", "T1047", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Although uncommon, Administrators may leverage Impackets tools to start a process on remote systems for system administration or automation use cases.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic focuses on identifying suspicious command-line parameters commonly associated with the use of Impacket wmiexec.py. Impacket is a set of Python classes designed for working with Microsoft network protocols, and it includes several scripts like wmiexec.py, smbexec.py, dcomexec.py, and atexec.py that enable command execution on remote endpoints. These scripts typically utilize administrative shares and hardcoded parameters, which can serve as signatures to detect their usage. Both Red Teams and adversaries may employ Impacket tools for lateral movement and remote code execution purposes. By monitoring for these specific command-line indicators, the analytic aims to detect potentially malicious activities related to Impacket tool usage.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.002", "T1021.003", "T1047", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Although uncommon, Administrators may leverage Impackets tools to start a process on remote systems for system administration or automation use cases.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the presence of suspicious commandline parameters typically present when using Impacket tools. Impacket is a collection of python classes meant to be used with Microsoft network protocols. There are multiple scripts that leverage impacket libraries like `wmiexec.py`, `smbexec.py`, `dcomexec.py` and `atexec.py` used to execute commands on remote endpoints. By default, these scripts leverage administrative shares and hardcoded parameters that can be used as a signature to detect its use. Red Teams and adversaries alike may leverage Impackets tools for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.002", "T1021.003", "T1047", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Although uncommon, Administrators may leverage Impackets tools to start a process on remote systems for system administration or automation use cases.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Interactive Session on Remote Endpoint with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the usage of the `Enter-PSSession`. This commandlet can be used to open an interactive session on a remote endpoint leveraging the WinRM protocol. Red Teams and adversaries alike may abuse WinRM and `Enter-PSSession` for lateral movement and remote code execution.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage WinRM and `Enter-PSSession` for administrative and troubleshooting tasks. This activity is usually limited to a small set of hosts or users. In certain environments, tuning may not be possible.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Java Class File download by Java User Agent - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies a Java user agent performing a GET request for a .class file from the remote site. This is potentially indicative of exploitation of the Java application and may be related to current event CVE-2021-44228 (Log4Shell).
how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = Filtering may be required in some instances, filter as needed.
providing_technologies = null

[savedsearch://ESCU - Java Writing JSP File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the process java writing a .jsp to disk. This is potentially indicative of a web shell being written to disk. Modify and tune the analytic based on data ingested. For instance, it may be worth running a broad query for jsp file writes first before performing a join.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible and filtering may be required. Restrict by assets or filter known jsp files that are common for the environment.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Jscript Execution Using Cscript App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a execution of jscript using cscript process. Commonly when a user run jscript file it was executed by wscript.exe application. This technique was seen in FIN7 js implant to execute its malicious script using cscript process. This behavior is uncommon and a good artifacts to check further anomalies within the network
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Kerberoasting spn request with RC4 encryption - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Kerberos Event 4769, A Kerberos service ticket was requested, to identify a potential kerberoasting attack against Active Directory networks. Kerberoasting allows an adversary to request kerberos tickets for domain accounts typically used as service accounts and attempt to crack them offline allowing them to obtain privileged access to the domain. This analytic looks for a specific combination of the Ticket_Options field based on common kerberoasting tools. Defenders should be aware that it may be possible for a Kerberoast attack to use different Ticket_Options.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.CM"]}
known_false_positives = Older systems that support kerberos RC4 by default like NetApp may generate false positives. Filter as needed
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Kerberos Pre-Authentication Flag Disabled in UserAccountControl - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic leverages Windows Security Event 4738, `A user account was changed`, to identify a change performed on a domain user object that disables Kerberos Pre-Authentication. Disabling the Pre Authentication flag in the UserAccountControl property allows an adversary to easily perform a brute force attack against the user's password offline leveraging the ASP REP Roasting technique. Red Teams and adversaries alike who have obtained privileges in an Active Directory network may use this technique as a backdoor or a way to escalate privileges.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `User Account Management` within `Account Management` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]}
known_false_positives = Unknown.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Kerberos Pre-Authentication Flag Disabled with PowerShell - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Set-ADAccountControl` commandlet with specific parameters. `Set-ADAccountControl` is part of the Active Directory PowerShell module used to manage Windows Active Directory networks. As the name suggests, `Set-ADAccountControl` is used to modify User Account Control values for an Active Directory domain account. With the appropiate parameters, Set-ADAccountControl allows adversaries to disable Kerberos Pre-Authentication for an account to to easily perform a brute force attack against the user's password offline leveraging the ASP REP Roasting technique. Red Teams and adversaries alike who have obtained privileges in an Active Directory network may use this technique as a backdoor or a way to escalate privileges.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.004"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, Administrators may need to set this flag for legitimate purposes.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Kerberos Service Ticket Request Using RC4 Encryption - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Kerberos Event 4769, A Kerberos service ticket was requested, to identify a potential Kerberos Service Ticket request related to a Golden Ticket attack. Adversaries who have obtained the Krbtgt account NTLM password hash may forge a Kerberos Granting Ticket (TGT) to obtain unrestricted access to an Active Directory environment. Armed with a Golden Ticket, attackers can request service tickets to move laterally and execute code on remote systems. Looking for Kerberos Service Ticket requests using the legacy RC4 encryption mechanism could represent the second stage of a Golden Ticket attack. RC4 usage should be rare on a modern network since Windows Vista & Windows Sever 2008 and newer support AES Kerberos encryption.\ Defenders should note that if an attacker does not leverage the NTLM password hash but rather the AES key to create a golden ticket, this detection may be bypassed.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.001"], "nist": ["DE.CM"]}
known_false_positives = Based on Microsoft documentation, legacy systems or applications will use RC4-HMAC as the default encryption for Kerberos Service Ticket requests. Specifically, systems before Windows Server 2008 and Windows Vista. Newer systems will use AES128 or AES256.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Kerberos TGT Request Using RC4 Encryption - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event 4768, A Kerberos authentication ticket (TGT) was requested, to identify a TGT request with encryption type 0x17, or RC4-HMAC. This encryption type is no longer utilized by newer systems and could represent evidence of an OverPass The Hash attack. Similar to Pass The Hash, OverPass The Hash is a form of credential theft that allows adversaries to move laterally or consume resources in a target network. Leveraging this attack, an adversary who has stolen the NTLM hash of a valid domain account is able to authenticate to the Kerberos Distribution Center(KDC) on behalf of the legitimate account and obtain a Kerberos TGT ticket. Depending on the privileges of the compromised account, this ticket may be used to obtain unauthorized access to systems and other network resources.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550"], "nist": ["DE.CM"]}
known_false_positives = Based on Microsoft documentation, legacy systems or applications will use RC4-HMAC as the default encryption for TGT requests. Specifically, systems before Windows Server 2008 and Windows Vista. Newer systems will use AES128 or AES256.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Kerberos User Enumeration - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event Id 4768, A Kerberos authentication ticket (TGT) was requested, to identify one source endpoint trying to obtain an unusual number Kerberos TGT ticket for non existing users. This behavior could represent an adversary abusing the Kerberos protocol to perform a user enumeration attack against an Active Directory environment. When Kerberos is sent a TGT request with no preauthentication for an invalid username, it responds with KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN or 0x6. Red teams and adversaries alike may abuse the Kerberos protocol to validate a list of users use them to perform further attacks.\ The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number requests. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1589", "T1589.002"], "nist": ["DE.AE"]}
known_false_positives = Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Known Services Killed by Ransomware - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search detects a suspicioous termination of known services killed by ransomware before encrypting files in a compromised machine. This technique is commonly seen in most of ransomware now a days to avoid exception error while accessing the targetted files it wants to encrypts because of the open handle of those services to the targetted file.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the 7036 EventCode ScManager in System audit Logs from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = Admin activities or installing related updates may do a sudden stop to list of services we monitor.
providing_technologies = null

[savedsearch://ESCU - Linux Account Manipulation Of SSH Config and Keys - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a deletion of ssh key in a linux machine. attacker may delete or modify ssh key to impair some security features or act as defense evasion in compromised linux machine. This Anomaly can be also a good indicator of a malware trying to wipe or delete several files in a compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Add Files In Known Crontab Directories - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic aims to detect unauthorized activities through suspicious file creation in recognized cron table directories, prevalent Unix-based locations for scheduling tasks. This behavior is often exploited by nefarious entities like malware or threat actors, including red teamers, to establish persistence on a targeted or compromised host. The analogy to Windows-based scheduled tasks helps explain the utility of a crontab or cron job. To enhance clarity and actionable intelligence, the anomaly query flags the anomaly, urging further investigation into the added file's details. A cybersecurity analyst should consider additional data points such as the user identity involved, the file's nature and purpose, file origin, timestamp, and any changes in system behavior post file execution. This comprehensive understanding aids in accurately determining the file's legitimacy, facilitating prompt and effective response actions.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can create file in crontab folders for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Add User Account - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for commands to create user accounts on the linux platform. This technique is commonly abuse by adversaries, malware author and red teamers to persist on the targeted or compromised host by creating new user with an elevated privilege. This Hunting query may catch normal creation of user by administrator so filter is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Adding Crontab Using List Parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious modifications to cron jobs on Linux systems using the crontab command with list parameters. This command line parameter can be abused by malware like Industroyer2, as well as adversaries and red teamers, to add a crontab entry for executing their malicious code on a schedule of their choice. However, it's important to note that administrators or normal users may also use this command for legitimate automation purposes, so filtering is required to minimize false positives. Identifying the modification of cron jobs using list parameters is valuable for a SOC as it indicates potential malicious activity or an attempt to establish persistence on the system. If a true positive is detected, further investigation should be conducted to analyze the added cron job, its associated command, and the impact it may have on the system. This includes examining the purpose of the job, reviewing any on-disk artifacts, and identifying any related processes or activities occurring concurrently. The impact of a true positive can range from unauthorized execution of malicious code to data destruction or other damaging outcomes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux apt-get Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The apt-get is a command line tool for interacting with the Advanced Package Tool (APT) library (a package management system for Linux distributions). It allows you to search for, install, manage, update, and remove software. The tool does not build software from the source code. If sudo right is given to the tool for user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux APT Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Advanced Package Tool, more commonly known as APT, is a collection of tools used to install, update, remove, and otherwise manage software packages on Debian and its derivative operating systems, including Ubuntu and Linux Mint. If sudo right is given to the tool for user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux At Allow Config File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of suspicious configuration files, /etc/at.allow or /etc/at.deny, in Linux. These files are commonly abused by malware, adversaries, or red teamers to establish persistence on compromised hosts. The configuration files determine which users are allowed to execute the "at" application, which is used for scheduling tasks in Linux. Attackers can add their user or a compromised username to these files to execute malicious code using "at." It's important to consider potential false positives as administrators or network operators may create these files for legitimate automation purposes. Adjust the filter macros to minimize false positives.\
Identifying the creation of these configuration files is valuable for a SOC as it indicates potential unauthorized activities or an attacker attempting to establish persistence. If a true positive is found, further investigation is necessary to examine the contents of the created configuration file and determine the source of creation. The impact of a true positive can vary but could result in unauthorized execution of malicious code, data theft, or other detrimental consequences. Analysts should review the file path, creation time, and associated processes to assess the extent of the attack and initiate appropriate response actions.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints into the Endpoint datamodel. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can create this file for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux At Application Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the execution of the "At" application in Linux, which can be used by attackers to create persistence entries on a compromised host. The "At" application can be used for automation purposes by administrators or network operators, so the filter macros should be updated to remove false positives. If a true positive is found, it suggests an attacker is trying to maintain access to the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, ensure you are ingesting logs with the required fields from your endpoints into the Endpoint datamodel. When a true positive is detected, it suggests that an attacker is attempting to establish persistence or deliver additional malicious payloads by leveraging the "At" application. This behavior can lead to data theft, ransomware attacks, or other damaging outcomes.\
During triage, the SOC analyst should review the context surrounding the execution of the "At" application. This includes identifying the user, the parent process responsible for invoking the application, and the specific command-line arguments used. It is important to consider whether the execution is expected behavior by an administrator or network operator for legitimate automation purposes.\
The presence of "At" application execution may indicate an attacker's attempt to maintain unauthorized access to the environment. Immediate investigation and response are necessary to mitigate further risks, identify the attacker's intentions, and prevent potential harm to the organization.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.002", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux AWK Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Awk is mostly used for processing and scanning patterns. It checks one or more files to determine whether any lines fit the specified patterns, and if so, it does the appropriate action. If sudo right is given to AWK binary for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Busybox Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides minimalist replacements for most of the utilities you usually find in GNU coreutils, util-linux, etc. If sudo right is given to BusyBox application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux c89 Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The c89 and cc commands compile, assemble, and link-edit C programs; the cxx or c++ command does the same for C++ programs. The c89 command should be used when compiling C programs that are written according to Standard C. If sudo right is given to c89 application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux c99 Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The c99 utility is an interface to the standard C compilation system; it shall accept source code conforming to the ISO C standard. The system conceptually consists of a compiler and link editor. If sudo right is given to ruby application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Change File Owner To Root - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for a commandline that change the file owner to root using chown utility tool. This technique is commonly abuse by adversaries, malware author and red teamers to escalate privilege to the targeted or compromised host by changing the owner of their malicious file to root. This event is not so common in corporate network except from the administrator doing normal task that needs high privilege.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222.002", "T1222"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Clipboard Data Copy - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Linux Xclip copying data out of the clipboard. Adversaries have utilized this technique to capture passwords, IP addresses, or store payloads.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1115"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present on Linux desktop as it may commonly be used by administrators or end users. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Common Process For Elevation Control - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for possible elevation control access using a common known process in linux platform to change the attribute and file ownership. This technique is commonly abused by adversaries, malware author and red teamers to gain persistence or privilege escalation on the target or compromised host. This common process is used to modify file attribute, file ownership or SUID. This tools can be used in legitimate purposes so filter is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.001", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Composer Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you. If sudo right is given to tool for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Cpulimit Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = cpulimit is a simple program which attempts to limit the cpu usage of a process (expressed in percentage, not in cpu time). This is useful to control batch jobs, when you don't want them to eat too much cpu. If sudo right is given to the program for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Csvtool Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = csvtool is an easy to use command-line tool to work with .CSV files. If sudo right is given to the tool for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Curl Upload File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies curl being utilized with the -F or --form, --upload-file, -T, -d, --data, --data-raw, -I and --head switches to upload AWS credentials or config to a remote destination. This enables uploading of binary files and so forth. To force the 'content' part to be a file, prefix the file name with an @ sign. To just get the content part from a file, prefix the file name with the symbol <. The difference between @ and < is then that @ makes a file get attached in the post as a file upload, while the < makes a text field and just get the contents for that text field from a file. This technique was utlized by the TeamTNT group to exfiltrate AWS credentials.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = Filtering may be required. In addition to AWS credentials, add other important files and monitor. The inverse would be to look for _all_ -F behavior and tune from there.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Data Destruction Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a unix shell command that can wipe root folders of a linux host. This commandline is being abused by Awfulshred malware that wipes or corrupts files in a targeted Linux host. The shell command uses the rm command with force recursive deletion even in the root folder. This TTP can be a good indicator that a user or a process wants to wipe roots directory files in Linux host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux DD File Overwrite - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to look for dd command to overwrite file. This technique was abused by adversaries or threat actor to destroy files or data on specific system or in a large number of host within network to interrupt host avilability, services and many more. This is also used to destroy data where it make the file irrecoverable by forensic techniques through overwriting files, data or local and remote drives.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Decode Base64 to Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the behavior of decoding base64-encoded data and passing it to a Linux shell. Additionally, it mitigates the potential damage and protects the organization's systems and data.The detection is made by searching for specific commands in the Splunk query, namely "base64 -d" and "base64 --decode", within the Endpoint.Processes data model. The analytic also includes a filter for Linux shells. The detection is important because  it indicates the presence of malicious activity since Base64 encoding is commonly used to obfuscate malicious commands or payloads, and decoding it can be a step in running those commands. It suggests that an attacker is attempting to run malicious commands on a Linux system to gain unauthorized access, for data exfiltration, or perform other malicious actions.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1027", "T1059.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on legitimate software being utilized. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Deleting Critical Directory Using RM Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious deletion of a critical folder in Linux machine using rm command. This technique was seen in industroyer2 campaign to wipe or destroy energy facilities of a targeted sector. Deletion in these list of folder is not so common since it need some elevated privileges to access some of it. We recommend to look further events specially in file access or file deletion, process commandline that may related to this technique.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Deletion Of Cron Jobs - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a deletion of cron job in a linux machine. This technique can be related to an attacker, threat actor or malware to disable scheduled cron jobs that might be related to security or to evade some detections. We also saw that this technique can be a good indicator for malware that is trying to wipe or delete several files on the compromised host like the acidrain malware. This anomaly detection can be a good pivot detection to look for process and user doing it why they doing. Take note that this event can be done by administrator so filtering on those possible false positive event is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Deletion Of Init Daemon Script - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a deletion of init daemon script in a linux machine. daemon script that place in /etc/init.d/ is a directory that can start and stop some daemon services in linux machines. attacker may delete or modify daemon script to impair some security features or act as defense evasion in a compromised linux machine. This TTP can be also a good indicator of a malware trying to wipe or delete several files in compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Deletion Of Services - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a deletion of services in a linux machine. attacker may delete or modify services to impair some security features or act as defense evasion in a compromised linux machine. This TTP can be also a good indicator of a malware trying to wipe or delete several files in a compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Deletion of SSL Certificate - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a deletion of ssl certificate in a linux machine. attacker may delete or modify ssl certificate to impair some security features or act as defense evasion in compromised linux machine. This Anomaly can be also a good indicator of a malware trying to wipe or delete several files in a compromised host as part of its destructive payload like what acidrain malware does in linux or router machines. This detection can be a good pivot to check what process and user tries to delete this type of files which is not so common and need further investigation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Disable Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to detect events that attempts to disable a service. This is typically identified in parallel with other instances of service enumeration of attempts to stop a service and then delete it. Adversaries utilize this technique like industroyer2 malware to terminate security services or other related services to continue there objective as a destructive payload.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Doas Conf File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect the creation of doas.conf file in linux host platform. This configuration file can be use by doas utility tool to allow or permit standard users to perform tasks as root, the same way sudo does. This tool is developed as a minimalistic alternative to sudo application. This tool can be abused advesaries, attacker or malware to gain elevated privileges to the targeted or compromised host. On the other hand this can also be executed by administrator for a certain task that needs admin rights. In this case filter is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Doas Tool Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect the doas tool execution in linux host platform. This utility tool allow standard users to perform tasks as root, the same way sudo does. This tool is developed as a minimalistic alternative to sudo application. This tool can be abused advesaries, attacker or malware to gain elevated privileges to the targeted or compromised host. On the other hand this can also be executed by administrator for a certain task that needs admin rights. In this case filter is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Docker Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Docker is an open source containerization platform. It helps programmers to bundle applications into containers, which are standardized executable parts that include the application source code along with the OS libraries and dependencies needed to run that code in any setting. The user can add mount the root directory into a container and edit the /etc/password file to add a super user. This requires the user to be privileged enough to run docker, i.e. being in the docker group or being root.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Edit Cron Table Parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the suspicious editing of cron jobs in Linux via the crontab command-line parameter. This tactic could be used by adversaries or malware to schedule execution of their malicious code, potentially leading to system compromise or unauthorized persistent access. It pinpoints this activity by monitoring command-line executions involving 'crontab' and the edit parameter (-e).\
Recognizing such activity is vital for a SOC as cron job manipulations might signal unauthorized persistence attempts or scheduled malicious actions, potentially resulting in substantial harm. A true positive signifies an active threat, with implications ranging from unauthorized access to broader network compromise.\
To implement this analytic, logs capturing process name, parent process, and command-line executions from your endpoints must be ingested.\
Known false positives could stem from valid administrative tasks or automation processes using crontab. To reduce these, fine-tune the filter macros according to the benign activities within your environment. These adjustments ensure legitimate actions aren't mistaken for threats, allowing analysts to focus on genuine potential risks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Emacs Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = EMACS is a family of text editors that are characterized by their extensibility. The manual for the most widely used variant, GNU Emacs, describes it as "the extensible, customizable, self-documenting, real-time display editor". If sudo right is given to EMACS tool for the user, then the user can run special commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux File Created In Kernel Driver Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious file creation in kernel/driver directory in linux platform. This directory is known folder for all linux kernel module available within the system. so creation of file in this directory is a good indicator that there is a possible rootkit installation in the host machine. This technique was abuse by adversaries, malware author and red teamers to gain high privileges to their malicious code such us in kernel level. Even this event is not so common administrator or legitimate 3rd party tool may install driver or linux kernel module as part of its installation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.006", "T1547"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can create file in this folders for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux File Creation In Init Boot Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious file creation on init system directories for automatic execution of script or file upon boot up. This technique is commonly abuse by adversaries, malware author and red teamer to persist on the targeted or compromised host. This behavior can be executed or use by an administrator or network operator to add script files or binary files as part of a task or automation. filter is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1037.004", "T1037"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can create file in this folders for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux File Creation In Profile Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious file creation in /etc/profile.d directory to automatically execute scripts by shell upon boot up of a linux machine. This technique is commonly abused by adversaries, malware and red teamers as a persistence mechanism to the targeted or compromised host. This Anomaly detection is a good indicator that someone wants to run a code after boot up which can be done also by the administrator or network operator for automation purposes.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.004", "T1546"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can create file in profile.d folders for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Find Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Find is a command-line utility that locates files based on some user-specified criteria and either prints the pathname of each matched object or, if another action is requested, performs that action on each matched object. If sudo right is given to find utility for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux GDB Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = GDB is the acronym for GNU Debugger. This tool helps to debug the programs written in C, C++, Ada, Fortran, etc. The console can be opened using the gdb command on terminal. If sudo right is given to GDB tool for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Gem Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = RubyGems is a package manager for the Ruby programming language that provides a standard format for distributing Ruby programs and libraries (in a self-contained format called a "gem"), a tool designed to easily manage the installation of gems, and a server for distributing them. If sudo right is given to GEM utility for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux GNU Awk Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = gawk command in Linux is used for pattern scanning and processing language. The awk command requires no compiling and allows the user to use variables, numeric functions, string functions, and logical operators. It is a utility that enables programmers to write tiny and effective programs in the form of statements that define text patterns that are to be searched for, in a text document and the action that is to be taken when a match is found within a line. If sudo right is given to gawk tool for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Hardware Addition SwapOff - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for process execution to disable the swapping of paging devices. This technique was seen in Awfulshred malware that disables the swapping of the specified devices and files. This anomaly detection can be a good indicator that a process or a user tries to disable this Linux feature in a targeted host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1200"], "nist": ["DE.AE"]}
known_false_positives = administrator may disable swapping of devices in a linux host. Filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux High Frequency Of File Deletion In Boot Folder - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a high frequency of file deletion relative to process name and process id /boot/ folder. These events was seen in industroyer2 wiper malware where it tries to delete all files in a critical directory in linux directory. This detection already contains some filter that might cause false positive during our testing.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]}
known_false_positives = linux package installer/uninstaller may cause this event. Please update you filter macro to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux High Frequency Of File Deletion In Etc Folder - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to detect a high frequency of file deletion relative to process name and process id /etc/ folder. These events was seen in acidrain wiper malware where it tries to delete all files in a non-standard directory in linux directory. This detection already contains some filter that might cause false positive during our testing. But we recommend to add more filter if needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.AE"]}
known_false_positives = linux package installer/uninstaller may cause this event. Please update you filter macro to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Impair Defenses Process Kill - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for PKILL process execution for possible termination of process. This technique is being used by several Threat actors, adversaries and red teamers to terminate processes in a targeted linux machine. This Hunting detection can be a good pivot to check a possible defense evasion technique or termination of security application in a linux host or wiper like Awfulshred that corrupt all files.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = network admin can terminate a process using this linux command. Filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Indicator Removal Clear Cache - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for processes that clear or free page cache in Linux system host. This technique was seen in Awfulshred malware wiper that tries to clear the cache using kernel system request drop_caches while wiping all files in the targeted host. This TTP detection can be a good indicator of user or process tries to clear page cache to delete tracks or might be a wiper like Awfulshred.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Indicator Removal Service File Deletion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious linux processes that delete service unit configuration files. This technique was seen in several malware to delete service configuration files to corrupt a services or security product as part of its defense evasion. This TTP detection can be a good indicator of possible malware try to kill several services or a wiper like AwfulShred shell script that wipes the targeted linux host
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070.004", "T1070"], "nist": ["DE.AE"]}
known_false_positives = network admin can delete services unit configuration file as part of normal software installation. Filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Ingress Tool Transfer Hunting - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic hunts for curl and wget being utilized in the environment. This is meant to help with identifying normal usage and potentially malicious. Utilize this query to tune other curl and wget analytics.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present. This query is meant to help tune other curl and wget analytics.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Ingress Tool Transfer with Curl - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies curl with the command-line switches that are commonly used to download, output, a remote script or binary. MetaSploit Framework will combine the -sO switch with | chmod +x to enable a simple one liner to download and set the execute bit to run the file immediately. During triage, review the remote domain and file being downloaded for legitimacy.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present. Tune and then change type to TTP.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Insert Kernel Module Using Insmod Utility - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for inserting of linux kernel module using insmod utility function. This event can detect a installation of rootkit or malicious kernel module to gain elevated privileges to their malicious code and bypassed detections. This Anomaly detection is a good indicator that someone installing kernel module in a linux host either admin or adversaries. filter is needed in this scenario
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.006", "T1547"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Install Kernel Module Using Modprobe Utility - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for possible installing a linux kernel module using modprobe utility function. This event can detect a installation of rootkit or malicious kernel module to gain elevated privileges to their malicious code and bypassed detections. This Anomaly detection is a good indicator that someone installing kernel module in a linux host either admin or adversaries. filter is needed in this scenario
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.006", "T1547"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Iptables Firewall Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious commandline that modify the iptables firewall setting of a linux machine. This technique was seen in cyclopsblink malware where it modifies the firewall setting of the compromised machine to allow traffic to its tcp port that will be used to communicate with its C2 server.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]}
known_false_positives = administrator may do this commandline for auditing and testing purposes. In this scenario filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Java Spawning Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the process name of Java, Apache, or Tomcat spawning a Linux shell. This is potentially indicative of exploitation of the Java application and may be related to current event CVE-2021-44228 (Log4Shell). The shells included in the macro are "sh", "ksh", "zsh", "bash", "dash", "rbash", "fish", "csh', "tcsh', "ion", "eshell". Upon triage, review parallel processes and command-line arguments to determine legitimacy.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = Filtering may be required on internal developer build systems or classify assets as web facing and restrict the analytic based on asset type.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Kernel Module Enumeration - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the process kmod being utilized to list kernel modules in use. Typically, this is not seen as malicious, however it may be a precurser to the use of insmod to install a module.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082", "T1014"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Kworker Process In Writable Process Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious process kworker commandline in a linux machine. kworker process name or thread are common names of kernel threads in linux process. This hunting detections can lead to investigate process contains process path in writable directory in linux like /home/, /var/log and /tmp/. This technique was seen in cyclopsblink malware to blend its core and other of its child process as normal kworker on the compromised machine. This detection might be a good pivot to look for other IOC related to cyclopsblink malware or attacks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.004", "T1036"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Make Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The Linux make command is used to build and maintain groups of programs and files from the source code. In Linux, it is one of the most frequently used commands by the developers. It assists developers to install and compile many utilities from the terminal. If sudo right is given to make utility for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux MySQL Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = MySQL is an open-source relational database management system. Its name is a combination of "My", the name of co-founder Michael Widenius's daughter My, and "SQL", the abbreviation for Structured Query Language. If sudo right is given to mysql utility for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Ngrok Reverse Proxy Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Ngrok being utilized on the Linux operating system. Unfortunately, there is no original file name for Ngrok, so it may be worth an additional hunt to identify any command-line arguments. The sign of someone using Ngrok is not malicious, however, more recently it has become an adversary tool.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1572", "T1090", "T1102"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if Ngrok is an authorized utility. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Node Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Node.js is a back-end JavaScript runtime environment that is open-source, cross-platform, runs on the V8 engine, and executes JavaScript code outside of a web browser. It was created to help create scalable network applications. If the binary is allowed to run as superuser by sudo, it does not drop the elevated privileges and may be used to access the file system, escalate or maintain privileged access.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux NOPASSWD Entry In Sudoers File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for suspicious command lines that may add entry to /etc/sudoers with NOPASSWD attribute in linux platform. This technique is commonly abuse by adversaries, malware author and red teamers to gain elevated privilege to the targeted or compromised host. /etc/sudoers file controls who can run what commands users can execute on the machines and can also control whether user need a password to execute particular commands. This file is composed of aliases (basically variables) and user specifications.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Obfuscated Files or Information Base64 Decode - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of base64 decode on Linux being utilized to deobfuscate a file. Identify the source of the file and determine if legitimate. Review parallel processes for further behavior before and after.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present and will require some tuning based on processes. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Octave Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = GNU Octave is a high-level programming language primarily intended for scientific computing and numerical computation. Octave helps in solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with MATLAB. If sudo right is given to the application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux OpenVPN Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = OpenVPN is a virtual private network system that implements techniques to create secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It implements both client and server applications. If sudo right is given to the OpenVPN application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Persistence and Privilege Escalation Risk Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following correlation is specific to Linux persistence and privilege escalation tactics and is tied to two analytic stories and any Linux analytic tied to persistence and privilege escalation. These techniques often overlap with Persistence techniques, as OS features that let an adversary persist can execute in an elevated context.
how_to_implement = Ensure Linux anomaly and TTP analytics are enabled. TTP may be set to Notables for point detections, anomaly should not be notables but risk generators. The correlation relies on more than x amount of distict detection names generated before generating a notable. Modify the value as needed. Default value is set to 4. This value may need to be increased based on activity in your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers.
providing_technologies = null

[savedsearch://ESCU - Linux PHP Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = PHP is a general-purpose scripting language geared toward web development. It was originally created by Danish-Canadian programmer Rasmus Lerdorf in 1994. The PHP reference implementation is now produced by The PHP Group. If sudo right is given to php application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux pkexec Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `pkexec` spawning with no command-line arguments. A vulnerability in Polkit's pkexec component identified as CVE-2021-4034 (PwnKit) which is present in the default configuration of all major Linux distributions and can be exploited to gain full root privileges on the system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Access Or Modification Of sshd Config File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for suspicious process command-line that might be accessing or modifying sshd_config. This file is the ssh configuration file that might be modify by threat actors or adversaries to redirect port connection, allow user using authorized key generated during attack. This anomaly detection might catch noise from administrator auditing or modifying ssh configuration file. In this scenario filter is needed
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.004", "T1098"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Access To Credential Files - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a possible attempt to dump or access the content of /etc/passwd and /etc/shadow to enable offline credential cracking. "etc/passwd" store user information within linux OS while "etc/shadow" contain the user passwords hash. Adversaries and threat actors may attempt to access this to gain persistence and/or privilege escalation. This anomaly detection can be a good indicator of possible credential dumping technique but it might catch some normal administrator automation scripts or during credential auditing. In this scenario filter is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.008", "T1003"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Access To Sudoers File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a possible access or modification of /etc/sudoers file. "/etc/sudoers" file controls who can run what command as what users on what machine and can also control whether a specific user need a password for particular commands.  adversaries and threat actors abuse this file to gain persistence and/or privilege escalation during attack on targeted host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Append Command To At Allow Config File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to identify suspicious command lines that may append user entries to either /etc/at.allow or /etc/at.deny. These files can be exploited by malicious actors for persistence on a compromised Linux host by altering permissions for scheduled tasks using the at command.\
In this context, an attacker can create a user or add an existing user to these configuration files to execute their malicious code through scheduled tasks. The detection of such anomalous behavior can serve as an effective indicator warranting further investigation to validate if the activity is indeed malicious or a false positive.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.002", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Append Command To Profile Config File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious command-lines that can be possibly used to modify user profile files to automatically execute scripts/executables by shell upon reboot of the machine. This technique is commonly abused by adversaries, malware and red teamers as persistence mechanism to the targeted or compromised host. This Anomaly detection is a good indicator that someone wants to run code after reboot which can be done also by the administrator or network operator for automation purposes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.004", "T1546"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Append Cronjob Entry on Existing Cronjob File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect potential tampering with cronjob files on a Linux system. It specifically searches for command lines that may be used to append code to existing cronjob files, a technique often employed by adversaries, malware, and red teamers for persistence or privilege escalation. Altering existing or sometimes normal cronjob script files allows malicious code to be executed automatically.\
The analytic operates by monitoring logs for specific process names, parent processes, and command-line executions from your endpoints. It specifically checks for any 'echo' command which modifies files in directories commonly associated with cron jobs such as '/etc/cron*', '/var/spool/cron/', and '/etc/anacrontab'. If such activity is detected, an alert is triggered.\
This behavior is worth identifying for a SOC because malicious cron jobs can lead to system compromises and unauthorized data access, impacting business operations and data integrity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]}
known_false_positives = False positives may arise from legitimate actions by administrators or network operators who may use these commands for automation purposes. Therefore, it's recommended to adjust filter macros to eliminate such false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Cronjob Modification With Editor - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects potential unauthorized modifications to Linux cronjobs using text editors like "nano", "vi" or "vim". It identifies this behavior by tracking command-line executions that interact with paths related to cronjob configuration, a common Linux scheduling utility. Cronjob files may be manipulated by attackers for privilege escalation or persistent access, making such changes critical to monitor.\ The identified behavior is significant for a Security Operations Center (SOC) as it could indicate an ongoing attempt at establishing persistent access or privilege escalation, leading to data breaches, system compromise, or other malicious activities.\
In case of a true positive, the impact could be severe. An attacker with escalated privileges or persistent access could carry out damaging actions, such as data theft, sabotage, or further network penetration.\
To implement this analytic, ensure ingestion of logs tracking process name, parent process, and command-line executions from your endpoints. Utilize the Add-on for Linux Sysmon from Splunkbase if you're using Sysmon.\
Known false positives include legitimate administrative tasks, as these commands may also be used for benign purposes. Careful tuning and filtering based on known benign activity in your environment can minimize these instances.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.003", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Possible Ssh Key File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for possible ssh key file creation on ~/.ssh/ folder. This technique is commonly abused by threat actors and adversaries to gain persistence and privilege escalation to the targeted host. by creating ssh private and public key and passing the public key to the attacker server. threat actor can access remotely the machine using openssh daemon service.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.004", "T1098"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can create file in ~/.ssh folders for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Preload Hijack Library Calls - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious command that may hijack a library function in linux platform. This technique is commonly abuse by adversaries, malware author and red teamers to gain privileges and persist on the machine. This detection pertains to loading a dll to hijack or hook a library function of specific program using LD_PRELOAD command.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.006", "T1574"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Proxy Socks Curl - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies curl being utilized with a proxy based on command-line arguments - -x, socks, --preproxy and --proxy. This behavior is built into the MetaSploit Framework as a auxiliary module. What does socks buy an adversary? SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address. The SOCKS5 protocol is defined in RFC 1928. It is an incompatible extension of the SOCKS4 protocol; it offers more choices for authentication and adds support for IPv6 and UDP, the latter of which can be used for DNS lookups. The protocols, and a proxy itself, allow an adversary to evade controls in place monitoring traffic, making it harder for the defender to identify and track activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090", "T1095"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on proxy usage internally. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Puppet Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = In computing, Puppet is a software configuration management tool which includes its own declarative language to describe system configuration. It is a model-driven solution that requires limited programming knowledge to use. If sudo right is given to the tool for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux RPM Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = RPM Package Manager is a free and open-source package management system. The name RPM refers to the .rpm file format and the package manager program itself. RPM was intended primarily for Linux distributions; the file format is the baseline package format of the Linux Standard Base. If sudo right is given to rpm utility for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Ruby Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Ruby is one of the most used and easy to use programming languages. Ruby is an open-source, object-oriented interpreter that can be installed on a Linux system. If sudo right is given to ruby application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives are present based on automated tooling or system administrative usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Service File Created In Systemd Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect suspicious file creation within the systemd timer directory on Linux platforms. Systemd is a system and service manager for Linux, similar to the combination of wininit.exe and services.exe on Windows. This process initializes a Linux system and starts defined services in unit files. Malicious actors, such as adversaries, malware, or red teamers, can exploit this feature by embedding a systemd service file for persistence on the targeted or compromised host.\
The analytic works by monitoring logs with file name, file path, and process GUID data from your endpoints. If a .service file is created in certain systemd directories, the analytic triggers an alert. This behavior is significant for a Security Operations Center (SOC) as it may indicate a persistent threat within the network, with a potential impact of system compromise or data exfiltration.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the file name, file path, and process_guid executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.006", "T1053"], "nist": ["DE.AE"]}
known_false_positives = False positives may arise when administrators or network operators create files in systemd directories for legitimate automation tasks. Therefore, it's important to adjust filter macros to account for valid activities. To implement this search successfully, it's crucial to ingest appropriate logs, preferably using the Linux Sysmon Add-on from Splunkbase for those using Sysmon.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Service Restarted - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the restarting or re-enabling of services in the Linux platform. It focuses on the use of the systemctl or service tools for executing these actions. Adversaries may leverage this technique to repeatedly execute malicious payloads as a form of persistence. Linux hosts typically start services during boot to perform background system functions. However, administrators may also create legitimate services for specific tools or applications as part of task automation. In such cases, it is recommended to verify the service path of the registered script or executable and identify the creator of the service for further validation.\
It's important to be aware that this analytic may generate false positives as administrators or network operators may use the same command-line for legitimate automation purposes. Filter macros should be updated accordingly to minimize false positives.\
Identifying restarted or re-enabled services is valuable for a SOC as it can indicate potential malicious activities attempting to maintain persistence or execute unauthorized actions on Linux systems. By detecting and investigating these events, security analysts can respond promptly to mitigate risks and prevent further compromise. The impact of a true positive can range from unauthorized access to data destruction or other damaging outcomes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.006", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Service Started Or Enabled - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation or enabling of services in Linux platforms, specifically using the systemctl or service tool application. This behavior is worth identifying as adversaries may create or modify services to execute malicious payloads as part of persistence. Legitimate services created by administrators for automation purposes may also trigger this analytic, so it is important to update the filter macros to remove false positives. If a true positive is found, it suggests an possible attacker is attempting to persist within the environment or deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, ensure you are ingesting logs with the process name, parent process, and command-line executions from your endpoints.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.006", "T1053"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can use this commandline for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Setuid Using Chmod Utility - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious chmod utility execution to enable SUID bit. This allows a user to temporarily gain root access, usually in order to run a program. For example, only the root account is allowed to change the password information contained in the password database; If the SUID bit appears as an s, the file's owner also has execute permission to the file; if it appears as an S, the file's owner does not have execute permission. The second specialty permission is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily change group membership, usually to execute a program. The SGID bit is set if an s or an S appears in the group section of permissions.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.001", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Setuid Using Setcap Utility - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious setcap utility execution to enable SUID bit. This allows a user to temporarily gain root access, usually in order to run a program. For example, only the root account is allowed to change the password information contained in the password database; If the SUID bit appears as an s, the file's owner also has execute permission to the file; if it appears as an S, the file's owner does not have execute permission. The second specialty permission is the SGID, or set group id bit. It is similar to the SUID bit, except it can temporarily change group membership, usually to execute a program. The SGID bit is set if an s or an S appears in the group section of permissions.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.001", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Shred Overwrite Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a shred process to overwrite a files in a linux machine. Shred Linux application is designed to overwrite file to hide its contents or make the deleted file un-recoverable. Weve seen this technique in industroyer2 malware that tries to wipe energy facilities of targeted sector as part of its destructive attack. It might be some normal user may use this command for valid purposes but it is recommended to check what files, disk or folder it tries to shred that might be good pivot for incident response in this type of destructive malware.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Sqlite3 Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = sqlite3 is a terminal-based front-end to the SQLite library that can evaluate queries interactively and display the results in multiple formats. sqlite3 can also be used within shell scripts and other applications to provide batch processing features. If sudo right is given to this application for the user, then the user can run system commands as root and possibly get a root shell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux SSH Authorized Keys Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies based on process execution the modification of SSH Authorized Keys. Adversaries perform this behavior to persist on endpoints. During triage, review parallel processes and capture any additional file modifications for review.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098.004"], "nist": ["DE.AE"]}
known_false_positives = Filtering will be required as system administrators will add and remove. One way to filter query is to add "echo".
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux SSH Remote Services Script Execute - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies SSH being utilized to move laterally and execute a script or file on the remote host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.004"], "nist": ["DE.CM"]}
known_false_positives = This is not a common command to be executed. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Stdout Redirection To Dev Null File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for suspicious commandline that redirect the stdout or possible stderror to dev/null file. This technique was seen in cyclopsblink malware where it redirect the possible output or error while modify the iptables firewall setting of the compromised machine to hide its action from the user. This Anomaly detection is a good pivot to look further why process or user use this un common approach.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Stop Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to detect events that attempt to stop or clear a service. This is typically identified in parallel with other instances of service enumeration of attempts to stop a service and then delete it. Adversaries utilize this technique like industroyer2 malware to terminate security services or other related services to continue there objective as a destructive payload.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]}
known_false_positives = Administrator or network operator can use this application for automation purposes. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Sudo OR Su Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect the execution of sudo or su command in linux operating system. The "sudo" command allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments. This command is commonly abused by adversaries, malware author and red teamers to elevate privileges to the targeted host. This command can be executed by administrator for legitimate purposes or to execute process that need admin privileges, In this scenario filter is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Sudoers Tmp File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to looks for file creation of sudoers.tmp file cause by editing /etc/sudoers using visudo or editor in linux platform. This technique may abuse by adversaries, malware author and red teamers to gain elevated privilege to targeted or compromised host. /etc/sudoers file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands. The file is composed of aliases (basically variables) and user specifications (which control who can run what).
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you can use the Add-on for Linux Sysmon from Splunkbase.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux System Network Discovery - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This analytic is to look for possible enumeration of local network configuration. This technique is commonly used as part of recon of adversaries or threat actor to know some network information for its next or further attack. This anomaly detections may capture normal event made by administrator during auditing or testing network connection of specific host or network to network.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux System Reboot Via System Request Key - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for possible execution of SysReq hack to reboot the Linux system host. This technique was seen in Awfulshred malware wiper to reboot the compromised host by using the linux magic sysreq key. This kernel configuration can trigger reboot by piping out 'b' to /proc/sysrq-trigger after enabling all the functions of sysrq. This TTP detection can be a good indicator of possible suspicious processes running on the Linux host since this command is not a common way to reboot a system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Unix Shell Enable All SysRq Functions - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for possible execution of SysReq hack to enable all functions of kernel system requests of the Linux system host. This technique was seen in AwfulShred malware wiper to reboot the compromised host by using the linux magic sysreq key. This kernel configuration can be triggered by piping out bitmask '1' to /proc/sys/kernel/sysrq. This TTP detection can be a good indicator of possible suspicious processes running on the Linux host since this command is not so common shell commandline.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.004", "T1059"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Linux Visudo Utility Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to looks for suspicious commandline that add entry to /etc/sudoers by using visudo utility tool in linux platform. This technique may abuse by adversaries, malware author and red teamers to gain elevated privilege to targeted or compromised host. /etc/sudoers file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands. The file is composed of aliases (basically variables) and user specifications (which control who can run what).
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.003", "T1548"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator can execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Living Off The Land - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following correlation identifies a distinct amount of analytics associated with the Living Off The Land analytic story that identify potentially suspicious behavior.
how_to_implement = To implement this correlation search a user needs to enable all detections in the Living Off The Land Analytic Story and confirm it is generating risk events. A simple search `index=risk analyticstories="Living Off The Land"` should contain events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Delivery", "Installation"], "mitre_attack": ["T1105", "T1190", "T1059", "T1133"], "nist": ["DE.AE"]}
known_false_positives = There are no known false positive for this search, but it could contain false positives as multiple detections can trigger and not have successful exploitation. Modify the static value distinct_detection_name to a higher value. It is also required to tune analytics that are also tagged to ensure volume is never too much.
providing_technologies = null

[savedsearch://ESCU - Loading Of Dynwrapx Module - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = DynamicWrapperX is an ActiveX component that can be used in a script to call Windows API functions, but it requires the dynwrapx.dll to be installed and registered. With that, registering or loading dynwrapx.dll to a host is highly suspicious. In most instances when it is used maliciously, the best way to triage is to review parallel processes and pivot on the process_guid. Review the registry for any suspicious modifications meant to load dynwrapx.dll. Identify any suspicious module loads of dynwrapx.dll. This detection will return and identify the processes that invoke vbs/wscript/cscript.
how_to_implement = To successfully implement this search you need to be ingesting information on processes that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, however it is possible to filter by Processes.process_name and specific processes (ex. wscript.exe). Filter as needed. This may need modification based on EDR telemetry and how it brings in registry data. For example, removal of (Default).
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Local Account Discovery with Net - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to query for local users. The two arguments `user` and 'users', return a list of all local users. Red Teams and adversaries alike use net.exe to enumerate users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Local Account Discovery With Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to query for local users. The argument `useraccount` is used to leverage WMI to return a list of all local users. Red Teams and adversaries alike use net.exe to enumerate users for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Log4Shell CVE-2021-44228 Exploitation - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This correlation find exploitation of Log4Shell CVE-2021-44228 against systems using detections from Splunk Security Content Analytic Story. It does this by calculating the distinct count of MITRE ATT&CK tactics from Log4Shell detections fired. If the count is larger than 2 or more distinct MITRE ATT&CK tactics we assume high problability of exploitation. The Analytic story breaks down into 3 major phases of a Log4Shell exploitation, specifically> Initial Payload delivery eg. `${jndi:ldap://PAYLOAD_INJECTED}` Call back to malicious LDAP server eg. Exploit.class Post Exploitation Activity/Lateral Movement using Powershell or similar T1562.001 Each of these phases fall into different MITRE ATT&CK Tactics (Initial Access, Execution, Command And Control), by looking into 2 or more phases showing up in detections triggerd is how this correlation search finds exploitation. If we get a notable from this correlation search the best way to triage it is by investigating the affected systems against Log4Shell exploitation using Splunk SOAR playbooks.
how_to_implement = To implement this correlation search a user needs to enable all detections in the Log4Shell Analytic Story and confirm it is generation risk events. A simple search `index=risk analyticstories="Log4Shell CVE-2021-44228"` should contain events.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Delivery", "Installation"], "mitre_attack": ["T1105", "T1190", "T1059", "T1133"], "nist": ["DE.AE"]}
known_false_positives = There are no known false positive for this search, but it could contain false positives as multiple detections can trigger and not have successful exploitation.
providing_technologies = null

[savedsearch://ESCU - Logon Script Event Trigger Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious modification of registry entry to persist and gain privilege escalation upon booting up of compromised host. This technique was seen in several APT and malware where it modify UserInitMprLogonScript registry entry to its malicious payload to be executed upon boot up of the machine.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1037", "T1037.001"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - LOLBAS With Network Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies LOLBAS with network traffic. When adversaries abuse LOLBAS they are often used to download malicious code or executables. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like downloading malicious code. Looking for these process can help defenders identify lateral movement, command-and-control, or exfiltration activies.
how_to_implement = To successfully implement this detection you must ingest events into the Network traffic data model that contain the source, destination, and communicating process in the app feild. Relevant processes must also be ingested in the Endpoint data model with matching process_id feild. Sysmon EID1 and EID3 are good examples of this type this data type.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control", "Actions on Objectives", "Exploitation"], "mitre_attack": ["T1105", "T1567", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Legitmate usage of internal automation or scripting, espically powershell.exe internal to internal or logon scripts. It may be necessary to omit internal IP ranges if extremely noisy. ie NOT dest_ip IN ("10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","170.98.0.0/16","0:0:0:0:0:0:0:1") 
providing_technologies = null

[savedsearch://ESCU - MacOS - Re-opened Applications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes referencing the plist files that determine which applications are re-opened when a user reboots their machine.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = At this stage, there are no known false positives. During testing, no process events refering the com.apple.loginwindow.plist files were observed during normal operation of re-opening applications on reboot. Therefore, it can be asumed that any occurences of this in the process events would be worth investigating. In the event that the legitimate modification by the system of these files is in fact logged to the process log, then the process_name of that process can be added to an allow list.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - MacOS LOLbin - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Detect multiple executions of Living off the Land (LOLbin) binaries in a short period of time.
how_to_implement = This detection uses osquery and endpoint security on MacOS. Follow the link in references, which describes how to setup process auditing in MacOS with endpoint security and osquery.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.004", "T1059"], "nist": ["DE.CM"]}
known_false_positives = None identified.
providing_technologies = null

[savedsearch://ESCU - MacOS plutil - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Detect usage of plutil to modify plist files. Adversaries can modiy plist files to executed binaries or add command line arguments. Plist files in auto-run locations are executed upon user logon or system startup.
how_to_implement = This detection uses osquery and endpoint security on MacOS. Follow the link in references, which describes how to setup process auditing in MacOS with endpoint security and osquery.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1647"], "nist": ["DE.CM"]}
known_false_positives = Administrators using plutil to change plist files.
providing_technologies = null

[savedsearch://ESCU - Mailsniper Invoke functions - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect known mailsniper.ps1 functions executed in a machine. This technique was seen in some attacker to harvest some sensitive e-mail in a compromised exchange server.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs  from your endpoints. make sure you enable needed registry to monitor this event.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114", "T1114.001"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Malicious InProcServer32 Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process modifying the registry with a known malicious CLSID under InProcServer32. Most COM classes are registered with the operating system and are identified by a GUID that represents the Class Identifier (CLSID) within the registry (usually under HKLM\\Software\\Classes\\CLSID or HKCU\\Software\\Classes\\CLSID).  Behind the implementation of a COM class is the server (some binary) that is referenced within registry keys under the CLSID.  The LocalServer32 key represents a path to an executable (exe) implementation, and the InprocServer32 key represents a path to a dynamic link library (DLL) implementation (Bohops). During triage, review parallel processes for suspicious activity. Pivot on the process GUID to see the full timeline of events. Analyze the value and look for file modifications. Being this is looking for inprocserver32, a DLL found in the value will most likely be loaded by a parallel process.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.010", "T1112"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, filter as needed. In our test case, Remcos used regsvr32.exe to modify the registry. It may be required, dependent upon the EDR tool producing registry events, to remove (Default) from the command-line.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Malicious Powershell Executed As A Service - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection is to identify the abuse the Windows SC.exe to execute malicious commands or payloads via PowerShell.
how_to_implement = To successfully implement this search, you need to be ingesting Windows System logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.CM"]}
known_false_positives = Creating a hidden powershell service is rare and could key off of those instances.
providing_technologies = null

[savedsearch://ESCU - Malicious PowerShell Process - Encoded Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of the EncodedCommand PowerShell parameter. This is typically used by Administrators to run complex scripts, but commonly used by adversaries to hide their code. \
The analytic identifies all variations of EncodedCommand, as PowerShell allows the ability to shorten the parameter. For example enc, enco, encod and so forth. In addition, through our research it was identified that PowerShell will interpret different command switch types beyond the hyphen. We have added endash, emdash, horizontal bar, and forward slash. \
During triage, review parallel events to determine legitimacy. Tune as needed based on admin scripts in use. \
Alternatively, may use regex per matching here https://regexr.com/662ov.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027"], "nist": ["DE.AE"]}
known_false_positives = System administrators may use this option, but it's not common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Malicious PowerShell Process - Execution Policy Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for PowerShell processes started with parameters used to bypass the local execution policy for scripts. These parameters are often observed in attacks leveraging PowerShell scripts as they override the default PowerShell execution policy.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = There may be legitimate reasons to bypass the PowerShell execution policy. The PowerShell script being run with this parameter should be validated to ensure that it is legitimate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Malicious PowerShell Process With Obfuscation Techniques - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for PowerShell processes launched with arguments that have characters indicative of obfuscation on the command-line.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = These characters might be legitimately on the command-line, but it is not common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Mimikatz PassTheTicket CommandLine Parameters - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic looks for the use of Mimikatz command line parameters leveraged to execute pass the ticket attacks. Red teams and adversaries alike may use the pass the ticket technique using stolen Kerberos tickets to move laterally within an environment, bypassing normal system access controls. Defenders should be aware that adversaries may customize the source code of Mimikatz and modify the command line parameters. This would effectively bypass this analytic.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.003"], "nist": ["DE.CM"]}
known_false_positives = Although highly unlikely, legitimate applications may use the same command line parameters as Mimikatz.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Mmc LOLBAS Execution Process Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `mmc.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing the DCOM protocol and the MMC20 COM object, the executed command is spawned as a child processs of `mmc.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of mmc.exe that are part of the LOLBAS project can help defenders identify lateral movement activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.003", "T1218.014"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may trigger this behavior, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Modification Of Wallpaper - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious modification of registry to deface or change the wallpaper of a compromised machines as part of its payload. This technique was commonly seen in ransomware like REVIL where it create a bitmap file contain a note that the machine was compromised and make it as a wallpaper.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Image, TargetObject registry key, registry Details from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1491"], "nist": ["DE.CM"]}
known_false_positives = 3rd party tool may used to changed the wallpaper of the machine
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Modify ACL permission To Files Or Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious modification of ACL permission to a files or folder to make it available to everyone. This technique may be used by the adversary to evade ACLs or protected files access. This changes is commonly configured by the file or directory owner with appropriate permission. This behavior is a good indicator if this command seen on a machine utilized by an account with no permission to do so.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.AE"]}
known_false_positives = administrators may use this command. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Monitor Registry Keys for Print Monitors - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for registry activity associated with modifications to the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors`. In this scenario, an attacker can load an arbitrary .dll into the print-monitor registry by giving the full path name to the after.dll. The system will execute the .dll with elevated (SYSTEM) permissions and will persist after reboot.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.010", "T1547"], "nist": ["DE.CM"]}
known_false_positives = You will encounter noise from legitimate print-monitor registry entries.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - MS Exchange Mailbox Replication service writing Active Server Pages - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following query identifies suspicious .aspx created in 3 paths identified by Microsoft as known drop locations for Exchange exploitation related to HAFNIUM group and recently disclosed vulnerablity named ProxyShell. Paths include: `\HttpProxy\owa\auth\`, `\inetpub\wwwroot\aspnet_client\`, and `\HttpProxy\OAB\`. The analytic is limited to process name MSExchangeMailboxReplication.exe, which typically does not write .aspx files to disk. Upon triage, the suspicious .aspx file will likely look obvious on the surface. inspect the contents for script code inside. Identify additional log sources, IIS included, to review source and other potential exploitation. It is often the case that a particular threat is only applicable to a specific subset of systems in your environment. Typically analytics to detect those threats are written without the benefit of being able to only target those systems as well. Writing analytics against all systems when those behaviors are limited to identifiable subsets of those systems is suboptimal. Consider the case ProxyShell vulnerability on Microsoft Exchange Servers. With asset information, a hunter can limit their analytics to systems that have been identified as Exchange servers. A hunter may start with the theory that the exchange server is communicating with new systems that it has not previously. If this theory is run against all publicly facing systems, the amount of noise it will generate will likely render this theory untenable. However, using the asset information to limit this analytic to just the Exchange servers will reduce the noise allowing the hunter to focus only on the systems where this behavioral change is relevant.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505", "T1505.003", "T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - MS Scripting Process Loading Ldap Module - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious MS scripting process such as wscript.exe or cscript.exe that loading ldap module to process ldap query. This behavior was seen in FIN7 implant where it uses javascript to execute ldap query to parse host information that will send to its C2 server. this anomaly detections is a good initial step to hunt further a suspicious ldap query or ldap related events to the host that may give you good information regarding ldap or AD information processing or might be a attacker.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.AE"]}
known_false_positives = automation scripting language may used by network operator to do ldap query.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - MS Scripting Process Loading WMI Module - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious MS scripting process such as wscript.exe or cscript.exe that loading wmi module to process wmi query. This behavior was seen in FIN7 implant where it uses javascript to execute wmi query to parse host information that will send to its C2 server. this anomaly detections is a good initial step to hunt further a suspicious wmi query or wmi related events to the host that may give you good information regarding process that are commonly using wmi query or modules or might be an attacker using this technique.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.007"], "nist": ["DE.AE"]}
known_false_positives = automation scripting language may used by network operator to do ldap query.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - MSBuild Suspicious Spawned By Script Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious child process of MSBuild spawned by Windows Script Host - cscript or wscript. This behavior or event are commonly seen and used by malware or adversaries to execute malicious msbuild process using malicious script in the compromised host. During triage, review parallel processes and identify any file modifications. MSBuild may load a script from the same path without having command-line arguments.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1127.001", "T1127"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as developers do not spawn MSBuild via a WSH.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Mshta spawning Rundll32 OR Regsvr32 Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious mshta.exe process that spawn rundll32 or regsvr32 child process. This technique was seen in several malware nowadays like trickbot to load its initial .dll stage loader to execute and download the the actual trickbot payload.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]}
known_false_positives = limitted. this anomaly behavior is not commonly seen in clean host.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - MSHTML Module Load in Office Product - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the module load of mshtml.dll into an Office product. This behavior has been related to CVE-2021-40444, whereas the malicious document will load ActiveX, which activates the MSHTML component. The vulnerability resides in the MSHTML component. During triage, identify parallel processes and capture any file modifications for analysis.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process names and image loads from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives will be present, however, tune as necessary.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - MSI Module Loaded by Non-System Binary - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies `msi.dll` being loaded by a binary not located in `system32`, `syswow64`, `winsxs` or `windows` paths. This behavior is most recently related to InstallerFileTakeOver, or CVE-2021-41379, and DLL side-loading. CVE-2021-41379 requires a binary to be dropped and `msi.dll` to be loaded by it. To Successful exploitation of this issue happens in four parts \
1. Generation of an MSI that will trigger bad behavior. \
1. Preparing a directory for MSI installation. \
1. Inducing an error state. \
1. Racing to introduce a junction and a symlink to trick msiexec.exe to modify the attacker specified file. \
In addition, `msi.dll` has been abused in DLL side-loading attacks by being loaded by non-system binaries.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.AE"]}
known_false_positives = It is possible some Administrative utilities will load msi.dll outside of normal system paths, filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Msmpeng Application DLL Side Loading - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious creation of msmpeng.exe or mpsvc.dll in non default windows defender folder. This technique was seen with revil ransomware in Kaseya Supply chain. The approach is to drop an old version of msmpeng.exe to load the actual payload name as mspvc.dll which will load the revil ransomware to the compromise machine
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]}
known_false_positives = quite minimal false positive expected.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Net Localgroup Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic will identify the use of localgroup discovery using `net localgroup`. During triage, review parallel processes and identify any further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - NET Profiler UAC bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect modification of registry to bypass UAC windows feature. This technique is to add a payload dll path on .NET COR file path that will be loaded by mmc.exe as soon it was executed. This detection rely on monitoring the registry key and values in the detection area. It may happened that windows update some dll related to mmc.exe and add dll path in this registry. In this case filtering is needed.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = limited false positive. It may trigger by some windows update that will modify this registry.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Network Connection Discovery With Arp - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `arp.exe` utilized to get a listing of network connections on a compromised system. Red Teams and adversaries alike may use arp.exe for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Network Connection Discovery With Net - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` with command-line arguments utilized to get a listing of network connections on a compromised system. Red Teams and adversaries alike may use net.exe for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Network Connection Discovery With Netstat - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `netstat.exe` with command-line arguments utilized to get a listing of network connections on a compromised system. Red Teams and adversaries alike may use netstat.exe for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Network Discovery Using Route Windows App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic look for a spawned process of route.exe windows application. Adversaries and red teams alike abuse this application the recon or do a network discovery on a target host. but one possible false positive might be an automated tool used by a system administator or a powershell script in amazon ec2 config services.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016", "T1016.001"], "nist": ["DE.AE"]}
known_false_positives = A network operator or systems administrator may utilize an automated host discovery application that may generate false positives or an amazon ec2 script that uses this application. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Network Share Discovery Via Dir Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies object access on Windows administrative SMB shares (Admin$, IPC$, C$). This represents suspicious behavior as its commonly used by tools like PsExec/PaExec and others to stage service binaries before creating and starting a Windows service on remote endpoints. Red Teams and adversaries alike may abuse administrative shares for lateral movement and remote code execution. The IcedID malware family also implements this behavior to try to infect other machines in the infected network.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 5140 EventCode enabled. The Windows TA is also required. Also enable the object Audit access success/failure in your group policy.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1135"], "nist": ["DE.AE"]}
known_false_positives = System Administrators may use looks like net.exe or "dir commandline" for troubleshooting or administrations tasks. However, this will typically come only from certain users and certain systems that can be added to an allow list.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Network Traffic to Active Directory Web Services Protocol - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic identifies network traffic to Active Directory Web Services Protocol. This protocol is used to manage Active Directory. The analytic is meant to be tuned and filtered to the specific environment. It will assist defenders in identifying suspicious processes accessing port 9389.
how_to_implement = The detection is based on data that originates from network traffic logs. The logs must contain the source and destination IP addresses, the application name, and the destination port. The logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the network traffic data source. The logs must also be mapped to the `Network_Traffic` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited as the destination port is specific to Active Directory Web Services Protocol, however we recommend utilizing this analytic to hunt for non-standard processes querying the ADWS port. Filter by App or dest_ip to AD servers and remove known proceses querying ADWS.
providing_technologies = null

[savedsearch://ESCU - Nishang PowershellTCPOneLine - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This query detects the Nishang Invoke-PowerShellTCPOneLine utility that spawns a call back to a remote Command And Control server. This is a powershell oneliner. In addition, this will capture on the command-line additional utilities used by Nishang. Triage the endpoint and identify any parallel processes that look suspicious. Review the reputation of the remote IP or domain contacted by the powershell process.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives may be present. Filter as needed based on initial analysis.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - NLTest Domain Trust Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for the execution of `nltest.exe` with command-line arguments utilized to query for Domain Trust information. Two arguments `/domain trusts`, returns a list of trusted domains, and `/all_trusts`, returns all trusted domains. Red Teams and adversaries alike use NLTest.exe to enumerate the current domain to assist with further understanding where to pivot next.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1482"], "nist": ["DE.CM"]}
known_false_positives = Administrators may use nltest for troubleshooting purposes, otherwise, rarely used.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect an anomaly event of a non-chrome process accessing the files in chrome user default folder. This folder contains all the sqlite database of the chrome browser related to users login, history, cookies and etc. Most of the RAT, trojan spy as well as FIN7 jssloader try to parse the those sqlite database to collect information on the compromised host. This SACL Event (4663) need to be enabled to tthe firefox profile directory to be eable to use this. Since you monitoring this access to the folder,  we observed noise that needs to be filter out and hence added sqlite db browser and explorer .exe to make this detection more stable.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555", "T1555.003"], "nist": ["DE.AE"]}
known_false_positives = other browser not listed related to firefox may catch by this rule.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Non Firefox Process Access Firefox Profile Dir - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect an anomaly event of a non-firefox process accessing the files in the profile folder. This folder contains all the sqlite database of the firefox browser related to users login, history, cookies and etc. Most of the RAT, trojan spy as well as FIN7 jssloader try to parse the those sqlite database to collect information on the compromised host. This SACL Event (4663) needs to be enabled to the firefox profile directory to use this. Since this is monitoring the access to the folder, we have obsevered noise and hence added `sqlite db browser` and `explorer.exe` to make this detection more stable.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555", "T1555.003"], "nist": ["DE.AE"]}
known_false_positives = other browser not listed related to firefox may catch by this rule.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Notepad with no Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies behavior related to default SliverC2 framework where it will inject into Notepad.exe and spawn Notepad.exe with no command line arguments. In testing, this is a common procedure for SliverC2 usage, however may be modified or changed. From Microsoft, "The Sideload, SpawnDll, and Execute-Assembly commands spawn and inject into notepad.exe by default. The following query finds process creation events where the same process creates and injects into notepad.exe within 10 seconds."
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering may need to occur based on organization endpoint behavior.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Ntdsutil Export NTDS - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Monitor for signs that Ntdsutil is being used to Extract Active Directory database - NTDS.dit, typically used for offline password cracking. It may be used in normal circumstances with no command line arguments or shorthand variations of more common arguments. Ntdsutil.exe is typically seen run on a Windows Server. Typical command used to dump ntds.dit \
ntdsutil "ac i ntds" "ifm" "create full C:\Temp" q q \
This technique uses "Install from Media" (IFM), which will extract a copy of the Active Directory database. A successful export of the Active Directory database will yield a file modification named ntds.dit to the destination.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Highly possible Server Administrators will troubleshoot with ntdsutil.exe, generating false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Application Drop Executable - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious MS office application that drops or creates executables or scripts in a Windows Operating System. This behavior is commonly seen in spear phishing office attachment where it drop malicious files or script to compromised the host. It might be some normal macro may drop script or tools as part of automation but still this behavior is reallly suspicious and not commonly seen in normal office application
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = office macro for automation may do this behavior
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Application Spawn Regsvr32 process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this detection was designed to identifies suspicious spawned process of known MS office application due to macro or malicious code. this technique can be seen in so many malware like IcedID that used MS office as its weapon or attack vector to initially infect the machines.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Application Spawn rundll32 process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection was designed to identify suspicious spawned processes of known MS office applications due to macro or malicious code. this technique can be seen in so many malware like trickbot that used MS office as its weapon or attack vector to initially infect the machines.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Document Creating Schedule Task - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search detects a potential malicious office document that create schedule task entry through macro VBA api or through loading taskschd.dll. This technique was seen in so many malicious macro malware that create persistence , beaconing using task schedule malware entry The search will return the first time and last time the task was registered, as well as the `Command` to be executed, `Task Name`, `Author`, `Enabled`, and whether it is `Hidden` or not. schtasks.exe is natively found in `C:\Windows\system32` and `C:\Windows\syswow64`. The following DLL(s) are loaded when schtasks.exe or TaskService is launched -`taskschd.dll`. If found loaded by another process, it's possible a scheduled task is being registered within that process context in memory. Upon triage, identify the task scheduled source. Was it schtasks.exe or via TaskService? Review the job created and the Command to be executed. Capture any artifacts on disk and review. Identify any parallel processes within the same timeframe to identify source.'
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and ImageLoaded (Like sysmon EventCode 7) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Also be sure to include those monitored dll to your own sysmon config.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Office Document Executing Macro Code - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this detection was designed to identifies suspicious office documents that using macro code. Macro code is known to be one of the prevalent weaponization or attack vector of threat actor. This malicious macro code is embed to a office document as an attachment that may execute malicious payload, download malware payload or other malware component. It is really good practice to disable macro by default to avoid automatically execute macro code while opening or closing a office document files.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and ImageLoaded (Like sysmon EventCode 7) from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Also be sure to include those monitored dll to your own sysmon config.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = Normal Office Document macro use for automation
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Office Document Spawned Child Process To Download - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect potential malicious office document executing lolbin child process to download payload or other malware. Since most of the attacker abused the capability of office document to execute living on land application to blend it to the normal noise in the infected machine to cover its track.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = Default browser not in the filter list.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawn CMD Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to detect a suspicious office product process that spawn cmd child process. This is commonly seen in a ms office product having macro to execute shell command to download or execute malicious lolbin relative to its malicious code. This is seen in trickbot spear phishing doc where it execute shell cmd to run mshta payload.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = IT or network admin may create an document automation that will run shell script.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawning BITSAdmin - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, IcedID). This detection identifies any Windows Office Product spawning `bitsadmin.exe`. In malicious instances, the command-line of `bitsadmin.exe` will contain a URL to a remote destination or similar command-line arguments as transfer, Download, priority, Foreground. In addition, Threat Research has released a detections identifying suspicious use of `bitsadmin.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `bitsadmin.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = No false positives known. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawning CertUtil - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, IcedID). This detection identifies any Windows Office Product spawning `certutil.exe`. In malicious instances, the command-line of `certutil.exe` will contain a URL to a remote destination. In addition, Threat Research has released a detections identifying suspicious use of `certutil.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `certutil.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = No false positives known. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawning MSHTA - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, IcedID). This detection identifies any Windows Office Product spawning `mshta.exe`. In malicious instances, the command-line of `mshta.exe` will contain the `hta` file locally, or a URL to the remote destination. In addition, Threat Research has released a detections identifying suspicious use of `mshta.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `mshta.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = No false positives known. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawning Rundll32 with no DLL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the latest behavior utilized by IcedID malware family. This detection identifies any Windows Office Product spawning `rundll32.exe` without a `.dll` file extension. In malicious instances, the command-line of `rundll32.exe` will look like `rundll32 ..\oepddl.igk2,DllRegisterServer`. In addition, Threat Research has released a detection identifying the use of `DllRegisterServer` on the command-line of `rundll32.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze the `DLL` that was dropped to disk. The Office Product will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, but if any are present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawning Windows Script Host - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic will identify a Windows Office Product spawning WScript.exe or CScript.exe. Tuning may be required based on legitimate application usage that may spawn scripts from an Office product.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on macro based approved documents in the organization. Filtering may be needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Spawning Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the latest behavior utilized by Ursnif malware family. This detection identifies any Windows Office Product spawning `wmic.exe`. In malicious instances, the command-line of `wmic.exe` will contain `wmic process call create`. In addition, Threat Research has released a detection identifying the use of `wmic process call create` on the command-line of `wmic.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `wmic.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = No false positives known. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Product Writing cab or inf - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies behavior related to CVE-2021-40444. Whereas the malicious document will load ActiveX and download the remote payload (.inf, .cab). During triage, review parallel processes and further activity on endpoint to identify additional patterns. Retrieve the file modifications and analyze further.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Office Spawning Control - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies control.exe spawning from an office product. This detection identifies any Windows Office Product spawning `control.exe`. In malicious instances, the command-line of `control.exe` will contain a file path to a .cpl or .inf, related to CVE-2021-40444. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. review parallel and child processes to identify further suspicious behavior
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives should be present.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Outbound Network Connection from Java Using Default Ports - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = A required step while exploiting the CVE-2021-44228-Log4j vulnerability is that the victim server will perform outbound connections to attacker-controlled infrastructure. This is required as part of the JNDI lookup as well as for retrieving the second stage .class payload. The following analytic identifies the Java process reaching out to default ports used by the LDAP and RMI protocols. This behavior could represent successfull exploitation. Note that adversaries can easily decide to use arbitrary ports for these protocols and potentially bypass this detection.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = Legitimate Java applications may use perform outbound connections to these ports. Filter as needed
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Overwriting Accessibility Binaries - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Microsoft Windows contains accessibility features that can be launched with a key combination before a user has logged in. An adversary can modify or replace these programs so they can get a command prompt or backdoor without logging in to the system. This search looks for modifications to these binaries.
how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546", "T1546.008"], "nist": ["DE.CM"]}
known_false_positives = Microsoft may provide updates to these binaries. Verify that these changes do not correspond with your normal software update cycle.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - PaperCut NG Suspicious Behavior Debug Log - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following hunting analytic is designed to monitor and detect potential exploitation attempts targeting a PaperCut NG server by analyzing its debug log data. By focusing on public IP addresses accessing the PaperCut NG instance, this analytic aims to identify unauthorized or suspicious access attempts. Furthermore, it searches for specific URIs that have been discovered in the proof of concept code, which are associated with known exploits or vulnerabilities. The analytic is focused on the user admin. Regex is used mainly because the log is not parsed by Splunk and there is no TA for this debug log.
how_to_implement = Debug logs must be enabled and shipped to Splunk in order to properly identify behavior with this analytic.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, as this is based on the admin user accessing the Papercut NG instance from a public IP address. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Password Policy Discovery with Net - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command line arguments used to obtain the domain password policy. Red Teams and adversaries may leverage `net.exe` for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1201"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Permission Modification using Takeown App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a modification of file or directory permission using takeown.exe windows app. This technique was seen in some ransomware that take the ownership of a folder or files to encrypt or delete it.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222"], "nist": ["DE.CM"]}
known_false_positives = takeown.exe is a normal windows application that may used by network operator.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - PetitPotam Network Share Access Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows Event Code 5145, "A network share object was checked to see whether client can be granted desired access". During our research into PetitPotam, CVE-2021-36942, we identified the ocurrence of this event on the target host with specific values. \
To enable 5145 events via Group Policy - Computer Configuration->Polices->Windows Settings->Security Settings->Advanced Audit Policy Configuration. Expand this node, go to Object Access (Audit Polices->Object Access), then select the Setting Audit Detailed File Share Audit \
It is possible this is not enabled by default and may need to be reviewed and enabled. \
During triage, review parallel security events to identify further suspicious activity.
how_to_implement = Windows Event Code 5145 is required to utilize this analytic and it may not be enabled in most environments.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1187"], "nist": ["DE.CM"]}
known_false_positives = False positives have been limited when the Anonymous Logon is used for Account Name.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PetitPotam Suspicious Kerberos TGT Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifes Event Code 4768, A `Kerberos authentication ticket (TGT) was requested`, successfull occurs. This behavior has been identified to assist with detecting PetitPotam, CVE-2021-36942. Once an attacer obtains a computer certificate by abusing Active Directory Certificate Services in combination with PetitPotam, the next step would be to leverage the certificate for malicious purposes. One way of doing this is to request a Kerberos Ticket Granting Ticket using a tool like Rubeus. This request will generate a 4768 event with some unusual fields depending on the environment. This analytic will require tuning, we recommend filtering Account_Name to Domain Controllers for your environment.
how_to_implement = The following analytic requires Event Code 4768. Ensure that it is logging no Domain Controllers and appearing in Splunk.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible if the environment is using certificates for authentication.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Ping Sleep Batch Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify the possible execution of ping sleep batch commands. This technique was seen in several malware samples and is used to trigger sleep times without explicitly calling sleep functions or commandlets. The goal is to delay the execution of malicious code and bypass detection or sandbox analysis. This  detection can be a good indicator of a process delaying its execution for malicious purposes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1497", "T1497.003"], "nist": ["DE.AE"]}
known_false_positives = Administrator or network operator may execute this command. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Possible Browser Pass View Parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will detect if a suspicious process contains a commandline parameter related to a web browser credential dumper. This technique is used by Remcos RAT malware which uses the Nirsoft webbrowserpassview.exe application to dump web browser credentials. Remcos uses the "/stext" command line to dump the credentials in text format. This Hunting query is a good indicator of hosts suffering from possible Remcos RAT infection. Since the hunting query is based on the parameter command and the possible path where it will save the text credential information, it may catch normal tools that are using the same command and behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555.003", "T1555"], "nist": ["DE.AE"]}
known_false_positives = False positive is quite limited. Filter is needed
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Possible Lateral Movement PowerShell Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to identify possible lateral movement attacks that involve the spawning of a PowerShell process as a child or grandchild process of commonly abused processes. These processes include services.exe, wmiprsve.exe, svchost.exe, wsmprovhost.exe, and mmc.exe.\
Such behavior is indicative of legitimate Windows features such as the Service Control Manager, Windows Management Instrumentation, Task Scheduler, Windows Remote Management, and the DCOM protocol being abused to start a process on a remote endpoint. This behavior is often seen during lateral movement techniques where adversaries or red teams abuse these services for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1021", "T1021.003", "T1021.006", "T1047", "T1053.005", "T1543.003", "T1059.001", "T1218.014"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may spawn PowerShell as a child process of the the identified processes. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Potential password in username - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search identifies users who have entered their passwords in username fields. This is done by looking for failed authentication attempts using usernames with a length longer than 7 characters and a high Shannon entropy, and looks for the next successful authentication attempt from the same source system to the same destination system as the failed attempt.
how_to_implement = To successfully implement this search, you need to have relevant authentication logs mapped to the Authentication data model. You also need to have the Splunk TA URL Toolbox (https://splunkbase.splunk.com/app/2734/) installed. The detection must run with a time interval shorter than endtime+1000.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.003", "T1552.001"], "nist": ["DE.AE"]}
known_false_positives = Valid usernames with high entropy or source/destination system pairs with multiple authenticating users will make it difficult to identify the real user authenticating.
providing_technologies = null

[savedsearch://ESCU - Potentially malicious code on commandline - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses a pretrained machine learning text classifier to detect potentially malicious commandlines.  The model identifies unusual combinations of keywords found in samples of commandlines where adversaries executed powershell code, primarily for C2 communication.  For example, adversaries will leverage IO capabilities such as "streamreader" and "webclient", threading capabilties such as "mutex" locks, programmatic constructs like "function" and "catch", and cryptographic operations like "computehash".  Although observing one of these keywords in a commandline script is possible, combinations of keywords observed in attack data are not typically found in normal usage of the commandline.  The model will output a score where all values above zero are suspicious, anything greater than one particularly so.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003"], "nist": ["DE.AE"]}
known_false_positives = This model is an anomaly detector that identifies usage of APIs and scripting constructs that are correllated with malicious activity.  These APIs and scripting constructs are part of the programming langauge and advanced scripts may generate false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - PowerShell 4104 Hunting - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following Hunting analytic assists with identifying suspicious PowerShell execution using Script Block Logging, or EventCode 4104. This analytic is not meant to be ran hourly, but occasionally to identify malicious or suspicious PowerShell. This analytic is a combination of work completed by Alex Teixeira and Splunk Threat Research Team.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.AE"]}
known_false_positives = Limited false positives. May filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell - Connect To Internet With Hidden Window - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies PowerShell commands utilizing the WindowStyle parameter to hide the window on the compromised endpoint. This combination of command-line options is suspicious because it is overriding the default PowerShell execution policy, attempts to hide its activity from the user, and connects to the Internet. Removed in this version of the query is New-Object. The analytic identifies all variations of WindowStyle, as PowerShell allows the ability to shorten the parameter. For example w, win, windowsty and so forth. In addition, through our research it was identified that PowerShell will interpret different command switch types beyond the hyphen. We have added endash, emdash, horizontal bar, and forward slash.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]}
known_false_positives = Legitimate process can have this combination of command-line options, but it's not common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Powershell COM Hijacking InprocServer32 Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell ScriptBlock Logging to identify a script that is attempting to modify or add a component object model to inprocserver32 path within the registry.
how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the PowerShell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.015", "T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present if any scripts are adding to inprocserver32. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Creating Thread Mutex - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is using the `mutex` function. This function is commonly seen in some obfuscated PowerShell scripts to make sure that only one instance of there process is running on a compromise machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1027", "T1027.005", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = powershell developer may used this function in their script for instance checking too.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Disable Security Monitoring - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search identifies a modification in registry to disable the windows defender real time behavior monitoring. This event or technique is commonly seen in RATs, bots, or Trojans to disable AV to evade detections.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives. However, tune based on scripts that may perform this action.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - PowerShell Domain Enumeration - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies specific PowerShell modules typically used to enumerate an organizations domain or users. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = It is possible there will be false positives, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Enable PowerShell Remoting - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic utilizes PowerShell Script Block Logging (EventCode 4104) to identify the use of Enable-PSRemoting cmdlet. This cmdlet allows users to enable PowerShell remoting on a local or remote computer, which allows other computers to run commands on the target computer. The ability to remotely execute commands can be abused by attackers to take control of compromised systems and pivot to other systems on the network. By detecting the use of Enable-PSRemoting cmdlet via script block logging, this analytic can help organizations identify potential malicious activity related to attackers attempting to gain remote control of compromised systems.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]}
known_false_positives = Note that false positives may occur due to the use of the Enable-PSRemoting cmdlet by legitimate users, such as system administrators. It is recommended to apply appropriate filters as needed to minimize the number of false positives.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Enable SMB1Protocol Feature - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious enabling of smb1protocol through `powershell.exe`. This technique was seen in some ransomware (like reddot) where it enable smb share to do the lateral movement and encrypt other files within the compromise network system.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the powershell logs  from your endpoints. make sure you enable needed registry to monitor this event.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027", "T1027.005"], "nist": ["DE.CM"]}
known_false_positives = network operator may enable or disable this windows feature.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Execute COM Object - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a COM CLSID execution through powershell. This technique was seen in several adversaries and malware like ransomware conti where it has a feature to execute command using COM Object. This technique may use by network operator at some cases but a good indicator if some application want to gain privilege escalation or bypass uac.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.015", "T1546", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = network operrator may use this command.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Fileless Process Injection via GetProcAddress - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \
This analytic identifies `GetProcAddress` in the script block. This is not normal to be used by most PowerShell scripts and is typically unsafe/malicious. Many attack toolkits use GetProcAddress to obtain code execution. \
In use, `$var_gpa = $var_unsafe_native_methods.GetMethod(GetProcAddress` and later referenced/executed elsewhere. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1059", "T1055", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies `FromBase64String` within the script block. A typical malicious instance will include additional code. \
Command example - `[Byte[]]$var_code = [System.Convert]::FromBase64String(38uqIyMjQ6rG....` \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1059", "T1027", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Get LocalGroup Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies the use of `get-localgroup` being used with PowerShell to identify local groups on the endpoint. During triage, review parallel processes and identify any further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Powershell Get LocalGroup Discovery with Script Block Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies PowerShell cmdlet - `get-localgroup` being ran. Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Tune as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Invoke CIMMethod CIMSession - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the use of the New-CIMSession cmdlet being created along with the Invoke-CIMMethod cmdlet being used within PowerShell. This particular behavior is similar to the usage of the Invoke-WMIMethod cmdlet, which is known for executing WMI commands on targets using NTLMv2 pass-the-hash authentication. The New-CIMSession cmdlet allows users to create a new CIM session object for a specified computer system, which can then be used to execute CIM operations remotely. Similarly, the Invoke-CIMMethod cmdlet is used to invoke a specified method on one or more CIM objects. Therefore, the combination of New-CIMSession and Invoke-CIMMethod cmdlets in PowerShell can potentially indicate malicious behavior, and this analytic can help detect such activity.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present based on third-party applications or administrators using CIM. It is recommended to apply appropriate filters as needed to minimize the number of false positives.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Invoke WmiExec Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the usage of the Invoke-WMIExec utility within PowerShell Script Block Logging (EventCode 4104). The utility is used for executing WMI commands on targets using NTLMv2 pass-the-hash authentication.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this analytic is designed to detect a specific utility. It is recommended to apply appropriate filters as needed to minimize the number of false positives.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Load Module in Meterpreter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies "MSF.Powershell","MSF.Powershell.Meterpreter","MSF.Powershell.Meterpreter.Kiwi","MSF.Powershell.Meterpreter.Transport" being used. This behavior is related to when a Meterpreter session is started and the operator runs load_kiwi. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be very limited as this is strict to MetaSploit behavior.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable no critical endpoints or all. \
This analytic identifies the use of PowerShell loading .net assembly via reflection. This is commonly found in malicious PowerShell usage, including Empire and Cobalt Strike. In addition, the `load(` value may be modifed by removing `(` and it will identify more events to review. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as day to day scripts do not use this method.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Processing Stream Of Data - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is processing compressed stream data. This is typically found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files that are stream flattened and will be deflated durnig execution. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = powershell may used this function to process compressed data.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Remote Services Add TrustedHost - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious PowerShell script execution via EventCode 4104 that contains command to add or modify the trustedhost configuration in Windows OS. This behavior raises concerns due to the nature of modifications made to the 'TrustedHost' configuration, which typically involves adjusting settings crucial for remote connections and security protocols. Alterations in this area could potentially indicate attempts to manipulate trusted hosts or systems for unauthorized remote access, a tactic commonly observed in various unauthorized access or compromise attempts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.006", "T1021"], "nist": ["DE.CM"]}
known_false_positives = user and network administrator may used this function to add trusted host.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Remote Thread To Known Windows Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is designed to detect suspicious powershell process that tries to inject code and to known/critical windows process and execute it using CreateRemoteThread. This technique is seen in several malware like trickbot and offensive tooling like cobaltstrike where it load a shellcode to svchost.exe to execute reverse shell to c2 and download another payload
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, Create Remote thread from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of create remote thread may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Powershell Remove Windows Defender Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify a suspicious PowerShell command used to delete the Windows Defender folder. This technique was seen used by the WhisperGate malware campaign where it used Nirsofts advancedrun.exe to gain administrative privileges to then execute a PowerShell command to delete the Windows Defender folder. This is a good indicator the offending process is trying corrupt a Windows Defender installation.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Script Block With URL Chain - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious PowerShell script execution via EventCode 4104 that contains multiple URLs within a function or array. This is typically found in obfuscated PowerShell or PowerShell executing embedded .NET or binary files that are attempting to download 2nd stage payloads. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Command and Control"], "mitre_attack": ["T1059.001", "T1105"], "nist": ["DE.CM"]}
known_false_positives = Unknown, possible custom scripting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell Start-BitsTransfer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Start-BitsTransfer is the PowerShell "version" of BitsAdmin.exe. Similar functionality is present. This technique variation is not as commonly used by adversaries, but has been abused in the past. Lesser known uses include the ability to set the `-TransferType` to `Upload` for exfiltration of files. In an instance where `Upload` is used, it is highly possible files will be archived. During triage, review parallel processes and process lineage. Capture any files on disk and review. For the remote domain or IP, what is the reputation?
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1197"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives. It is possible administrators will utilize Start-BitsTransfer for administrative tasks, otherwise filter based parent process or command-line arguments.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - PowerShell Start or Stop Service - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the use of PowerShell's Start-Service or Stop-Service cmdlets on an endpoint. These cmdlets allow users to start or stop a specified Windows service. The ability to manipulate services can be leveraged by attackers to disable or stop critical services, which can cause system instability or disrupt business operations. By detecting the use of Start-Service or Stop-Service cmdlets via PowerShell, this analytic can help organizations identify potential malicious activity related to attackers attempting to manipulate services on compromised systems. However, note that this behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, it is recommended not to enable this analytic as a direct notable or TTP. Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001"], "nist": ["DE.AE"]}
known_false_positives = This behavior may be noisy, as these cmdlets are commonly used by system administrators or other legitimate users to manage services. Therefore, it is recommended not to enable this analytic as a direct notable or TTP. Instead, it should be used as part of a broader set of security controls to detect and investigate potential threats.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Using memory As Backing Store - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is using memory stream as new object backstore. The malicious PowerShell script will contain stream flate data and will be decompressed in memory to run or drop the actual payload. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.CM"]}
known_false_positives = powershell may used this function to store out object into memory.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - PowerShell WebRequest Using Memory Stream - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a common fileless malware staging technique of using .NET classes to directly download a URL payload into memory. The analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution.
how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Command and Control", "Exploitation"], "mitre_attack": ["T1059.001", "T1105", "T1027.011"], "nist": ["DE.CM"]}
known_false_positives = Unknown, possible custom scripting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Powershell Windows Defender Exclusion Commands - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will detect a suspicious process commandline related to windows defender exclusion feature. This command is abused by adversaries, malware author and red teams to bypassed Windows Defender Anti-Virus product by excluding  folder path, file path, process, extensions and etc. from its real time or schedule scan to execute their malicious code. This is a good indicator for defense evasion and to look further for events after this behavior.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to use this windows features.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Prevent Automatic Repair Mode using Bcdedit - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious bcdedit.exe execution to ignore all failures. This technique was used by ransomware to prevent the compromise machine automatically boot in repair mode.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = Administrators may modify the boot configuration ignore failure during testing and debugging.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Print Processor Registry Autostart - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious modification or new registry entry regarding print processor. This registry is known to be abuse by turla or other APT to gain persistence and privilege escalation to the compromised machine. This is done by adding the malicious dll payload on the new created key in this registry that will be executed as it restarted the spoolsv.exe process and services.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = possible new printer installation may add driver component on this registry.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Print Spooler Adding A Printer Driver - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies new printer drivers being load by utilizing the Windows PrintService operational logs, EventCode 316. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. \
Within the proof of concept code, the following event will occur - "Printer driver 1234 for Windows x64 Version-3 was added or updated. Files:- UNIDRV.DLL, kernelbase.dll, evil.dll. No user action is required." \
During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events and review the source of where the exploitation began.
how_to_implement = You will need to ensure PrintService Admin and Operational logs are being logged to Splunk from critical or all systems.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = Unknown. This may require filtering.
providing_technologies = null

[savedsearch://ESCU - Print Spooler Failed to Load a Plug-in - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies driver load errors utilizing the Windows PrintService Admin logs. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. \
Within the proof of concept code, the following error will occur - "The print spooler failed to load a plug-in module C:\Windows\system32\spool\DRIVERS\x64\3\meterpreter.dll, error code 0x45A. See the event user data for context information." \
The analytic is based on file path and failure to load the plug-in. \
During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events.
how_to_implement = You will need to ensure PrintService Admin and Operational logs are being logged to Splunk from critical or all systems.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = False positives are unknown and filtering may be required.
providing_technologies = null

[savedsearch://ESCU - Process Creating LNK file in Suspicious Location - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for a process launching an `*.lnk` file under `C:\User*` or `*\Local\Temp\*`. This is common behavior used by various spear phishing tools.
how_to_implement = You must be ingesting data that records filesystem and process activity from your hosts to populate the Endpoint data model. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or endpoint data sources, such as Sysmon.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.002"], "nist": ["DE.CM"]}
known_false_positives = This detection should yield little or no false positive results. It is uncommon for LNK files to be executed from temporary or user directories.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Process Deleting Its Process File Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection is to identify a suspicious process that tries to delete the process file path related to its process. This technique is known to be defense evasion once a certain condition of malware is satisfied or not. Clop ransomware use this technique where it will try to delete its process file path using a .bat command if the keyboard layout is not the layout it tries to infect.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Process Execution via WMI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `WmiPrvSE.exe` spawning a process. This typically occurs when a process is instantiated from a local or remote process using `wmic.exe`. During triage, review parallel processes for suspicious behavior or commands executed. Review the process and command-line spawning from `wmiprvse.exe`. Contain and remediate the endpoint as necessary.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, administrators may use wmi to execute commands for legitimate purposes.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Process Kill Base On File Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of `wmic.exe` using `delete` to remove a executable path. This is typically ran via a batch file during beginning stages of an adversary setting up for mining on an endpoint.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Unknown.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Process Writing DynamicWrapperX - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = DynamicWrapperX is an ActiveX component that can be used in a script to call Windows API functions, but it requires the dynwrapx.dll to be installed and registered. With that, a binary writing dynwrapx.dll to disk and registering it into the registry is highly suspect. Why is it needed? In most malicious instances, it will be written to disk at a non-standard location. During triage, review parallel processes and pivot on the process_guid. Review the registry for any suspicious modifications meant to load dynwrapx.dll. Identify any suspicious module loads of dynwrapx.dll. This will identify the process that will invoke vbs/wscript/cscript.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1559.001"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited, however it is possible to filter by Processes.process_name and specific processes (ex. wscript.exe). Filter as needed. This may need modification based on EDR telemetry and how it brings in registry data. For example, removal of (Default).
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Processes launching netsh - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes launching netsh.exe. Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper DLL when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe and executing commands via the command line.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.AE"]}
known_false_positives = Some VPN applications are known to launch netsh.exe. Outside of these instances, it is unusual for an executable to launch netsh.exe and run commands.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Processes Tapping Keyboard Events - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes in an MacOS system that is tapping keyboard events in MacOS, and essentially monitoring all keystrokes made by a user. This is a common technique used by RATs to log keystrokes from a victim, although it can also be used by legitimate processes like Siri to react on human input
how_to_implement = In order to properly run this search, Splunk needs to ingest data from your osquery deployed agents with the [osx-attacks.conf](https://github.com/facebook/osquery/blob/experimental/packs/osx-attacks.conf#L599) pack enabled. Also the [TA-OSquery](https://github.com/d1vious/TA-osquery) must be deployed across your indexers and universal forwarders in order to have the osquery data populate the Alerts data model.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = There might be some false positives as keyboard event taps are used by processes like Siri and Zoom video chat, for some good examples of processes to exclude please see [this](https://github.com/facebook/osquery/pull/5345#issuecomment-454639161) comment.
providing_technologies = null

[savedsearch://ESCU - Randomly Generated Scheduled Task Name - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic leverages Event ID 4698, `A scheduled task was created`, to identify the creation of a Scheduled Task with a suspicious, high entropy, Task Name. To achieve this, this analytic also leverages the `ut_shannon` function from the URL ToolBox Splunk application. Red teams and adversaries alike may abuse the Task Scheduler to create and start a remote Scheduled Task and obtain remote code execution. To achieve this goal, tools like Impacket or Crapmapexec, typically create a Scheduled Task with a random task name on the victim host. This hunting analytic may help defenders identify Scheduled Tasks created as part of a lateral movement attack. The entropy threshold `ut_shannon > 3` should be customized by users. The Command field can be used to determine if the task has malicious intent or not.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA as well as the URL ToolBox application are also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.AE"]}
known_false_positives = Legitimate applications may use random Scheduled Task names.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Randomly Generated Windows Service Name - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic leverages Event ID 7045, `A new service was installed in the system`, to identify the installation of a Windows Service with a suspicious, high entropy, Service Name. To achieve this, this analytic also leverages the `ut_shannon` function from the URL ToolBox Splunk application. Red teams and adversaries alike may abuse the Service Control Manager to create and start a remote Windows Service and obtain remote code execution. To achieve this goal, some tools like Metasploit, Cobalt Strike and Impacket, typically create a Windows Service with a random service name on the victim host. This hunting analytic may help defenders identify Windows Services installed as part of a lateral movement attack. The entropy threshold `ut_shannon > 3` should be customized by users. The Service_File_Name field can be used to determine if the Windows Service has malicious intent or not.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints. The Windows TA as well as the URL ToolBox application are also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.AE"]}
known_false_positives = Legitimate applications may use random Windows Service names.
providing_technologies = null

[savedsearch://ESCU - Ransomware Notes bulk creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytics identifies a big number of instance of ransomware notes (filetype e.g .txt, .html, .hta) file creation to the infected machine. This behavior is a good sensor if the ransomware note filename is quite new for security industry or the ransomware note filename is not in your ransomware lookup table list for monitoring.
how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Recon AVProduct Through Pwh or WMI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 performing checks to identify anti-virus products installed on the endpoint. This technique is commonly found in malware and APT events where the adversary will map all running security applications or services. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592"], "nist": ["DE.CM"]}
known_false_positives = network administrator may used this command for checking purposes
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Recon Using WMI Class - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell via EventCode 4104, where WMI is performing an event query looking for running processes or running services. This technique is commonly found where the adversary will identify services and system information on the compromised machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance", "Installation"], "mitre_attack": ["T1592", "T1059.001"], "nist": ["DE.AE"]}
known_false_positives = network administrator may used this command for checking purposes
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Recursive Delete of Directory In Batch CMD - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious commandline designed to delete files or directory recursive using batch command. This technique was seen in ransomware (reddot) where it it tries to delete the files in recycle bin to impaire user from recovering deleted files.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070.004", "T1070"], "nist": ["DE.CM"]}
known_false_positives = network operator may use this batch command to delete recursively a directory or files within directory
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Reg exe Manipulating Windows Services Registry Keys - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for reg.exe modifying registry keys that define Windows services and their configurations.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.011", "T1574"], "nist": ["DE.CM"]}
known_false_positives = It is unusual for a service to be created or modified by directly manipulating the registry. However, there may be legitimate instances of this behavior. It is important to validate and investigate, as appropriate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Registry Keys for Creating SHIM Databases - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for registry activity associated with application compatibility shims, which can be leveraged by attackers for various nefarious purposes.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.011", "T1546"], "nist": ["DE.CM"]}
known_false_positives = There are many legitimate applications that leverage shim databases for compatibility purposes for legacy applications
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Registry Keys Used For Persistence - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for modifications or alterations made to registry keys that have the potential to initiate the launch of an application or service during system startup. By monitoring and detecting modifications in these registry keys, we can identify suspicious or unauthorized changes that could be indicative of malicious activity. This proactive approach helps in safeguarding the system's integrity and security by promptly identifying and mitigating potential threats that aim to gain persistence or execute malicious actions during the startup process.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.001", "T1547"], "nist": ["DE.CM"]}
known_false_positives = There are many legitimate applications that must execute on system startup and will use these registry keys to accomplish that task.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Registry Keys Used For Privilege Escalation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for modifications to registry keys that can be used to elevate privileges. The registry keys under "Image File Execution Options" are used to intercept calls to an executable and can be used to attach malicious binaries to benign system binaries.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.012", "T1546"], "nist": ["DE.CM"]}
known_false_positives = There are many legitimate applications that must execute upon system startup and will use these registry keys to accomplish that task.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a loading of dll using regsvr32 application with silent parameter and dllinstall execution. This technique was seen in several RAT malware similar to remcos, njrat and adversaries to load their malicious DLL on the compromised machine. This TTP may executed by normal 3rd party application so it is better to pivot by the parent process, parent command-line and command-line of the file that execute this regsvr32.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.AE"]}
known_false_positives = Other third part application may used this parameter but not so common in base windows environment.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies Regsvr32.exe utilizing the silent switch to load DLLs. This technique has most recently been seen in IcedID campaigns to load its initial dll that will download the 2nd stage loader that will download and decrypt the config payload. The switch type may be either a hyphen `-` or forward slash `/`. This behavior is typically found with `-s`, and it is possible there are more switch types that may be used. \ During triage, review parallel processes and capture any artifacts that may have landed on disk. Isolate and contain the endpoint as necessary.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.AE"]}
known_false_positives = minimal. but network operator can use this application to load dll.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remcos client registry install entry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the presence of a registry key related to the Remcos RAT agent on a host. This detection is made by a Splunk query to search for instances where the registry key "license" is found in the "Software\Remcos" path. This analytic combines information from two data models: Endpoint.Processes and Endpoint.Registry and retrieves process information such as user, process ID, process name, process path, destination, parent process name, parent process, and process GUID. This analytic also retrieves registry information such as registry path, registry key name, registry value name, registry value data, and process GUID. By joining the process GUID from the Endpoint.Processes data model with the process GUID from the Endpoint.Registry data model, the analytic identifies instances where the "license" registry key is found in the "Software\Remcos" path. This detection is important because it suggests that the host has been compromised by the Remcos RAT agent. Remcos is a well-known remote access Trojan that can be used by attackers to gain unauthorized access to systems and exfiltrate sensitive data. Identifying this behavior allows the SOC to take immediate action to remove the RAT agent and prevent further compromise. The impact of this attack can be severe, as the attacker can gain unauthorized access to the system, steal sensitive information, or use the compromised system as a launching point for further attacks. Next steps include using this analytic in conjunction with other security measures and threat intelligence to ensure accurate detection and response.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remcos RAT File Creation in Remcos Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect file creation in remcos folder in appdata which is the keylog and clipboard logs that will be send to its c2 server. This is really a good TTP indicator that there is a remcos rat in the system that do keylogging, clipboard grabbing and audio recording.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Desktop Process Running On System - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for the remote desktop process mstsc.exe running on systems upon which it doesn't typically run. This is accomplished by filtering out all systems that are noted in the `common_rdp_source category` in the Assets and Identity framework.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]}
known_false_positives = Remote Desktop may be used legitimately by users on the network.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Process Instantiation via DCOM and PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with arguments utilized to start a process on a remote endpoint by abusing the DCOM protocol. Specifically, this search looks for the abuse of ShellExecute and ExecuteShellCommand. Red Teams and adversaries alike may abuse DCOM and `powershell.exe` for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage DCOM to start a process on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Process Instantiation via DCOM and PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of PowerShell with arguments utilized to start a process on a remote endpoint by abusing the DCOM protocol. Specifically, this search looks for the abuse of ShellExecute and ExecuteShellCommand. Red Teams and adversaries alike may abuse DCOM for lateral movement and remote code execution.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage DCOM to start a process on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Remote Process Instantiation via WinRM and PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with arguments utilized to start a process on a remote endpoint by abusing the WinRM protocol. Specifically, this search looks for the abuse of the `Invoke-Command` commandlet. Red Teams and adversaries alike may abuse WinRM and `powershell.exe` for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage WinRM and `Invoke-Command` to start a process on remote systems for system administration or automation use cases. However, this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Process Instantiation via WinRM and PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of PowerShell with arguments utilized to start a process on a remote endpoint by abusing the WinRM protocol. Specifically, this search looks for the abuse of the `Invoke-Command` commandlet. Red Teams and adversaries alike may abuse WinRM for lateral movement and remote code execution.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage WinRM and `Invoke-Command` to start a process on remote systems for system administration or automation use cases. This activity is usually limited to a small set of hosts or users. In certain environments, tuning may not be possible.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Remote Process Instantiation via WinRM and Winrs - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `winrs.exe` with command-line arguments utilized to start a process on a remote endpoint. Red Teams and adversaries alike may abuse the WinRM protocol and this binary for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage WinRM and WinRs to start a process on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Process Instantiation via WMI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies wmic.exe being launched with parameters to spawn a process on a remote system. Red Teams and adversaries alike may abuse WMI and this binary for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = The wmic.exe utility is a benign Windows application. It may be used legitimately by Administrators with these parameters for remote system administration, but it's relatively uncommon.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Process Instantiation via WMI and PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` leveraging the `Invoke-WmiMethod` commandlet complemented with arguments utilized to start a process on a remote endpoint by abusing WMI. Red Teams and adversaries alike may abuse WMI and `powershell.exe` for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage WWMI and powershell.exe to start a process on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote Process Instantiation via WMI and PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Invoke-WmiMethod` commandlet with arguments utilized to start a process on a remote endpoint by abusing WMI. Red Teams and adversaries alike may abuse WMI and this commandlet for lateral movement and remote code execution.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup instructions can be found https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage WWMI and powershell.exe to start a process on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Remote System Discovery with Adsisearcher - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain computers. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain computers for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use Adsisearcher for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Remote System Discovery with Dsquery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `dsquery.exe` with command-line arguments utilized to discover remote systems. The `computer` argument returns a list of all computers registered in the domain. Red Teams and adversaries alike engage in remote system discovery for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote System Discovery with Net - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `net.exe` or `net1.exe` with command-line arguments utilized to discover remote systems. The argument `domain computers /domain` returns a list of all domain computers. Red Teams and adversaries alike use net.exe to identify remote systems for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote System Discovery with Wmic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `wmic.exe` with command-line arguments utilized to discover remote systems. The arguments utilized in this command return a list of all the systems registered in the domain. Red Teams and adversaries alike may leverage WMI and wmic.exe to identify remote systems for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Remote WMI Command Attempt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies usage of `wmic.exe` spawning a local or remote process, identified by the `node` switch. During triage, review parallel processes for additional commands executed. Look for any file modifications before and after `wmic.exe` execution. In addition, identify the remote endpoint and confirm execution or file modifications. Contain and isolate the endpoint as needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Administrators may use this legitimately to gather info from remote systems. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Resize ShadowStorage volume - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytics identifies the resizing of shadowstorage by ransomware malware to avoid the shadow volumes being made again. this technique is an alternative by ransomware attacker than deleting the shadowstorage which is known alert in defensive team. one example of ransomware that use this technique is CLOP ransomware where it drops a .bat file that will resize the shadowstorage to minimum size as much as possible
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = network admin can resize the shadowstorage for valid purposes.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Revil Common Exec Parameter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious commandline parameter that are commonly used by REVIL ransomware to encrypts the compromise machine.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204"], "nist": ["DE.CM"]}
known_false_positives = third party tool may have same command line parameters as revil ransomware.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Revil Registry Entry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious modification in registry entry to keep some malware data during its infection. This technique seen in several apt implant, malware and ransomware like REVIL where it keep some information like the random generated file extension it uses for all the encrypted files and ransomware notes file name in the compromised host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rubeus Command Line Parameters - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Rubeus is a C# toolset for raw Kerberos interaction and abuses. It is heavily adapted from Benjamin Delpys Kekeo project and Vincent LE TOUXs MakeMeEnterpriseAdmin project. This analytic looks for the use of Rubeus command line arguments utilized in common Kerberos attacks like exporting and importing tickets, forging silver and golden tickets, requesting a TGT or TGS, kerberoasting, password spraying, etc. Red teams and adversaries alike use Rubeus for Kerberos attacks within Active Directory networks. Defenders should be aware that adversaries may customize the source code of Rubeus and modify the command line parameters. This would effectively bypass this analytic.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.003", "T1558", "T1558.003", "T1558.004"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, legitimate applications may use the same command line parameters as Rubeus. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rubeus Kerberos Ticket Exports Through Winlogon Access - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic looks for a process accessing the winlogon.exe system process. The Splunk Threat Research team identified this behavior when using the Rubeus tool to monitor for and export kerberos tickets from memory. Before being able to export tickets. Rubeus will try to escalate privileges to SYSTEM by obtaining a handle to winlogon.exe before trying to monitor for kerberos tickets. Exporting tickets from memory is typically the first step for pass the ticket attacks. Red teams and adversaries alike may use the pass the ticket technique using stolen Kerberos tickets to move laterally within an environment, bypassing normal system access controls. Defenders should be aware that adversaries may customize the source code of Rubeus to potentially bypass this analytic.
how_to_implement = This search needs Sysmon Logs and a sysmon configuration, which includes EventCode 10. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550", "T1550.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may obtain a handle for winlogon.exe. Filter as needed
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Runas Execution in CommandLine - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic look for a spawned runas.exe process with a administrator user option parameter. This parameter was abused by adversaries, malware author or even red teams to gain elevated privileges in target host. This is a good hunting query to figure out privilege escalation tactics that may used for different stages like lateral movement but take note that administrator may use this command in purpose so its better to see other event context before and after this analytic.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134", "T1134.001"], "nist": ["DE.AE"]}
known_false_positives = A network operator or systems administrator may utilize an automated or manual execute this command that may generate false positives. filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rundll32 Control RunDLL Hunt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting detection identifies rundll32.exe with `control_rundll` within the command-line, loading a .cpl or another file type. Developed in relation to CVE-2021-40444. Rundll32.exe can also be used to execute Control Panel Item files (.cpl) through the undocumented shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. Double-clicking a .cpl file also causes rundll32.exe to execute. \ This is written to be a bit more broad by not including .cpl. \ During triage, review parallel processes to identify any further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.AE"]}
known_false_positives = This is a hunting detection, meant to provide a understanding of how voluminous control_rundll is within the environment.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rundll32 Control RunDLL World Writable Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies rundll32.exe with `control_rundll` within the command-line, loading a .cpl or another file type from windows\temp, programdata, or appdata. Developed in relation to CVE-2021-40444. Rundll32.exe can also be used to execute Control Panel Item files (.cpl) through the undocumented shell32.dll functions Control_RunDLL and Control_RunDLLAsUser. Double-clicking a .cpl file also causes rundll32.exe to execute. This is written to be a bit more broad by not including .cpl. The paths are specified, add more as needed. During triage, review parallel processes to identify any further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = This may be tuned, or a new one related, by adding .cpl to command-line. However, it's important to look for both. Tune/filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rundll32 Create Remote Thread To A Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the suspicious Remote Thread execution of rundll32.exe to any process. This technique was seen in IcedID malware to execute its malicious code in normal process for defense evasion and to steal sensitive information in the compromised host.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the SourceImage, TargetImage, and EventCode executions from your endpoints related to create remote thread or injecting codes. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Rundll32 CreateRemoteThread In Browser - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the suspicious Remote Thread execution of rundll32.exe process to "firefox.exe" and "chrome.exe" browser. This technique was seen in IcedID malware where it hooks the browser to parse banking information as user used the targetted browser process.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the SourceImage, TargetImage, and EventCode executions from your endpoints related to create remote thread or injecting codes. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Rundll32 DNSQuery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious rundll32.exe process having a http connection and do a dns query in some web domain. This technique was seen in IcedID malware where the rundll32 that execute its payload will contact amazon.com to check internet connect and to communicate to its C&C server to download config and other file component.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and eventcode = 22 dnsquery executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Rundll32 LockWorkStation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious rundll32 commandline to lock the workstation through command line. This technique was seen in CONTI leak tooling and script as part of its defense evasion. This technique is not a common practice to lock a screen and maybe a good indicator of compromise.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rundll32 Process Creating Exe Dll Files - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious rundll32 process that drops executable (.exe or .dll) files. This behavior seen in rundll32 process of IcedID that tries to drop copy of itself in temp folder or download executable drop it either appdata or programdata as part of its execution.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, TargetFilename, and eventcode 11 executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Rundll32 Shimcache Flush - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious rundll32 commandline to clear shim cache. This technique is a anti-forensic technique to clear the cache taht are one important artifacts in terms of digital forensic during attacks or incident. This TTP is a good indicator that someone tries to evade some tools and clear foothold on the machine.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Rundll32 with no Command Line Arguments with Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe with no command line arguments and performing a network connection. It is unusual for rundll32.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, triage any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may use a moved copy of rundll32, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - RunDLL Loading DLL By Ordinal - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe loading an export function by ordinal value. Adversaries may abuse rundll32.exe to proxy execution of malicious code. Using rundll32.exe, vice executing directly, may avoid triggering security tools that may not monitor execution of the rundll32.exe process because of allowlists or false positives from normal operations. Utilizing ordinal values makes it a bit more complicated for analysts to understand the behavior until the DLL is reviewed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible with native utilities and third party applications. Filtering may be needed based on command-line, or add world writeable paths to restrict query.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Ryuk Test Files Detected - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for files that contain the key word *Ryuk* under any folder in the C drive, which is consistent with Ryuk propagation.
how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint Filesystem data-model object. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.CM"]}
known_false_positives = If there are files with this keywoord as file names it might trigger false possitives, please make use of our filters to tune out potential FPs.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Ryuk Wake on LAN Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This Splunk query identifies the use of Wake-on-LAN utilized by Ryuk ransomware. The Ryuk Ransomware uses the Wake-on-Lan feature to turn on powered off devices on a compromised network to have greater success encrypting them. This is a high fidelity indicator of Ryuk ransomware executing on an endpoint. Upon triage, isolate the endpoint. Additional file modification events will be within the users profile (\appdata\roaming) and in public directories (users\public\). Review all Scheduled Tasks on the isolated endpoint and across the fleet. Suspicious Scheduled Tasks will include a path to a unknown binary and those endpoints should be isolated until triaged.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.003"], "nist": ["DE.CM"]}
known_false_positives = Limited to no known false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - SAM Database File Access Attempt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies access to SAM, SYSTEM or SECURITY databases' within the file path of `windows\system32\config` using Windows Security EventCode 4663. This particular behavior is related to credential access, an attempt to either use a Shadow Copy or recent CVE-2021-36934 to access the SAM database. The Security Account Manager (SAM) is a database file in Windows XP, Windows Vista, Windows 7, 8.1 and 10 that stores users' passwords.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002", "T1003"], "nist": ["DE.AE"]}
known_false_positives = Natively, `dllhost.exe` will access the files. Every environment will have additional native processes that do as well. Filter by process_name. As an aside, one can remove process_name entirely and add `Object_Name=*ShadowCopy*`.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Samsam Test File Write - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for a file named "test.txt" written to the windows system directory tree, which is consistent with Samsam propagation.
how_to_implement = You must be ingesting data that records the file-system activity from your hosts to populate the Endpoint file-system data-model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.CM"]}
known_false_positives = No false positives have been identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Sc exe Manipulating Windows Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for arguments to sc.exe indicating the creation or modification of a Windows service.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003", "T1543"], "nist": ["DE.CM"]}
known_false_positives = Using sc.exe to manipulate Windows services is uncommon. However, there may be legitimate instances of this behavior. It is important to validate and investigate as appropriate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - SchCache Change By App Connect And Create ADSI Object - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect an application try to connect and create ADSI Object to do LDAP query. Every time an application connects to the directory and attempts to create an ADSI object, the Active Directory Schema is checked for changes. If it has changed since the last connection, the schema is downloaded and stored in a cache on the local computer either in %LOCALAPPDATA%\Microsoft\Windows\SchCache or %systemroot%\SchCache. We found this a good anomaly use case to detect suspicious application like blackmatter ransomware that use ADS object api to execute ldap query. having a good list of ldap or normal AD query tool used within the network is a good start to reduce the noise.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]}
known_false_positives = normal application like mmc.exe and other ldap query tool may trigger this detections.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Schedule Task with HTTP Command Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the registration of suspicious tasks on Windows using the Windows Security EventCode 4698, "A scheduled task was created." It specifically looks for tasks registered through schtasks.exe or TaskService that have command arguments containing the string "HTTP." This behavior is often associated with malware or attacks that utilize Living off the Land binaries (lolbins) to download additional files or payloads to the compromised machine.\
The search returns information about the task, such as the task name, command, author, enabled status, hidden status, and arguments. Upon triage, it is important to identify the source of the scheduled task, whether it was registered through schtasks.exe or TaskService. Review the details of the created task and the command to be executed. Capture relevant artifacts on disk and examine them. Additionally, identify any parallel processes occurring within the same timeframe to determine the source of the attack.\
Implementing this analytic requires ingesting logs with information about task schedules, specifically Windows Security Log EventCode 4698, from your endpoints. It is recommended to tune and filter known instances of task schedules used in your environment to minimize false positives.\
Detecting the registration of suspicious tasks with HTTP command arguments is valuable for a SOC as it indicates potential malicious activity or an attempt to establish persistence on the system. If a true positive is found, further investigation is warranted to analyze the nature and purpose of the scheduled task, identify any downloaded files or payloads, and mitigate the associated risks. The impact of a true positive can vary but may include data exfiltration, malware propagation, or unauthorized access to sensitive information.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the task schedule (Exa. Security Log EventCode 4698) endpoints. Tune and filter known instances of Task schedule used in your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Schedule Task with Rundll32 Command Trigger - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of suspicious tasks in Windows, specifically tasks using the rundll32 command. It's implemented using Windows Security EventCode 4698 for A scheduled task was created, and looks for tasks executed either via schtasks.exe or TaskService. This behavior is worth identifying as it is commonly used by malware, such as TrickBot, that leverages rundll32 to execute its downloader.\
If a true positive is found, it suggests an attacker is trying to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes.\
To implement this analytic, ensure you are ingesting logs with task schedule information from your endpoints. Be aware of potential false positives - legitimate uses of Task Scheduler in your environment may cause benign activities to be flagged.\
Upon triage, review the scheduled task's source and the command to be executed. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the task schedule (Exa. Security Log EventCode 4698) endpoints. Tune and filter known instances of Task schedule used in your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Scheduled Task Creation on Remote Endpoint using At - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of suspicious tasks on a remote Windows endpoint using the at.exe command with command-line arguments. This technique is commonly used by red teams and adversaries for lateral movement and remote code execution. The at.exe binary leverages the deprecated AT protocol, which may still work on previous versions of Windows. Attackers can enable this protocol on demand by modifying a system registry key. It is important to consider potential false positives. While administrators may create scheduled tasks on remote systems, this activity is typically limited to a small set of hosts or users.\
Identifying the creation of scheduled tasks on remote endpoints is crucial for a Security Operations Center (SOC) because it indicates potential unauthorized activity or an attacker attempting to establish persistence or execute malicious code. The impact of a true positive can be significant, leading to unauthorized access, data theft, or other damaging outcomes. During triage, investigate the source and purpose of the scheduled task, inspect relevant on-disk artifacts, and analyze concurrent processes to identify the extent of the attack and take appropriate response actions.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053", "T1053.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators may create scheduled tasks on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Scheduled Task Deleted Or Created via CMD - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic focuses on identifying the creation or deletion of scheduled tasks using the schtasks.exe utility with the corresponding command-line flags (-create or -delete). This technique has been notably associated with threat actors like Dragonfly and the SUNBURST attack against SolarWinds. The purpose of this analytic is to detect suspicious activity related to scheduled tasks that could indicate malicious intent or unauthorized system manipulation. By monitoring for these specific command-line flags, we can enhance our ability to identify potential threats and prevent attacks similar to the use of scheduled tasks in the BadRabbit Ransomware incident.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = While it is possible for legitimate scripts or administrators to trigger this behavior, filtering can be applied based on the parent process and application to reduce false positives. Analysts should reference the provided references to understand the context and threat landscape associated with this activity.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Scheduled Task Initiation on Remote Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects instances of 'schtasks.exe' being used to start a Scheduled Task on a remote endpoint. Adversaries often abuse the Task Scheduler for lateral movement and remote code execution. The search parameters include process details such as the process  name, parent process, and command-line executions. Although legitimate administrators may start scheduled tasks on remote systems, this activity is usually limited to a small set of hosts or users. The findings from this analytic provide valuable insight into potentially malicious activities on an endpoint.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.CM"]}
known_false_positives = Administrators may start scheduled tasks on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Schtasks Run Task On Demand - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect when a Windows Scheduled Task is executed on demand via shell or command line. Adversaries often force the execution of their created Scheduled Tasks for persistent access or lateral movement within a compromised machine. This analytic is driven by process-related data, specifically process name, parent process, and command-line executions, sourced from endpoint logs. The search criteria focus on 'schtasks.exe' with an associated 'run' command.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]}
known_false_positives = Bear in mind, administrators debugging Scheduled Task entries may trigger this analytic, necessitating fine-tuning and filtering to distinguish between legitimate and potentially malicious use of 'schtasks.exe'.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Schtasks scheduling job on remote system - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect suspicious command-line arguments executed through 'schtasks.exe' to create a scheduled task on a remote endpoint. The analytic scans process data, checking for instances where 'schtasks.exe' has been used with specific command-line flags that suggest an attempt at lateral movement or remote code execution, common techniques employed by adversaries and red teams. Key data points include the process name, the specific command line used, the parent process name, the target destination, and the user involved. Also, timestamp data gives context to when these activities occurred.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = While it is possible to have false positives, due to legitimate administrative tasks, these are usually limited and should still be validated and investigated as appropriate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Schtasks used for forcing a reboot - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes a Splunk query to pinpoint potential threats by monitoring the 'schtasks.exe' command-line usage. This particular command, especially when used in tandem with 'shutdown' and '/create' flags, can suggest an adversarial force intending to schedule unwarranted system reboots. The query focuses on endpoint process data and retrieves details such as the process name, the parent process name, the destination, and the user involved. Essential to the investigation are the earliest and latest timestamps of these events, providing an activity timeline. Data such as the targeted host and initiating user offer valuable context for analyst.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = This analytic may also capture legitimate administrative activities such as system updates or maintenance tasks, which can be classified as false positives. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Screensaver Event Trigger Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect possible event trigger execution through screensaver registry entry modification for persistence or privilege escalation. This technique was seen in several APT and malware where they put the malicious payload path to the SCRNSAVE.EXE registry key to redirect the execution to their malicious payload path. This TTP is a good indicator that some attacker may modify this entry for their persistence and privilege escalation.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546", "T1546.002"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Script Execution via WMI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects any potential misuse of Windows Management Instrumentation (WMI) for malicious purposes since adversaries often use WMI to run scripts which allows them to carry out malicious activities without raising suspicion. The detection is made by monitoring the process 'scrcons.exe', which is essential to run WMI scripts. The detection is important because it proactively identifies and responds to potential threats that leverage WMI for malicious purposes that can lead to system compromise, data exfiltration, or the establishment of persistence within the environment. False positives might occur since administrators might occasionally use WMI to launch scripts for legitimate purposes. Therefore, you must distinguish between malicious and benign activities.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, administrators may use wmi to launch scripts for legitimate purposes. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Sdclt UAC Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious sdclt.exe registry modification. This technique is commonly seen when attacker try to bypassed UAC by using sdclt.exe application by modifying some registry that sdclt.exe tries to open or query with payload file path on it to be executed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = Limited to no false positives are expected.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Sdelete Application Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect the execution of sdelete.exe application sysinternal tools. This tool is one of the most use tool of malware and adversaries to remove or clear their tracks and artifact in the targetted host. This tool is designed to delete securely a file in file system that remove the forensic evidence on the machine. A good TTP query to check why user execute this application which is not a common practice.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives", "Exploitation"], "mitre_attack": ["T1485", "T1070.004", "T1070"], "nist": ["DE.CM"]}
known_false_positives = user may execute and use this application
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - SearchProtocolHost with no Command Line with Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies searchprotocolhost.exe with no command line arguments and with a network connection. It is unusual for searchprotocolhost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. searchprotocolhost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - SecretDumps Offline NTDS Dumping Tool - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a potential usage of secretsdump.py tool for dumping credentials (ntlm hash) from a copy of ntds.dit and SAM.Security,SYSTEM registrry hive. This technique was seen in some attacker that dump ntlm hashes offline after having a copy of ntds.dit and SAM/SYSTEM/SECURITY registry hive.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.003", "T1003"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - ServicePrincipalNames Discovery with PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `powershell.exe` usage, using Script Block Logging EventCode 4104, related to querying the domain for Service Principle Names. typically, this is a precursor activity related to kerberoasting or the silver ticket attack. \
What is a ServicePrincipleName? \
A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.\
The following analytic identifies the use of KerberosRequestorSecurityToken class within the script block. Using .NET System.IdentityModel.Tokens.KerberosRequestorSecurityToken class in PowerShell is the equivelant of using setspn.exe. \
During triage, review parallel processes for further suspicious activity.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558.003"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, however filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - ServicePrincipalNames Discovery with SetSPN - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `setspn.exe` usage related to querying the domain for Service Principle Names. typically, this is a precursor activity related to kerberoasting or the silver ticket attack. \
What is a ServicePrincipleName? \
A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.\
Example usage includes the following \
1. setspn -T offense -Q */* 1. setspn -T attackrange.local -F -Q MSSQLSvc/* 1. setspn -Q */* > allspns.txt 1. setspn -q \
Values \
1. -F = perform queries at the forest, rather than domain level 1. -T = perform query on the specified domain or forest (when -F is also used) 1. -Q = query for existence of SPN \
During triage, review parallel processes for further suspicious activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558.003"], "nist": ["DE.CM"]}
known_false_positives = False positives may be caused by Administrators resetting SPNs or querying for SPNs. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Services Escalate Exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of `svc-exe` with Cobalt Strike. The behavior typically follows after an adversary has already gained initial access and is escalating privileges. Using `svc-exe`, a randomly named binary will be downloaded from the remote Teamserver and placed on disk within `C:\Windows\400619a.exe`. Following, the binary will be added to the registry under key `HKLM\System\CurrentControlSet\Services\400619a\` with multiple keys and values added to look like a legitimate service. Upon loading, `services.exe` will spawn the randomly named binary from `\\127.0.0.1\ADMIN$\400619a.exe`. The process lineage is completed with `400619a.exe` spawning rundll32.exe, which is the default `spawnto_` value for Cobalt Strike. The `spawnto_` value is arbitrary and may be any process on disk (typically system32/syswow64 binary). The `spawnto_` process will also contain a network connection. During triage, review parallel procesess and identify any additional file modifications.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as `services.exe` should never spawn a process from `ADMIN$`. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Services LOLBAS Execution Process Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `services.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing the Service Control Manager and creating a remote malicious service, the executed command is spawned as a child process of `services.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of services.exe that are part of the LOLBAS project can help defenders identify lateral movement activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may trigger this behavior, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Monitor for changes of the ExecutionPolicy in the registry to the values "unrestricted" or "bypass," which allows the execution of malicious scripts.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.CM"]}
known_false_positives = Administrators may attempt to change the default execution policy on a system for a variety of reasons. However, setting the policy to "unrestricted" or "bypass" as this search is designed to identify, would be unusual. Hits should be reviewed and investigated as appropriate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Shim Database File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for shim database files being written to default directories. The sdbinst.exe application is used to install shim database files (.sdb). According to Microsoft, a shim is a small library that transparently intercepts an API, changes the parameters passed, handles the operation itself, or redirects the operation elsewhere.
how_to_implement = You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.011", "T1546"], "nist": ["DE.CM"]}
known_false_positives = Because legitimate shim files are created and used all the time, this event, in itself, is not suspicious. However, if there are other correlating events, it may warrant further investigation.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Shim Database Installation With Suspicious Parameters - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search detects the process execution and arguments required to silently create a shim database.  The sdbinst.exe application is used to install shim database files (.sdb). A shim is a small library which transparently intercepts an API, changes the parameters passed, handles the operation itself, or redirects the operation elsewhere.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.011", "T1546"], "nist": ["DE.CM"]}
known_false_positives = None identified
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Short Lived Scheduled Task - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows Security EventCode 4698, "A scheduled task was created," and EventCode 4699, "A scheduled task was deleted," to identify scheduled tasks that are created and deleted within a short time frame of less than 30 seconds. This behavior is indicative of a potential lateral movement attack where the Task Scheduler is abused to achieve code execution. Both red teams and adversaries may exploit the Task Scheduler for lateral movement and remote code execution.\
To implement this analytic, ensure that you are ingesting Windows Security Event Logs with EventCode 4698 enabled. Additionally, the Windows TA (Technology Add-on) is required to parse and extract the necessary information from the logs.\
It's important to note that while uncommon, legitimate applications may create and delete scheduled tasks within a short duration. Analysts should filter the results based on the specific context and environment to reduce false positives.\
Identifying short-lived scheduled tasks is valuable for a SOC as it can indicate malicious activities attempting to move laterally or execute unauthorized code on Windows systems. By detecting and investigating these events, security analysts can respond promptly to prevent further compromise and mitigate potential risks. The impact of a true positive could range from unauthorized access to data exfiltration or the execution of malicious payloads.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005"], "nist": ["DE.CM"]}
known_false_positives = Although uncommon, legitimate applications may create and delete a Scheduled Task within 30 seconds. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Short Lived Windows Accounts - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The following analytic detects the creation and deletion of accounts in a short time period to identify potential threats earlier and take appropriate actions to mitigate the risks. Helps prevent or minimize the potential damage caused by unauthorized access or malicious activities within the environment. This detection is made by a Splunk query that searches for events with the result IDs 4720 and 4726 in the "Change" data model. The query then groups the results by time, user, and destination. The result is filtered to only include events with the specified result IDs. The "transaction" command is used to group events that occur within a specified time span and have the same user but are not connected. Finally, the relevant information such as the first and last time of the event, the count, user, destination, and result ID are displayed in a table. This detection is important because it suggests that an attacker is attempting to create and delete accounts rapidly, potentially to cover their tracks or gain unauthorized access. The impact of such an attack can include unauthorized access to sensitive data, privilege escalation, or the ability to carry out further malicious activities within the environment. Next steps include investigating the events flagged by the analytic, review the account creation and deletion activities, and analyze any associated logs or artifacts to determine the intent and impact of the attack.
how_to_implement = This search requires you to have enabled your Group Management Audit Logs in your Local Windows Security Policy and be ingesting those logs.  More information on how to enable them can be found here: http://whatevernetworks.com/auditing-group-membership-changes-in-active-directory/
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.CM"]}
known_false_positives = It is possible that an administrator created and deleted an account in a short time period.  Verifying activity with an administrator is advised.
providing_technologies = null

[savedsearch://ESCU - SilentCleanup UAC Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious modification of registry that may related to UAC bypassed. This registry will be trigger once the attacker abuse the silentcleanup task schedule to gain high privilege execution that will bypass User control account.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Single Letter Process On Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a behavior where a process name consists only of a single letter that helps to detect potential threats earlier and mitigate the risks. This detection is important because it indicates the presence of malware or an attacker attempting to evade detection by using a process name that is difficult to identify or track so that he can carry out malicious activities such as data theft or ransomware attacks. False positives might occur since there might be legitimate uses of single-letter process names in your environment. Next steps include reviewing the process details and investigating any suspicious activity upon triage.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204", "T1204.002"], "nist": ["DE.CM"]}
known_false_positives = Single-letter executables are not always malicious. Investigate this activity with your normal incident-response process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - SLUI RunAs Elevated - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Microsoft Software Licensing User Interface Tool, `slui.exe`, elevating access using the `-verb runas` function. This particular bypass utilizes a registry key/value. Identified by two sources, the registry keys are `HKCU\Software\Classes\exefile\shell` and `HKCU\Software\Classes\launcher.Systemsettings\Shell\open\command`. To simulate this behavior, multiple POC are available. The analytic identifies the use of `runas` by `slui.exe`.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives should be present as this is not commonly used by legitimate applications.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - SLUI Spawning a Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Microsoft Software Licensing User Interface Tool, `slui.exe`, spawning a child process. This behavior is associated with publicly known UAC bypass. `slui.exe` is commonly associated with software updates and is most often spawned by `svchost.exe`. The `slui.exe` process should not have child processes, and any processes spawning from it will be running with elevated privileges. During triage, review the child process and additional parallel processes. Identify any file modifications that may have lead to the bypass.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = Certain applications may spawn from `slui.exe` that are legitimate. Filtering will be needed to ensure proper monitoring.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Spike in File Writes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for a sharp increase in the number of files written to a particular host
how_to_implement = In order to implement this search, you must populate the Endpoint file-system data model node. This is typically populated via endpoint detection and response product, such as Carbon Black or endpoint data sources such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the file system.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = It is important to understand that if you happen to install any new applications on your hosts or are copying a large number of files, you can expect to see a large increase of file modifications.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Spoolsv Spawning Rundll32 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious child process, `rundll32.exe`, with no command-line arguments being spawned from `spoolsv.exe`. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to spawn a process. During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives have been identified. There are limited instances where `rundll32.exe` may be spawned by a legitimate print driver.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Spoolsv Suspicious Loaded Modules - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect suspicious loading of dll in specific path relative to printnightmare exploitation. In this search we try to detect the loaded modules made by spoolsv.exe after the exploitation.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Spoolsv Suspicious Process Access - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a suspicious behavior related to PrintNightmare, or CVE-2021-34527 previously (CVE-2021-1675),  to gain privilege escalation on the vulnerable machine. This exploit attacks a critical Windows Print Spooler Vulnerability to elevate privilege. This detection is to look for suspicious process access made by the spoolsv.exe that may related to the attack.
how_to_implement = To successfully implement this search, you need to be ingesting logs with process access event where SourceImage, TargetImage, GrantedAccess and CallTrace executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of spoolsv.exe.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = Unknown. Filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Spoolsv Writing a DLL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a `.dll` being written by `spoolsv.exe`. This was identified during our testing of CVE-2021-34527 previously (CVE-2021-1675) or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to write a `.dll`. Current POC code used will write the suspicious DLL to disk within a path of `\spool\drivers\x64\`. During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = Unknown.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Spoolsv Writing a DLL - Sysmon - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a `.dll` being written by `spoolsv.exe`. This was identified during our testing of CVE-2021-34527 previously(CVE-2021-1675) or PrintNightmare. Typically, this is not normal behavior for `spoolsv.exe` to write a `.dll`. Current POC code used will write the suspicious DLL to disk within a path of `\spool\drivers\x64\`. During triage, isolate the endpoint and review for source of exploitation. Capture any additional file modification events.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances where renamed rundll32.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.012", "T1547"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives. Filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Sqlite Module In Temp Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious file creation of sqlite3.dll in %temp% folder. This behavior was seen in IcedID malware where it download sqlite module to parse browser database like for chrome or firefox to stole browser information related to bank, credit card or credentials.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1005"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Steal or Forge Authentication Certificates Behavior Identified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This correlation rule focuses on detecting potential threats associated with MITRE ATT&CK T1649 (Steal or Forge Authentication Certificates). The rule is designed to identify instances where 5 or more analytics related to Windows Certificate Services analytic story that are triggered within a specified time frame, which may indicate a potential attack in progress. By aggregating these analytics, security teams can swiftly respond to and investigate any suspicious activities, enhancing their ability to protect critical assets and prevent unauthorized access to sensitive information.
how_to_implement = The Windows Certificate Services analytic story must have 5 or more analytics enabled. In addition, ensure data is being logged that is required. Modify the correlation as needed based on volume of noise related to the other analytics.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present based on automated tooling or system administrators. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Sunburst Correlation DLL and Network Event - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The malware sunburst will load the malicious dll by SolarWinds.BusinessLayerHost.exe. After a period of 12-14 days, the malware will attempt to resolve a subdomain of avsvmcloud.com. This detections will correlate both events.
how_to_implement = This detection relies on sysmon logs with the Event ID 7, Driver loaded. Please tune your sysmon config that you DriverLoad event for SolarWinds.Orion.Core.BusinessLayer.dll is captured by Sysmon. Additionally, you need sysmon logs for Event ID 22, DNS Query. We suggest to run this detection at least once a day over the last 14 days.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1203"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Suspicious Computer Account Name Change - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) exploitation chain, adversaries need to create a new computer account name and rename it to match the name of a domain controller account without the ending '$'. In Windows Active Directory environments, computer account names always end with `$`. This analytic leverages Event Id 4781, `The name of an account was changed`, to identify a computer account rename event with a suspicious name that does not terminate with `$`. This behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation.
how_to_implement = To successfully implement this search, you need to be ingesting Windows event logs from your hosts. In addition, the Splunk Windows TA is needed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.CM"]}
known_false_positives = Renaming a computer account name to a name that not end with '$' is highly unsual and may not have any legitimate scenarios.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Suspicious Copy on System32 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious copy of file from systemroot folder of the windows OS. This technique is commonly used by APT or other malware as part of execution (LOLBIN) to run its malicious code using the available legitimate tool in OS. this type of event may seen or may execute of normal user in some instance but this is really a anomaly that needs to be check within the network.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036.003", "T1036"], "nist": ["DE.CM"]}
known_false_positives = every user may do this event but very un-ussual.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Curl Network Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of a curl contacting suspicious remote domains to checkin to Command And Control servers or download further implants. In the context of Silver Sparrow, curl is identified contacting s3.amazonaws.com. This particular behavior is common with MacOS adware-malicious software.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = Unknown. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious DLLHost no Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies DLLHost.exe with no command line arguments. It is unusual for DLLHost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. DLLHost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Driver Loaded Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will detect suspicious driver loaded paths. This technique is commonly used by malicious software like coin miners (xmrig) to register its malicious driver from notable directories where executable or drivers do not commonly exist. During triage, validate this driver is for legitimate business use. Review the metadata and certificate information. Unsigned drivers from non-standard paths is not normal, but occurs. In addition, review driver loads into `ntoskrnl.exe` for possible other drivers of interest. Long tail analyze drivers by path (outside of default, and in default) for further review.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the driver loaded and Signature from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003", "T1543"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives will be present. Some applications do load drivers
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Suspicious Event Log Service Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows Event ID 1100 to identify when Windows event log service is shutdown. Note that this is a voluminous analytic that will require tuning or restricted to specific endpoints based on criticality. This event generates every time Windows Event Log service has shut down. It also generates during normal system shutdown. During triage, based on time of day and user, determine if this was planned. If not planned, follow through with reviewing parallel alerts and other data sources to determine what else may have occurred.
how_to_implement = To successfully implement this search, you need to be ingesting Windows event logs from your hosts. In addition, the Splunk Windows TA is needed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.001"], "nist": ["DE.CM"]}
known_false_positives = It is possible the Event Logging service gets shut down due to system errors or legitimately administration tasks. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Suspicious GPUpdate no Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies gpupdate.exe with no command line arguments. It is unusual for gpupdate.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. gpupdate.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious IcedID Rundll32 Cmdline - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious rundll32.exe commandline to execute dll file. This technique was seen in IcedID malware to load its payload dll with the following parameter to load encrypted dll payload which is the license.dat.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = limitted. this parameter is not commonly used by windows application but can be used by the network operator.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Image Creation In Appdata Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious creation of image in appdata folder made by process that also has a file reference in appdata folder. This technique was seen in remcos rat that capture screenshot of the compromised machine and place it in the appdata and will be send to its C2 server. This TTP is really a good indicator to check that process because it is in suspicious folder path and image files are not commonly created by user in this folder path.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Kerberos Service Ticket Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) exploitation chain, adversaries will request and obtain a Kerberos Service Ticket (TGS) with a domain controller computer account as the Service Name. This Service Ticket can be then used to take control of the domain controller on the final part of the attack. This analytic leverages Event Id 4769, `A Kerberos service ticket was requested`, to identify an unusual TGS request where the Account_Name requesting the ticket matches the Service_Name field. This behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.CM"]}
known_false_positives = We have tested this detection logic with ~2 million 4769 events and did not identify false positives. However, they may be possible in certain environments. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Suspicious Linux Discovery Commands - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search, detects execution of suspicious bash commands from various commonly leveraged bash scripts like (AutoSUID, LinEnum, LinPeas) to perform discovery of possible paths of privilege execution, password files, vulnerable directories, executables and file permissions on a Linux host.\
The search logic specifically looks for high number of distinct commands run in a short period of time.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.004"], "nist": ["DE.CM"]}
known_false_positives = Unless an administrator is using these commands to troubleshoot or audit a system, the execution of these commands should be monitored.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious microsoft workflow compiler rename - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a renamed instance of microsoft.workflow.compiler.exe. Microsoft.workflow.compiler.exe is natively found in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 and is rarely utilized. When investigating, identify the executed code on disk and review. A spawned child process from microsoft.workflow.compiler.exe is uncommon. In any instance, microsoft.workflow.compiler.exe spawning from an Office product or any living off the land binary is highly suspect.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1127", "T1036.003"], "nist": ["DE.AE"]}
known_false_positives = Although unlikely, some legitimate applications may use a moved copy of microsoft.workflow.compiler.exe, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious microsoft workflow compiler usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies microsoft.workflow.compiler.exe usage. microsoft.workflow.compiler.exe is natively found in C:\Windows\Microsoft.NET\Framework64\v4.0.30319 and is rarely utilized. When investigating, identify the executed code on disk and review. It is not a commonly used process by many applications.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1127"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, limited instances have been identified coming from native Microsoft utilities similar to SCCM.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious msbuild path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies msbuild.exe executing from a non-standard path. Msbuild.exe is natively found in C:\Windows\Microsoft.NET\Framework\v4.0.30319 and C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Instances of Visual Studio will run a copy of msbuild.exe. A moved instance of MSBuild is suspicious, however there are instances of build applications that will move or use a copy of MSBuild.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1127", "T1036.003", "T1127.001"], "nist": ["DE.CM"]}
known_false_positives = Some legitimate applications may use a moved copy of msbuild.exe, triggering a false positive. Baselining of MSBuild.exe usage is recommended to better understand it's path usage. Visual Studio runs an instance out of a path that will need to be filtered on.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious MSBuild Rename - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies renamed instances of msbuild.exe executing. Msbuild.exe is natively found in C:\Windows\Microsoft.NET\Framework\v4.0.30319 and C:\Windows\Microsoft.NET\Framework64\v4.0.30319. During investigation, identify the code executed and what is executing a renamed instance of MSBuild.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1127", "T1036.003", "T1127.001"], "nist": ["DE.AE"]}
known_false_positives = Although unlikely, some legitimate applications may use a moved copy of msbuild, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious MSBuild Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies wmiprvse.exe spawning msbuild.exe. This behavior is indicative of a COM object being utilized to spawn msbuild from wmiprvse.exe. It is common for MSBuild.exe to be spawned from devenv.exe while using Visual Studio. In this instance, there will be command line arguments and file paths. In a malicious instance, MSBuild.exe will spawn from non-standard processes and have no command line arguments. For example, MSBuild.exe spawning from explorer.exe, powershell.exe is far less common and should be investigated.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1127", "T1127.001"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious mshta child process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies child processes spawning from  "mshta.exe". The search will return the first time and last time these command-line arguments were used for these executions, as well as the target system, the user, parent process "mshta.exe" and its child process.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious mshta spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies wmiprvse.exe spawning mshta.exe. This behavior is indicative of a DCOM object being utilized to spawn mshta from wmiprvse.exe or svchost.exe. In this instance, adversaries may use LethalHTA that will spawn mshta.exe from svchost.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.005"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may exhibit this behavior, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious PlistBuddy Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of a native MacOS utility, PlistBuddy, creating or modifying a properly list (.plist) file. In the instance of Silver Sparrow, the following commands were executed:\
- PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :ProgramArguments:0 string /bin/sh" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist \
Upon triage, capture the property list file being written to disk and review for further indicators. Contain the endpoint and triage further.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.001", "T1543"], "nist": ["DE.CM"]}
known_false_positives = Some legitimate applications may use PlistBuddy to create or modify property lists and possibly generate false positives. Review the property list being modified or created to confirm.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious PlistBuddy Usage via OSquery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of a native MacOS utility, PlistBuddy, creating or modifying a properly list (.plist) file. In the instance of Silver Sparrow, the following commands were executed:\
- PlistBuddy -c "Add :Label string init_verx" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :RunAtLoad bool true" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :StartInterval integer 3600" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :ProgramArguments array" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :ProgramArguments:0 string /bin/sh" ~/Library/Launchagents/init_verx.plist \
- PlistBuddy -c "Add :ProgramArguments:1 string -c" ~/Library/Launchagents/init_verx.plist \
Upon triage, capture the property list file being written to disk and review for further indicators. Contain the endpoint and triage further.
how_to_implement = OSQuery must be installed and configured to pick up process events (info at https://osquery.io) as well as using the Splunk OSQuery Add-on https://splunkbase.splunk.com/app/4402. Modify the macro and validate fields are correct.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.001", "T1543"], "nist": ["DE.CM"]}
known_false_positives = Some legitimate applications may use PlistBuddy to create or modify property lists and possibly generate false positives. Review the property list being modified or created to confirm.
providing_technologies = null

[savedsearch://ESCU - Suspicious Process DNS Query Known Abuse Web Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a suspicious process making a DNS query via known, abused text-paste web services, VoIP, instant messaging, and digital distribution platforms used to download external files. This technique is abused by adversaries, malware actors, and red teams to download a malicious file on the target host. This is a good TTP indicator for possible initial access techniques. A user will experience false positives if the following instant messaging is allowed or common applications like telegram or discord are allowed in the corporate network.
how_to_implement = This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.005", "T1059"], "nist": ["DE.CM"]}
known_false_positives = Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Suspicious Process Executed From Container File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a suspicious process spawned by another process from within common container/archive file types. This technique was a common technique used by adversaries and malware to execute scripts or evade defenses. This TTP may detect some normal software installation or user behaviors where opening archive files is common.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1204.002", "T1036.008"], "nist": ["DE.CM"]}
known_false_positives = Various business process or userland applications and behavior.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Process File Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a suspicious processes running in file paths that are not typically associated with legitimate software. Adversaries often employ this technique to drop and execute malicious executables in accessible locations that do not require administrative privileges. By monitoring for processes running in such unconventional file paths, we can identify potential indicators of compromise and proactively respond to malicious activity. This analytic plays a crucial role in enhancing system security by pinpointing suspicious behaviors commonly associated with malware and unauthorized software execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543"], "nist": ["DE.CM"]}
known_false_positives = Administrators may allow execution of specific binaries in non-standard paths. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Process With Discord DNS Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a process making a DNS query to Discord, a well known instant messaging and digital distribution platform. Discord can be abused by adversaries, as seen in the WhisperGate campaign, to host and download malicious. external files. A process resolving a Discord DNS name could be an indicator of malware trying to download files from Discord for further execution.
how_to_implement = his detection relies on sysmon logs with the Event ID 22, DNS Query.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.005", "T1059"], "nist": ["DE.AE"]}
known_false_positives = Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Suspicious Reg exe Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for reg.exe being launched from a command prompt not started by the user. When a user launches cmd.exe, the parent process is usually explorer.exe. This search filters out those instances.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = It's possible for system administrators to write scripts that exhibit this behavior. If this is the case, the search will need to be modified to filter them out.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Regsvr32 Register Suspicious Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Adversaries may abuse Regsvr32.exe to proxy execution of malicious code by using non-standard file extensions to load DLLs. Upon investigating, look for network connections to remote destinations (internal or external). Review additional parrallel processes and child processes for additional activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.010"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives with the query restricted to specified paths. Add more world writeable paths as tuning continues.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Rundll32 dllregisterserver - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe using dllregisterserver on the command line to load a DLL. When a DLL is registered, the DllRegisterServer method entry point in the DLL is invoked. This is typically seen when a DLL is being registered on the system. Not every instance is considered malicious, but it will capture malicious use of it. During investigation, review the parent process and parrellel processes executing. Capture the DLL being loaded and inspect further. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = This is likely to produce false positives and will require some filtering. Tune the query by adding command line paths to known good DLLs, or filtering based on parent process names.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Rundll32 no Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe with no command line arguments. It is unusual for rundll32.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may use a moved copy of rundll32, triggering a false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Rundll32 PluginInit - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious rundll32.exe process with plugininit parameter. This technique is commonly seen in IcedID malware to execute its initial dll stager to download another payload to the compromised machine.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = third party application may used this dll export name to execute function.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Rundll32 StartW - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe executing a DLL function name, Start and StartW, on the command line that is commonly observed with Cobalt Strike x86 and x64 DLL payloads. Rundll32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. Typically, the DLL will be written and loaded from a world writeable path or user location. In most instances it will not have a valid certificate (Unsigned). During investigation, review the parent process and other parallel application execution. Capture and triage the DLL in question. In the instance of Cobalt Strike, rundll32.exe is the default process it opens and injects shellcode into. This default process can be changed, but typically is not.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, some legitimate applications may use Start as a function and call it via the command line. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Scheduled Task from Public Directory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic, "Suspicious Scheduled Task from Public Directory", detects the registration of scheduled tasks aimed to execute a binary or script from public directories, a behavior often associated with malware deployment. It utilizes the Sysmon Event ID 1 data source, searching for instances where schtasks.exe is connected with the directories users\public, \programdata\, or \windows\temp and involves the /create command.\
The registration of such scheduled tasks in public directories could suggest that an attacker is trying to maintain persistence or execute malicious scripts. If confirmed as a true positive, this could lead to data compromise, unauthorized access, and potential lateral movement within the network.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.AE"]}
known_false_positives = The main source of false positives could be the legitimate use of scheduled tasks from these directories. Careful tuning of this search may be necessary to suit the specifics of your environment, reducing the rate of false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious SearchProtocolHost no Command Line Arguments - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies searchprotocolhost.exe with no command line arguments. It is unusual for searchprotocolhost.exe to execute with no command line arguments present. This particular behavior is common with malicious software, including Cobalt Strike. During investigation, identify any network connections and parallel processes. Identify any suspicious module loads related to credential dumping or file writes. searchprotocolhost.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives may be present in small environments. Tuning may be required based on parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious SQLite3 LSQuarantine Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of a SQLite3 querying the MacOS preferences to identify the original URL the pkg was downloaded from. This particular behavior is common with MacOS adware-malicious software. Upon triage, review other processes in parallel for suspicious activity. Identify any recent package installations.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1074"], "nist": ["DE.CM"]}
known_false_positives = Unknown.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious Ticket Granting Ticket Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = As part of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) exploitation chain, adversaries will need to request a Kerberos Ticket Granting Ticket (TGT) on behalf of the newly created and renamed computer account. The TGT request will be preceded by a computer account name event. This analytic leverages Event Id 4781, `The name of an account was changed` and event Id 4768 `A Kerberos authentication ticket (TGT) was requested` to correlate a sequence of events where the new computer account on event id 4781 matches the request account on event id 4768. This behavior could represent an exploitation attempt of CVE-2021-42278 and CVE-2021-42287 for privilege escalation.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078", "T1078.002"], "nist": ["DE.AE"]}
known_false_positives = A computer account name change event inmediately followed by a kerberos TGT request with matching fields is unsual. However, legitimate behavior may trigger it. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Suspicious WAV file in Appdata Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious creation of .wav file in appdata folder. This behavior was seen in Remcos RAT malware where it put the audio recording in the appdata\audio folde as part of data collection. this recording can be send to its C2 server as part of its exfiltration to the compromised machine. creation of wav files in this folder path is not a ussual disk place used by user to save audio format file.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, file_name, file_path and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious wevtutil Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The wevtutil.exe application is the windows event log utility. This searches for wevtutil.exe with parameters for clearing the application, security, setup, trace or system event logs.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070.001", "T1070"], "nist": ["DE.CM"]}
known_false_positives = The wevtutil.exe application is a legitimate Windows event log utility. Administrators may use it to manage Windows event logs.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Suspicious writes to windows Recycle Bin - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = The following analytic detects when a process other than explorer.exe writes to the Windows Recycle Bin to detect potential threats earlier and mitigate the risks. This detection is made by a Splunk query that utilizes the Endpoint.Filesystem data model and the Endpoint.Processes data model. The query looks for any process writing to the "*$Recycle.Bin*" file path, excluding explorer.exe. This detection is important because it suggests that an attacker is attempting to hide their activities by using the Recycle Bin, which can lead to data theft, ransomware, or other damaging outcomes. Detecting writes to the Recycle Bin by a process other than explorer.exe can help to investigate and determine if the activity is malicious or benign. False positives might occur since there might be legitimate uses of the Recycle Bin by processes other than explorer.exe. Next steps include reviewing the process writing to the Recycle Bin and any relevant on-disk artifacts upon triage.
how_to_implement = To successfully implement this search you need to be ingesting information on filesystem and process logs responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` nodes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.CM"]}
known_false_positives = Because the Recycle Bin is a hidden folder in modern versions of Windows, it would be unusual for a process other than explorer.exe to write to it. Incidents should be investigated as appropriate.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Svchost LOLBAS Execution Process Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to spot instances of 'svchost.exe' initiating a Living Off The Land Binaries and Scripts (LOLBAS) execution process. Often, adversaries manipulate Task Scheduler to execute code on remote endpoints, resulting in the spawning of a malicious command as a child process of 'svchost.exe'. By tracking child processes of 'svchost.exe' that align with the LOLBAS project, potential lateral movement activity can be detected. The analytic examines process details, including the process name, parent process, and command-line executions. A comprehensive list of LOLBAS processes is included in the search parameters. Although the analytic might catch legitimate applications exhibiting this behavior, these instances should be filtered accordingly. The findings from this analytic offer valuable insight into potentially malicious activities on an endpoint.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may trigger this behavior, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - System Info Gathering Using Dxdiag Application - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious dxdiag.exe process command-line execution. Dxdiag is used to collect the system info of the target host. This technique has been used by Remcos RATS, various actors, and other malware to collect information as part of the recon or collection phase of an attack. This behavior should rarely be seen in a corporate network, but this command line can be used by a network administrator to audit host machine specifications. Thus in some rare cases, this detection will contain false positives in its results. To triage further, analyze what commands were passed after it pipes out the result to a file for further processing.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592"], "nist": ["DE.AE"]}
known_false_positives = This commandline can be used by a network administrator to audit host machine specifications. Thus, a filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - System Information Discovery Detection - Rule]
type = detection
asset_type = Windows
confidence = medium
explanation = Detect system information discovery techniques used by attackers to understand configurations of the system to further exploit it.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.CM"]}
known_false_positives = Administrators debugging servers
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - System Processes Run From Unexpected Locations - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for system processes that typically execute from `C:\Windows\System32\` or `C:\Windows\SysWOW64`.  This may indicate a malicious process that is trying to hide as a legitimate process.\
This detection utilizes a lookup that is deduped `system32` and `syswow64` directories from Server 2016 and Windows 10.\
During triage, review the parallel processes - what process moved the native Windows binary? identify any artifacts on disk and review. If a remote destination is contacted, what is the reputation?
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003"], "nist": ["DE.AE"]}
known_false_positives = This detection may require tuning based on third party applications utilizing native Windows binaries in non-standard paths.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - System User Discovery With Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `query.exe` with command-line arguments utilized to discover the logged user. Red Teams and adversaries alike may leverage `query.exe` to identify system users on a compromised endpoint for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - System User Discovery With Whoami - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `whoami.exe` without any arguments. This windows native binary prints out the current logged user. Red Teams and adversaries alike may leverage `whoami.exe` to identify system users on a compromised endpoint for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Time Provider Persistence Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious modification of time provider registry for persistence and autostart. This technique can allow the attacker to persist on the compromised host and autostart as soon as the machine boot up. This TTP can be a good indicator of suspicious behavior since this registry is not commonly modified by normal user or even an admin.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.003", "T1547"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Trickbot Named Pipe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is to detect potential trickbot infection through the create/connected named pipe to the system. This technique is used by trickbot to communicate to its c2 to post or get command during infection.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and pipename from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. .
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - UAC Bypass MMC Load Unsigned Dll - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious loaded unsigned dll by MMC.exe application. This technique is commonly seen in attacker that tries to bypassed UAC feature or gain privilege escalation. This is done by modifying some CLSID registry that will trigger the mmc.exe to load the dll path
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548", "T1218.014"], "nist": ["DE.CM"]}
known_false_positives = unknown. all of the dll loaded by mmc.exe is microsoft signed dll.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - UAC Bypass With Colorui COM Object - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a possible uac bypass using the colorui.dll COM Object. this technique was seen in so many malware and ransomware like lockbit where it make use of the colorui.dll COM CLSID to bypass UAC.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.003"], "nist": ["DE.CM"]}
known_false_positives = not so common. but 3rd part app may load this dll.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Uninstall App Using MsiExec - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious un-installation of application using msiexec. This technique was seen in conti leak tool and script where it tries to uninstall AV product using this commandline. This commandline to uninstall product is not a common practice in enterprise network.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007", "T1218"], "nist": ["DE.CM"]}
known_false_positives = unknown.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Unknown Process Using The Kerberos Protocol - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process performing an outbound connection on port 88 used by default by the network authentication protocol Kerberos. Typically, on a regular Windows endpoint, only the lsass.exe process is the one tasked with connecting to the Kerberos Distribution Center to obtain Kerberos tickets. Identifying an unknown process using this protocol may be evidence of an adversary abusing the Kerberos protocol.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1550"], "nist": ["DE.CM"]}
known_false_positives = Custom applications may leverage the Kerberos protocol. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Unload Sysmon Filter Driver - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Attackers often disable security tools to avoid detection. This search looks for the usage of process `fltMC.exe` to unload a Sysmon Driver that will stop sysmon from collecting the data.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Unknown at the moment
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Unloading AMSI via Reflection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify suspicious PowerShell execution. Script Block Logging captures the command sent to PowerShell, the full command to be executed. Upon enabling, logs will output to Windows event logs. Dependent upon volume, enable on critical endpoints or all. \
This analytic identifies the behavior of AMSI being tampered with. Implemented natively in many frameworks, the command will look similar to `SEtValuE($Null,(New-OBJEct COLlECtionS.GenerIC.HAshSEt{[StrINg]))}$ReF=[ReF].AsSeMbLY.GeTTyPe("System.Management.Automation.Amsi"+"Utils")` taken from Powershell-Empire. \
During triage, review parallel processes using an EDR product or 4688 events. It will be important to understand the timeline of events around this activity. Review the entire logged PowerShell script block.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1562", "T1059.001", "T1059"], "nist": ["DE.CM"]}
known_false_positives = Potential for some third party applications to disable AMSI upon invocation. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Unusual Number of Computer Service Tickets Requested - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic leverages Event ID 4769, `A Kerberos service ticket was requested`, to identify an unusual number of computer service ticket requests from one source. When a domain joined endpoint connects to a remote endpoint, it first will request a Kerberos Ticket with the computer name as the Service Name. An endpoint requesting a large number of computer service tickets for different endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc. The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of service requests. To customize this analytic, users can try different combinations of the `bucket` span time,  the calculation of the `upperBound` field as well as the Outlier calculation. This logic can be used for real time security monitoring as well as threat hunting exercises.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = An single endpoint requesting a large number of computer service tickets is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systeams and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Unusual Number of Kerberos Service Tickets Requested - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic leverages Kerberos Event 4769, A Kerberos service ticket was requested, to identify a potential kerberoasting attack against Active Directory networks. Kerberoasting allows an adversary to request kerberos tickets for domain accounts typically used as service accounts and attempt to crack them offline allowing them to obtain privileged access to the domain.\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number service ticket requests. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.AE"]}
known_false_positives = An single endpoint requesting a large number of kerberos service tickets is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Unusual Number of Remote Endpoint Authentication Events - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic leverages Event ID 4624, `An account was successfully logged on`, to identify an unusual number of remote authentication attempts coming from one source. An endpoint authenticating to a large number of remote endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc. The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual high number of authentication events.To customize this analytic, users can try different combinations of the `bucket` span time,  the calculation of the `upperBound` field as well as the Outlier calculation.This logic can be used for real time security monitoring as well as threat hunting exercises.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078"], "nist": ["DE.AE"]}
known_false_positives = An single endpoint authenticating to a large number of hosts is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, jump servers and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Unusually Long Command Line - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects command lines that are extremely long, which might be indicative of malicious activity on your hosts because attackers often use obfuscated or complex command lines to hide their actions and evade detection. This helps to mitigate the risks associated with long command lines to enhance your overall security posture and reduce the impact of attacks. This detection is important because it suggests that an attacker might be attempting to execute a malicious command or payload on the host, which can lead to various damaging outcomes such as data theft, ransomware, or further compromise of the system. False positives might occur since legitimate processes or commands can sometimes result in long command lines. Next steps include conducting extensive triage and investigation to differentiate between legitimate and malicious activities. Review the source of the command line and the command itself during the triage. Additionally, capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the source of the attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Some legitimate applications start with long command lines.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Unusually Long Command Line - MLTK - Rule]
type = detection
asset_type = 
confidence = medium
explanation = Command lines that are extremely long may be indicative of malicious activity on your hosts. This search leverages the Machine Learning Toolkit (MLTK) to help identify command lines with lengths that are unusual for a given user.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.AE"]}
known_false_positives = Some legitimate applications use long command lines for installs or updates. You should review identified command lines for legitimacy. You may modify the first part of the search to omit legitimate command lines from consideration. If you are seeing more results than desired, you may consider changing the value of threshold in the search to a smaller value. You should also periodically re-run the support search to re-build the ML model on the latest data. You may get unexpected results if the user identified in the results is not present in the data used to build the associated model.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - User Discovery With Env Vars PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `powershell.exe` with command-line arguments that leverage PowerShell environment variables to identify the current logged user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - User Discovery With Env Vars PowerShell Script Block - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the use of PowerShell environment variables to identify the current logged user. Red Teams and adversaries may leverage this method to identify the logged user on a compromised endpoint for situational awareness and Active Directory Discovery.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this PowerShell commandlet for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - USN Journal Deletion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The fsutil.exe application is a legitimate Windows utility used to perform tasks related to the file allocation table (FAT) and NTFS file systems. The update sequence number (USN) change journal provides a log of all changes made to the files on the disk. This search looks for fsutil.exe deleting the USN journal.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.CM"]}
known_false_positives = None identified
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Vbscript Execution Using Wscript App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious wscript commandline to execute vbscript. This technique was seen in several malware to execute malicious vbs file using wscript application. commonly vbs script is associated to cscript process and this can be a technique to evade process parent child detections or even some av script emulation system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.005", "T1059"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Verclsid CLSID Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a possible abuse of verclsid to execute malicious file through generate CLSID. This process is a normal application of windows to verify the CLSID COM object before it is instantiated by Windows Explorer. This hunting query can be a good pivot point to analyze what is he CLSID or COM object pointing too to check if it is a valid application or not.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.012", "T1218"], "nist": ["DE.AE"]}
known_false_positives = windows can used this application for its normal COM object validation.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - W3WP Spawning Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This query identifies a shell, PowerShell.exe or Cmd.exe, spawning from W3WP.exe, or IIS. In addition to IIS logs, this behavior with an EDR product will capture potential webshell activity, similar to the HAFNIUM Group abusing CVEs, on publicly available Exchange mail servers. During triage, review the parent process and child process of the shell being spawned. Review the command-line arguments and any file modifications that may occur. Identify additional parallel process, child processes, that may highlight further commands executed. After triaging, work to contain the threat and patch the system that is vulnerable.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.003"], "nist": ["DE.CM"]}
known_false_positives = Baseline your environment before production. It is possible build systems using IIS will spawn cmd.exe to perform a software build. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WBAdmin Delete System Backups - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for flags passed to wbadmin.exe (Windows Backup Administrator Tool) that delete backup files. This is typically used by ransomware to prevent recovery.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1490"], "nist": ["DE.CM"]}
known_false_positives = Administrators may modify the boot configuration.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Wbemprox COM Object Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a potential suspicious process loading a COM object from wbemprox.dll or faskprox.dll. The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. This feature is being abused by several threat actors, adversaries or even red teamers to gain privilege escalation or even to evade detections. This TTP is a good indicator that a process is loading possible known .dll modules that were known for its COM object.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.003"], "nist": ["DE.CM"]}
known_false_positives = legitimate process that are not in the exception list may trigger this event.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Wermgr Process Connecting To IP Check Web Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is designed to detect suspicious wermgr.exe process that tries to connect to known IP web services. This technique is know for trickbot and other trojan spy malware to recon the infected machine and look for its ip address without so much finger print on the commandline process. Since wermgr.exe is designed for error handling process of windows it is really suspicious that this process is trying to connect to this IP web services cause that maybe cause of some malicious code injection.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, dns query name process path , and query ststus from your endpoints like EventCode 22. If you are using Sysmon, you must have at least version 12 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1590", "T1590.005"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Wermgr Process Create Executable File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this search is designed to detect potential malicious wermgr.exe process that drops or create executable file. Since wermgr.exe is an application trigger when error encountered in a process, it is really un ussual to this process to drop executable file. This technique is commonly seen in trickbot malware where it injects it code to this process to execute it malicious behavior like downloading other payload
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Tune and filter known instances of wermgr.exe may be used.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Wermgr Process Spawned CMD Or Powershell Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is designed to detect suspicious cmd and powershell process spawned by wermgr.exe process. This suspicious behavior are commonly seen in code injection technique technique like trickbot to execute a shellcode, dll modules to run malicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Wget Download and Bash Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of wget on Linux or MacOS attempting to download a file from a remote source and pipe it to bash. This is typically found with coinminers and most recently with CVE-2021-44228, a vulnerability in Log4j.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, however filtering may be required.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Abused Web Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a suspicious process making a DNS query via known, abused text-paste web services, VoIP, internet via secure tunneling,instant messaging, and digital distribution platforms used to download external files. This technique is abused by adversaries, malware actors, and red teams to download a malicious file on the target host. This is a good TTP indicator for possible initial access techniques. A user will experience false positives if the following instant messaging is allowed or common applications like telegram or discord are allowed in the corporate network.
how_to_implement = This detection relies on sysmon logs with the Event ID 22, DNS Query. We suggest you run this detection at least once a day over the last 14 days.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1102"], "nist": ["DE.CM"]}
known_false_positives = Noise and false positive can be seen if the following instant messaging is allowed to use within corporate network. In this case, a filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious process enabling the "SeDebugPrivilege" privilege token. SeDebugPrivilege allows a process to inspect and adjust the memory of other processes, and has long been a security concern. SeDebugPrivilege allows the token bearer to access any process or thread, regardless of security descriptors, per Palantir. This technique is abused by adversaries to gain debug privileges with their malicious software to be able to access or debug a process to dump credentials or to inject malicious code.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4703 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.002", "T1134"], "nist": ["DE.AE"]}
known_false_positives = Some native binaries and browser applications may request SeDebugPrivilege. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Access Token Manipulation Winlogon Duplicate Token Handle - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process requesting access to winlogon.exe attempting to duplicate its handle. This technique was seen in several adversaries to gain privileges for their process. Winlogon.exe is the common targeted process of this technique because it contains high privileges and security tokens.
how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.001", "T1134"], "nist": ["DE.AE"]}
known_false_positives = It is possible legitimate applications will request access to winlogon, filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Access Token Winlogon Duplicate Handle In Uncommon Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process requesting access in winlogon.exe to duplicate its handle with a non-common or public process source path. This technique was seen where adversaries attempt to gain privileges to their process. This duplicate handle access technique, may refer to a malicious process duplicating the process token of winlogon.exe and using it to a new process instance. Winlogon.exe is the common targeted process of this technique because it contains high privileges and security tokens.
how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.001", "T1134"], "nist": ["DE.AE"]}
known_false_positives = It is possible legitimate applications will request access to winlogon, filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Account Discovery for None Disable User Account - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging to identify the execution of the PowerView PowerShell commandlet Get-NetUser. In the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user accounts that are not disabled. The full script block text based on the CISA-23-347A advisory is "Get-NetUser -UACFilter NOT_ACCOUNTDISABLE". Utilize this query to identify potential suspicious activity of user account enumeration.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.=
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Account Discovery for Sam Account Name - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetUser. In the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user account's "samccountname". This hunting query is a good pivot to look for suspicious process or malware that gather user account information in a host or within network system.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.=
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Account Discovery With NetUser PreauthNotRequire - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetUser. This technique was observed in the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user accounts that do not require preauthentication for Kerberos. This hunting query is a good pivot to look for suspicious process or malware that gather user account information in a host or within network system.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.=
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Abnormal Object Access Activity - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Windows Active Directory contains numerous objects. A statistically significant increase in access to these objects may be evidence of attacker enumeration of Active Directory.
how_to_implement = Enable Audit Directory Service Access via GPO and collect event code 4662. The required SACLs need to be created for the relevant objects. Be aware Splunk filters this event by default on the Windows TA. Recommend pre-filtering any known service accounts that frequently query AD to make detection more accurate. Setting wide search window of 48~72hr may smooth out misfires.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.AE"]}
known_false_positives = Service accounts or applications that routinely query Active Directory for information.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD AdminSDHolder ACL Modified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the modification of the Access Control List for the AdminSDHolder object within a Windows domain. Specifically, the detection triggers on the addition of a new rule to the existing ACL. AdminSDHolder is an object located in the System Partition in Active Directory and is used as a security template for objects that are members of certain privileged groups. Objects in these groups are enumerated and any objects with security descriptors that dont match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object Access Control List (ACL) with the security permissions set on the AdminSDHolder. An adversary who has obtained privileged access to a Windows Domain may modify the AdminSDHolder ACL to establish persistence and allow an unprivileged user to take control of a domain.
how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for the AdminSDHolder object in order to log modifications.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546"], "nist": ["DE.CM"]}
known_false_positives = Adding new users or groups to the AdminSDHolder ACL is not usual. Filter as needed
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Cross Domain SID History Addition - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic looks for changes to the sIDHistory AD attribute of user or computer objects within different domains. The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries for inter-domain privilege escalation and persistence.
how_to_implement = To successfully implement this search, you need to be ingesting eventcodes `4738` and `4742`. The Advanced Security Audit policy settings `Audit User Account Management` and  `Audit Computer Account Management` within `Account Management` all need to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.005", "T1134"], "nist": ["DE.CM"]}
known_false_positives = Domain mergers and migrations may generate large volumes of false positives for this analytic.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Domain Controller Audit Policy Disabled - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the disabling of audit policies on a domain controller. The detection is made by identifying changes made to audit policies and checks for the removal of success or failure auditing, which are common indicators of policy tampering. The detection is important because it indicates that an attacker has gained access to the domain controller and is attempting to evade detection and cover up malicious activity. The impact of such an attack can be severe, including data theft, privilege escalation, and compromise of the entire network. False positives might occur since legitimate changes to audit policies might also trigger the analytic. Upon triage, review the audit policy change event and investigate the source of the change. Additionally, you must capture and inspect any relevant on-disk artifacts and review concurrent processes to identify the attack source."
how_to_implement = Ensure you are ingesting EventCode `4719` from your domain controllers, the category domain_controller exists in assets and identities, and that assets and identities is enabled. If A&I is not configured, you will need to manually filter the results within the base search.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Domain Controller Promotion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a genuine DC promotion event. Identifying when a computer assigns itself the necessary SPNs to function as a domain controller. Note these events are triggered on the existing domain controllers, not the newly joined domain controller. This detection will serve to identify rogue DCs added to the network. There are 2x detections within this analytic story which identify DCShadow attacks, if you do not currently possess the logging for these detections, remove the where clause within this detection to identify DCShadow activity.
how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4742`. The Advanced Security Audit policy setting `Audit Computer Account Management` within `Account Management` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]}
known_false_positives = None.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Domain Replication ACL Addition - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the addition of the permissions necessary to perform a DCSync attack. In order to replicate AD objects, the initiating user or computer must have the following permissions on the domain. - DS-Replication-Get-Changes - DS-Replication-Get-Changes-All Certain Sync operations may require the additional permission of DS-Replication-Get-Changes-In-Filtered-Set. By default, adding DCSync permissions via the Powerview Add-ObjectACL operation adds all 3. This alert identifies where this trifecta has been met, and also where just the base level requirements have been met.
how_to_implement = To successfully implement this search, you need to be ingesting the eventcode 5136. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` to  `Write All Properties` applied to the domain root and all descendant objects. Once the necessary logging has been enabled, enumerate the domain policy to verify if existing accounts with access need to be whitelisted, or revoked. Assets and Identities is also leveraged to automatically translate the objectSid into username. Ensure your identities lookup is configured with the sAMAccountName and objectSid of all AD user and computer objects.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484"], "nist": ["DE.CM"]}
known_false_positives = When there is a change to nTSecurityDescriptor, Windows logs the entire ACL with the newly added components. If existing accounts are present with this permission, they will raise an alert each time the nTSecurityDescriptor is updated unless whitelisted.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD DSRM Account Changes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Aside from being used to promote genuine domain controllers, the DSRM (Directory Services Restore Mode) account can be used to persist within a Domain. A DC can be configured to allow the DSRM account to logon & be used in the same way as a local administrator account. This detection is looking for alterations to the behaviour of the account via registry.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = Disaster recovery events.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows AD DSRM Password Reset - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Aside from being used to promote genuine domain controllers, the DSRM (Directory Services Restore Mode) account can be used to persist within a Domain. A DC can be configured to allow the DSRM account to logon & be used in the same way as a local administrator account. This detection is looking for any password reset attempts against that account.
how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4794` and  have the Advanced Security Audit policy `Audit User Account Management` within `Account Management` enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = Resetting the DSRM password for legitamate reasons, i.e. forgot the password. Disaster recovery. Deploying AD backdoor deliberately.
providing_technologies = null

[savedsearch://ESCU - Windows AD Privileged Account SID History Addition - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection identifies when the SID of a privileged user is added to the SID History attribute of another user. Useful for tracking SID history abuse across multiple domains. This detection leverages the Asset and Identities framework. See the implementation section for further details on configuration.
how_to_implement = Ensure you have objectSid and the Down Level Logon Name `DOMAIN\sAMACountName` added to the identity field of your Asset and Identities lookup, along with the category of privileged for the applicable users. Ensure you are ingesting eventcodes 4742 and 4738. Two advanced audit policies `Audit User Account Management` and `Audit Computer Account Management` under `Account Management` are required to generate these event codes.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.005", "T1134"], "nist": ["DE.CM"]}
known_false_positives = Migration of privileged accounts.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Privileged Object Access Activity - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Windows Active Directory contains numerous objects that grant elevated access to the domain they reside in. These objects should be rarely accessed by normal users or processes. Access attempts to one or more of these objects may be evidence of attacker enumeration of Active Directory.
how_to_implement = Enable Audit Directory Service Access via GPO and collect event code 4662. The required SACLs need to be created for the relevant objects. Be aware Splunk filters this event by default on the Windows TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]}
known_false_positives = Service accounts or applications that routinely query Active Directory for information.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Replication Request Initiated by User Account - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This alert was written to detect activity associated with the DCSync attack. When a domain controller receives a replication request, the user account permissions are validated, however no checks are performed to validate the request was initiated by a Domain Controller. Once an attacker gains control of an account with the necessary privileges, they can request password hashes for any or all users within the domain. This alert detects when a user account creates a handle to domainDNS with the necessary replication permissions.
how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4662`. The Advanced Security Audit policy settings `Audit Directory Services Access` within `DS Access` needs to be enabled, as well as the following SACLs applied to the domain root and all descendant objects. The principals `everybody`,  `Domain Computers`, and  `Domain Controllers` auditing the permissions `Replicating Directory Changes`, `Replicating Directory Changes All`, and `Replicating Directory Changes In Filtered Set`
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.006", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Azure AD Connect syncing operations.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Replication Request Initiated from Unsanctioned Location - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This alert was written to detect activity associated with the DCSync attack performed by computer accounts. When a domain controller receives a replication request, the account permissions are validated, however no checks are performed to validate the request was initiated by a Domain Controller. Once an attacker gains control of an account with the necessary privileges, they can request password hashes for any or all users within the domain. This alert detects when a computer account account creates a handle to domainDNS with the necessary replication permissions. These requests are then filtered to exclude where the events originate from a known domain controller IP address.
how_to_implement = To successfully implement this search, you need to be ingesting eventcode `4662`. The Advanced Security Audit policy settings `Audit Directory Services Access` within `DS Access` needs to be enabled, as well as the following SACLs applied to the domain root and all descendant objects. The principals `everybody`,  `Domain Computers`, and  `Domain Controllers` auditing the permissions `Replicating Directory Changes`, `Replicating Directory Changes All`, and `Replicating Directory Changes In Filtered Set` Assets and Identities will also need to be configured, with the category of domain_controller added for domain controllers.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.006", "T1003"], "nist": ["DE.CM"]}
known_false_positives = Genuine DC promotion may trigger this alert.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Same Domain SID History Addition - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic looks for changes to the sIDHistory AD attribute of user or computer objects which exist within the same domain. The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries to stealthily grant access to a backdoor account within the same domain. This analytic was written to pick up on activity via Mimikatz sid::patch. Please note there are additional avenues to abuse SID history such as DCShadow & Golden / Diamond tickets which won't be detected using these event codes.
how_to_implement = To successfully implement this search, you need to be ingesting eventcodes `4738` and `4742`. The Advanced Security Audit policy settings `Audit User Account Management` and  `Audit Computer Account Management` within `Account Management` all need to be enabled. SID resolution is not required..
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.005", "T1134"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD ServicePrincipalName Added To Domain Account - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic identifies the addition of a Service Principal Name to a domain account. While this event may be part of a legitimate action part of certain administrative operations, it may also be evidence of a persistence attack. Domain accounts with Servce Principal Names are vulnerable to a technique called Kerberoasting that enables attackers to potentially obtain the cleartext password of the account by performing offline cracking. An adversary who has obtained privileged access to a domain environment may add an SPN to a privileged account to then leverage the Kerberoasting technique and attempt to obtain its clertext password.
how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = A Service Principal Name should only be added to an account when an application requires it. While infrequent, this detection may trigger on legitimate actions. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Short Lived Domain Account ServicePrincipalName - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the addition of a Service Principal Name to a domain account that is quickly deleted within 5 minutes or less. While this event may be part of a legitimate action part of certain administrative operations, it may also be evidence of a persistence attack. Domain accounts with Service Principal Names are vulnerable to a technique called Kerberoasting that enables attackers to potentially obtain the cleartext password of the account by performing offline cracking. An adversary who has obtained privileged access to a domain environment may add an SPN to a privileged account to then leverage the Kerberoasting technique and attempt to obtain its clertext password. To clean things up, the adversary may delete the SPN which will trigger this detection.
how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = A Service Principal Name should only be added to an account when an application requires it. Adding an SPN and quickly deleting it is less common but may be part of legitimate action. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Short Lived Domain Controller SPN Attribute - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when either a global catalog SPN or a DRS RPC SPN are temporarily added to an Active Directory computer object, both of which can be evidence of a DCShadow attack. DCShadow allows an attacker who has obtained privileged access to register a rogue Domain Controller (DC). Once registered, the rogue DC may be able to inject and replicate changes into the AD infrastructure for any domain object, including credentials and keys. This technique was initially released in 2018 by security researchers Benjamin Delpy and Vincent Le Toux. No event logs are written for changes to AD attributes, allowing for stealthy backdoors to be implanted in the domain, or metadata such as timestamps overwritten to cover tracks.
how_to_implement = To successfully implement this search, you need to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled, alongside a SACL for `everybody` to `Write All Properties` applied to the domain root and all descendant objects.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]}
known_false_positives = None.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD Short Lived Server Object - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a change in an Active Directory environment that could represent evidence of the DCShadow attack. DCShadow allows an attacker who has obtained privileged access to register a rogue Domain Controller (DC). Once registered, the rogue DC may be able to inject and replicate changes in the AD infrastructure for any domain object, including credentials and keys. This technique was initially released in 2018 by security researchers Benjamin Delpy and Vincent Le Toux. Specifically, the detection will trigger when a possible rogue Domain Controller computer object is created and quickly deleted within 30 seconds or less in an Active Directory domain. This behavior was identfied by simulating the DCShadow attack with Mimikatz.
how_to_implement = To successfully implement this search, you ned to be ingesting Event codes `5137` and `5141`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. For these event codes to be generated, specific SACLs are required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]}
known_false_positives = Creating and deleting a server object within 30 seconds or less is unusual but not impossible in a production environment. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AD SID History Attribute Modified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages event code `5136` to identify a modification of the SID History AD attribute. The SID history AD attribute allows users to inherit permissions from a separate AD account without group changes. Initially developed for access continuity when migrating user accounts to different domains, this attribute can also be abused by adversaries to stealthily grant access to a backdoor account within the same domain.
how_to_implement = To successfully implement this search, you ned to be ingesting eventcode `5136`. The Advanced Security Audit policy setting `Audit Directory Services Changes` within `DS Access` needs to be enabled. Additionally, a SACL needs to be created for AD objects in order to ingest attribute modifications.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134", "T1134.005"], "nist": ["DE.CM"]}
known_false_positives = Domain mergers and migrations may generate large volumes of false positives for this analytic.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows AdFind Exe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for the execution of `adfind.exe` with command-line arguments that it uses by default specifically the filter or search functions. It also considers the arguments necessary like objectcategory, see readme for more details: https://www.joeware.net/freetools/tools/adfind/usage.htm. AdFind.exe is a powerful tool that is commonly used for querying and retrieving information from Active Directory (AD). While it is primarily designed for AD administration and management, it has been seen used before by Wizard Spider, FIN6 and actors whom also launched SUNBURST.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = ADfind is a command-line tool for AD administration and management that is seen to be leveraged by various adversaries. Filter out legitimate administrator usage using the filter macro.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Admin Permission Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to identify suspicious file creation in the root drive (C:\). This tactic was observed in NjRAT as a means to ascertain whether its malware instance running on the compromised host possesses administrative privileges. The methodology involves an attempt to create a 'win.dat' file in the C:\ directory. If this file is successfully created, it serves as an indicator that the process indeed holds administrative privileges. This anomaly detection mechanism serves as a valuable pivot point for detecting NjRAT and other malware strains employing similar techniques to assess the privileges of their running malware instances, without using token privilege API calls or PowerShell commandlets.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may occur if there are legitimate accounts with the privilege to drop files in the root of the C drive. It's recommended to verify the legitimacy of such actions and the accounts involved.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Administrative Shares Accessed On Multiple Hosts - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event IDs 5140 or 5145 to identify a source computer accessing windows administrative shares (C$, Admin$ and IPC$ ) across a large number remote endpoints. Specifically, the logic will trigger when a source endpoint accesses administrative shares across 30 or more target computers within a 5 minute timespan. This behavior could represent an adversary who is enumerating network shares across an Active Directory environment in the search for sensitive files, a common technique leveraged by red teamers and threat actors. As environments differ across organizations, security teams should customize the thresholds of this detection as needed.
how_to_implement = To successfully implement this search, you need to be ingesting file share events. The Advanced Security Audit policy setting `Audit Detailed File Share` or `Audit File Share` within `Object Access` need to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1135"], "nist": ["DE.CM"]}
known_false_positives = An single endpoint accessing windows administrative shares across a large number of endpoints is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Admon Default Group Policy Object Modified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Splunks Admon to identify the modification of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the modification of the default GPOs.
how_to_implement = To successfully implement this search, you need to be monitoring Active Directory logs using Admon. Details can be found here https://docs.splunk.com/Documentation/SplunkCloud/8.1.2101/Data/MonitorActiveDirectory
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]}
known_false_positives = The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Admon Group Policy Object Created - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Splunks Admon to identify the creation of a new Group Policy Object. With GPOs, system administrators can manage and configure applications, software operations, and user settings throughout an entire organization. GPOs can be abused and leveraged by adversaries to escalate privileges or deploy malware across an Active Directory network. As an example, the Lockbit ransomware malware will create new group policies on the domain controller that are then pushed out to every device on the network. Security teams should monitor the creation of new Group Policy Objects.
how_to_implement = To successfully implement this search, you need to be monitoring Active Directory logs using Admon. Details can be found here https://docs.splunk.com/Documentation/SplunkCloud/8.1.2101/Data/MonitorActiveDirectory
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]}
known_false_positives = Group Policy Objects are created as part of regular administrative operations, filter as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Alternate DataStream - Base64 Content - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic leverages Sysmon Event ID 15, a critical file creation event, to detect the creation of Alternate Data Streams (ADS) on Windows systems. ADS is a feature of the NTFS file system that allows the storage of data in hidden streams attached to files. These streams are not visible in standard file listings, making them a popular technique for concealing malicious activity. Event ID 15 captures both the hash of the primary file content (unnamed stream) and the content of any additional named streams, which can include executables, scripts, or configuration data. Malware often exploits ADS to hide payloads, leveraging browser downloads to attach a Zone.Identifier stream, marking the file as originating from the Internet (Mark Of The Web, MOTW). This analytic is designed to identify such misuse by analyzing the content and creation patterns of named streams, including those under 1KB which may contain MOTW information. It is essential for detecting sophisticated threats that utilize non-executable file types or conceal malicious scripts within ADS, beyond the traditional focus on PE executables. The detection process involves monitoring for the creation of named streams, which are part of the NTFS structure and can be examined using tools like PowerShell for the presence of additional data streams or MOTW information. This approach helps in uncovering hidden payloads and tracking the origin of suspicious files downloaded via browsers or email clients, providing a comprehensive defense against ADS abuse.
how_to_implement = Target environment must ingest sysmon data, specifically Event ID 15.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564", "T1564.004"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Alternate DataStream - Executable Content - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to detect when data, possessing an IMPHASH value, is written to an Alternate Data Stream (ADS) in the NTFS file system. The presence of an IMPHASH value suggests that the written data has a Portable Executable (PE) structure, indicating its potential to be executed. Such behavior could be a sign of a threat actor staging malicious code within hard-to-detect areas of the file system for future use or persistence. It's important to note that for this analytic to function correctly, import hashing/imphash must be enabled within Sysmon. This allows the capture of the IMPHASH value, a unique identifier for the imported functions of a PE, providing a robust mechanism for detecting hidden malicious activity leveraging ADS.
how_to_implement = Target environment must ingest Sysmon data, specifically Event ID 15, and import hashing/imphash must be enabled within Sysmon.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564", "T1564.004"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Alternate DataStream - Process Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This following analytic detects when a process attempts to execute a file from within an NTFS file system alternate data stream. This behavior could indicate that a threat actor staged malicious code within a difficult to detect area of the file system and is now attempting to execute it.
how_to_implement = Target environment must ingest process execution data sources such as Windows process monitoring and/or Sysmon Event ID 1.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564", "T1564.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated by process executions within the commandline, regex has been provided to minimize the possibilty.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Apache Benchmark Binary - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a default behavior of a MetaSploit payload. MetaSploit uses Apache Benchmark to generate payloads. The payloads contain standard artifacts including "Apache Benchmark" and the original file name is always ab.exe. During triage, review the process and it's path. It is possible network connections spawned from it. Review parallel processes for further behaviors.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited as there is a small subset of binaries that contain the original file name of ab.exe. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows App Layer Protocol Qakbot NamedPipe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious process creating or connecting to a possible Qakbot named pipe . This technique was seen in Qakbot malware that creates named pipe after injecting its code in legitimate process to communicate on other process that also has an injected code to steal information on the compromised host. This Anomaly detection can be a good pivot for possible Qakbot infection. This detection looks for possible random generated named pipe (in GUID form) created by known process being abused by Qakbot.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, pipename, processguid and named pipe event type from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows App Layer Protocol Wermgr Connect To NamedPipe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious wermgr.exe process creating or connecting to a named pipe. Wermgr.exe is part of Windows OS Problem reporting application responsible for reporting problems, fault or error happen on the Windows OS. This file is being abused by several Threat actors and malware such as Trickbot and Qakbot to execute their malicious code. This anomaly detection can be a good pivot on possible wermgr.exe processes having injected malicious code that might be related to qakbot infection that communicates via named pipe.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, pipename, processguid and named pipe event type from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Application Layer Protocol RMS Radmin Tool Namedpipe - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of default or publicly known named pipes used by RMX remote admin tool. A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. RMX Tool uses named pipes in many way as part of its communication for its server and client component. This tool was abuse by several adversaries and malware like Azorult to collect data to the targeted host. This TTP is a good indicator that this tool was install in production premise and need to check if the user has a valid reason why it need to install this legitimate application.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present. Filter based on pipe name or process.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows AppLocker Block Events - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows AppLocker event logs to generate risk based on blocks related to AppLocker policy violations. The analytic is designed to identify attempts to bypass application restrictions.
how_to_implement = To implement this analytic, you must be ingesting Windows AppLocker logs into Splunk. Ensure proper logging is setup for AppLocker and data is being ingested into Splunk.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.AE"]}
known_false_positives = Administrators may legitimately use AppLocker to allow applications.
providing_technologies = null

[savedsearch://ESCU - Windows AppLocker Execution from Uncommon Locations - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify executions of applications or scripts from uncommon or suspicious file paths, which could be indicative of malware or unauthorized activity. By leveraging a simple statistical model, the query analyzes the frequency of application executions across different file paths. It calculates the average (avg) number of executions per file path and uses the standard deviation (stdev) to measure the variation or dispersion of the execution counts from the average. A file path is considered uncommon or suspicious if the number of executions from it is significantly higher than what is expected based on the calculated average and standard deviation. Specifically, the analytic flags any file path from which the number of executions exceeds the upper bound, defined as the average plus two times the standard deviation (avg+stdev*2). This approach helps in pinpointing anomalies in application execution patterns, potentially uncovering malicious activities or policy violations.
how_to_implement = The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk. Note that, an additional method to reduce any false positives would be to add the specific EventCodes - 8003 or 8004 and filter from there. Upon tuning, modify to Anomaly or TTP.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.AE"]}
known_false_positives = False positives are possible if legitimate users are executing applications from file paths that are not permitted by AppLocker. It is recommended to investigate the context of the application execution to determine if it is malicious or not. Modify the threshold as needed to reduce false positives.
providing_technologies = null

[savedsearch://ESCU - Windows AppLocker Privilege Escalation via Unauthorized Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows AppLocker event logs to identify attempts to bypass application restrictions. AppLocker is a feature that allows administrators to specify which applications are permitted to run on a system. This analytic is designed to identify attempts to bypass these restrictions, which could be indicative of an attacker attempting to escalate privileges. The analytic uses EventCodes 8007, 8004, 8022, 8025, 8029, and 8040 to identify these attempts. The analytic will identify the host, full file path, and target user associated with the bypass attempt. These EventCodes are related to block events and focus on 5 attempts or more.
how_to_implement = The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible if legitimate users are attempting to bypass application restrictions. This could occur if a user is attempting to run an application that is not permitted by AppLocker. It is recommended to investigate the context of the bypass attempt to determine if it is malicious or not. Modify the threshold as needed to reduce false positives.
providing_technologies = null

[savedsearch://ESCU - Windows AppLocker Rare Application Launch Detection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to detect the launch of applications that occur rarely within the environment, which could indicate the use of potentially malicious software or tools by attackers. It works by aggregating the count of application launches over time, then calculating the average and standard deviation of these counts. Applications whose launch counts significantly deviate from the norm, either by exceeding or falling below three standard deviations from the average, are flagged for further investigation. This approach helps in identifying unusual application activity that could be indicative of a security threat.
how_to_implement = The analytic is designed to be run against Windows AppLocker event logs collected from endpoints with AppLocker enabled. If using Microsoft Defender for Endpoint (MDE), modify the analytic to use EventTypes/ActionTypes that match the block events for AppLocker. The analytic requires the AppLocker event logs to be ingested into Splunk. Note that, an additional method to reduce any false positives would be to add the specific EventCodes - 8003 or 8004 and filter from there.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.AE"]}
known_false_positives = False positives are possible if legitimate users are launching applications that are not permitted by AppLocker. It is recommended to investigate the context of the application launch to determine if it is malicious or not. Modify the threshold as needed to reduce false positives.
providing_technologies = null

[savedsearch://ESCU - Windows Archive Collected Data via Powershell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script that archive files to a temp folder. This anomaly detection serves as a valuable indicator to uncover threats from adversaries utilizing PowerShell scripts for data archiving purposes. Identifying this method becomes pivotal in flagging and investigating potential threats, enabling proactive measures threat actors leveraging similar PowerShell-based data collection and archiving techniques.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560"], "nist": ["DE.AE"]}
known_false_positives = powershell may used this function to archive data.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Archive Collected Data via Rar - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execute a rar utilities to archive files. This method has been exploited by various threat actors, including red-teamers and malware like DarkGate, to gather and compress collected data on compromised hosts. Subsequently, these archives are transmitted to command and control servers as part of their data exfiltration techniques. These adversaries leverage RAR archiving to consolidate and compress collected data on compromised hosts. Once the data is compiled into these archives, it serves as a means for these entities to effectively exfiltrate sensitive information. This process involves transferring the archived data to command and control servers, facilitating the extraction and retrieval of critical information from compromised systems.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1560.001", "T1560"], "nist": ["DE.AE"]}
known_false_positives = user and network administrator can execute this command.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows AutoIt3 Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect any execution of AutoIt3, a scripting language designed for automating the Windows GUI and general scripting. This includes instances where AutoIt3 has been renamed or otherwise altered in an attempt to evade detection. The analytic works by searching for process names or original file names that match 'autoit3.exe', which is the default executable for AutoIt scripts. This detection is important as AutoIt3 is often used by attackers to automate malicious activities, such as the execution of malware or other unwanted software. False positives may occur with legitimate uses of AutoIt3.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if the application is legitimately used, filter by user or endpoint as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Autostart Execution LSASS Driver Registry Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the abuse of two undocumented registry keys that allow for a DLL to load into lsass.exe to potentially capture credentials. Upon successful modification of \CurrentControlSet\Services\NTDS\DirectoryServiceExtPt or \CurrentControlSet\Services\NTDS\LsaDbExtPt, a DLL either remote or local will be set as the value and load up into lsass.exe. Based on POC code a text file may be written to disk with credentials.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.008"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present on recent Windows Operating Systems. Filtering may be required based on process_name. In addition, look for non-standard, unsigned, module loads into LSASS. If query is too noisy, modify by adding Endpoint.processes process_name to query to identify the process making the modification.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Binary Proxy Execution Mavinject DLL Injection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Adversaries may abuse mavinject.exe to inject malicious DLLs into running processes (i.e. Dynamic-link Library Injection), allowing for arbitrary code execution (ex. C:\Windows\system32\mavinject.exe PID /INJECTRUNNING PATH_DLL). In addition to Dynamic-link Library Injection, Mavinject.exe can also be abused to perform import descriptor injection via its /HMODULE command-line parameter (ex. mavinject.exe PID /HMODULE=BASE_ADDRESS PATH_DLL ORDINAL_NUMBER). This command would inject an import table entry consisting of the specified DLL into the module at the given base address. During triage, review file modifcations and parallel processes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.013", "T1218"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter on DLL name or parent process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Boot or Logon Autostart Execution In Startup Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious files dropped or created in the Windows %startup% folder. This technique is a common way to gain persistence on a targeted host. Threat actor, adversaries and red teamer abuse this folder path to automatically execute their malicious sample upon boot or restart of the infected host. This TTP detection is a good indicator that a suspicious process wants to gain persistence on the targeted host. We suggest to verify the process name by using the process guid field, the file created and also the user and the computer name for further investigation.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.001", "T1547"], "nist": ["DE.AE"]}
known_false_positives = Administrators may allow creation of script or exe in this path.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows BootLoader Inventory - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting query utilizes a PowerShell Scripted input that captures the bootloader paths for each Windows endpoint it is deployed to. The template inputs.conf is located in the references link. By default, it only captures the path, but may be modified to capture everything that BCDedit provides. It can be verbose, but may be worth it.
how_to_implement = To implement this analytic, a new stanza will need to be added to a inputs.conf and deployed to all or some Windows endpoints. https://gist.github.com/MHaggis/26518cd2844b0e03de6126660bb45707 provides the stanza. If modifying the sourcetype, be sure to update the Macro for this analytic. Recommend running it daily, or weekly, depending on threat model.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542.001", "T1542"], "nist": ["DE.AE"]}
known_false_positives = No false positives here, only bootloaders. Filter as needed or create a lookup as a baseline.
providing_technologies = null

[savedsearch://ESCU - Windows Bypass UAC via Pkgmgr Tool - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a potentially suspicious execution of the 'pkgmgr' process involving the use of an XML input file for package management. The 'pkgmgr' process, though deprecated in modern Windows systems, was historically used for managing packages. The presence of an XML input file raises concerns about the nature of the executed command and its potential impact on the system. Due to the deprecated status of 'pkgmgr' and the involvement of an XML file, this activity warrants careful investigation. XML files are commonly used for configuration and data exchange, making it crucial to ascertain the intentions and legitimacy of the command. To ensure system security, it is recommended to use up-to-date package management utilities, such as DISM or PowerShell's PackageManagement module, and exercise caution when executing commands involving potentially sensitive operations or files.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present on recent Windows Operating Systems. Filtering may be required based on process_name. In addition, look for non-standard, unsigned, module loads into LSASS. If query is too noisy, modify by adding Endpoint.processes process_name to query to identify the process making the modification.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows CAB File on Disk - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies .cab files being written to disk. Utilize this analytic as a way to hunt for suspect .cab files being written to non-standard paths and tune as needed. Cab files were recently being utilized to deliver .url files embedded. The .url files were then used to deliver malicious payloads. The search specifically looks for instances where the file name is '*.cab' and the action is 'write'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001"], "nist": ["DE.AE"]}
known_false_positives = False positives will only be present if a process legitimately writes a .cab file to disk. Modify the analytic as needed by file path. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Cached Domain Credentials Reg Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line related to the discovery of cache domain credential logon count in the registry. This Technique was being abused by several post exploitation tool like Winpeas where it query CachedLogonsCount registry value in Winlogon registry. This value can be good information about the login caching setting on the Windows OS target host. A value of 0 means login caching is disable and values > 50 caches only 50 login attempts. By default all versions of Windows 10 save cached logins except Windows Server 2008.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.005", "T1003"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Change Default File Association For No File Ext - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect suspicious process commandline to change or set the default file association of a file without file extension with notepad.exe. This technique was seen in some APT and ransomware Prestige where it set/modify the default process to run file association, like .txt to notepad.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.001", "T1546"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows ClipBoard Data via Get-ClipBoard - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a powershell script command to retrieve clipboard data. This technique was seen in several post exploitation tools like WINPEAS to steal sensitive information that was saved in clipboard. Using the Get-Clipboard powershell commandlet, adversaries can be able collect data stored in clipboard that might be a copied user name, password or other sensitive information.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1115"], "nist": ["DE.AE"]}
known_false_positives = It is possible there will be false positives, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows COM Hijacking InprocServer32 Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of reg.exe performing an add to the InProcServer32, which may be related to COM hijacking. Adversaries can use the COM system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence. Hijacking a COM object requires a change in the Registry to replace a reference to a legitimate system component which may cause that component to not work when executed. When that system component is executed through normal system operation the adversary's code will be executed instead.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.015", "T1546"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and some filtering may be required.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Command and Scripting Interpreter Hunting Path Traversal - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies path traversal command-line execution and should be used to tune and driver other more higher fidelity analytics. This technique was seen in malicious document that execute malicious code using msdt.exe and path traversal technique that serve as defense evasion. This Hunting query is a good pivot to look for possible suspicious process and command-line that runs execute path traversal technique to run malicious code. This may help you to find possible downloaded malware or other lolbin execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = false positive may vary depends on the score you want to check. The bigger number of path traversal string count the better.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Command and Scripting Interpreter Path Traversal Exec - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies path traversal command-line execution. This technique was seen in malicious document that execute malicious code using msdt.exe and path traversal technique that serve as defense evasion. This TTP is a good pivot to look for more suspicious process and command-line that runs before and after this execution. This may help you to find possible downloaded malware or other lolbin execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]}
known_false_positives = Not known at this moment.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Command Shell DCRat ForkBomb Payload - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies DCRat "forkbomb" payload feature. This technique was seen in dark crystal RAT backdoor capabilities where it will execute several cmd child process executing "notepad.exe & pause". The following analytic detects the multiple cmd.exe and child process notepad.exe  execution using batch script in the targeted host within 30s timeframe. this TTP can be a good pivot to check DCRat infection.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.003", "T1059"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Command Shell Fetch Env Variables - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious process command line fetching the environment variables with a non-shell parent process. This technique was seen in qakbot malware where it fetches the environment variable in the target or compromised host. This TTP detection is a good pivot of possible malicious behavior since the command line is executed by a common non-shell process like cmd.exe , powershell.exe and many more. This can also be a good sign that the parent process has a malicious code injected to it to execute this command.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = shell process that are not included in this search may cause False positive. Filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following correlation identifies instances where four or more distinct detection analytics are associated with malicious command line behavior that is known to be exploited by multiple threat actors, adversaries, or red teamers on a specific host. By leveraging the Command Line Interface (CLI), attackers can execute malicious commands, gain access to sensitive data, install backdoors, and engage in various nefarious activities. The impact of such compromise can be severe, as attackers may gain unauthorized control over the compromised system, enabling them to exfiltrate valuable information, escalate privileges, or launch further attacks within the network. If this detection is triggered, there is a high level of confidence in the occurrence of suspicious command line activities on the host.
how_to_implement = Splunk Enterprise Security is required to utilize this correlation. In addition, modify the source_count value to your environment. In our testing, a count of 4 or 5 was decent in a lab, but the number may need to be increased base on internal testing. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Actions on Objectives", "Installation"], "mitre_attack": ["T1222", "T1049", "T1033", "T1529", "T1016", "T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers.
providing_technologies = null

[savedsearch://ESCU - Windows Computer Account Created by Computer Account - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifes a Computer Account creating a new Computer Account with specific a Service Principle Name - "RestrictedKrbHost". The RestrictedKrbHost service class allows client applications to use Kerberos authentication when they do not have the identity of the service but have the server name.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4741 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]}
known_false_positives = It is possible third party applications may have a computer account that adds computer accounts, filtering may be required.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Computer Account Requesting Kerberos Ticket - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a ComputerAccount requesting a Kerberos Ticket. typically, a user account requests a Kerberos ticket. This behavior was identified with KrbUpRelay, but additional Kerberos attacks have exhibited similar behavior.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4768 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]}
known_false_positives = It is possible false positives will be present based on third party applications. Filtering may be needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Computer Account With SPN - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies two SPNs, HOST and RestrictedKrbHost, added using the KrbRelayUp behavior. This particular behavior has been found in other Kerberos based attacks.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4741 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]}
known_false_positives = It is possible third party applications may add these SPNs to Computer Accounts, filtering may be needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows ConHost with Headless Argument - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic detects the unusual use of the Windows Console Host process (conhost.exe) with the undocumented --headless parameter to spawn a new process. This behavior is highly unusual and indicative of suspicious activity, as the --headless parameter is not commonly used in legitimate operations. The analytic identifies this behavior by looking for instances where conhost.exe is invoked with the --headless argument. This behavior is worth identifying for a Security Operations Center (SOC) as it could indicate an attacker's attempt to execute commands or scripts in a stealthy manner, potentially to establish persistence, perform lateral movement, or carry out other malicious activities. If a true positive is identified, it suggests that an attacker has gained a foothold in the environment and is attempting to further their attack, which could lead to serious consequences such as data exfiltration, system compromise, or deployment of ransomware. Potential false positives could arise from legitimate administrative activity, hence it is important to validate the context of the detected behavior during triage.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1564.003", "T1564.006"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if the application is legitimately used, filter by user or endpoint as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Create Local Account - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a new local user account added to a computer. Note that, this should be restricted to critical assets.
how_to_implement = This search requires you to have enabled your Group Management Audit Logs in your Local Windows Security Policy and be ingesting those logs.  More information on how to enable them can be found here: http://whatevernetworks.com/auditing-group-membership-changes-in-active-directory/
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1136.001", "T1136"], "nist": ["DE.AE"]}
known_false_positives = It is possible that an administrator created the account. Verifying activity with an administrator is advised. This analytic is set to anomaly to allow for risk to be added. Filter and tune as needed. Restrict to critical infrastructure to reduce any volume.
providing_technologies = null

[savedsearch://ESCU - Windows Credential Access From Browser Password Store - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a possible non-common browser process accessing its browser user data profile. This tactic/technique has been observed in various Trojan Stealers, such as SnakeKeylogger, which attempt to gather sensitive browser information and credentials as part of their exfiltration strategy. Detecting this anomaly can serve as a valuable pivot for identifying processes that access lists of browser user data profiles unexpectedly. This detection uses a lookup file `browser_app_list` that maintains a list of well known browser applications and the browser paths that are allowed to access the browser user data profiles.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure." This search may trigger on a browser application that is not included in the browser_app_list lookup file.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = The lookup file `browser_app_list` may not contain all the browser applications that are allowed to access the browser user data profiles. Consider updating the lookup files to add allowed object paths for the browser applications that are not included in the lookup file.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Credential Dumping LSASS Memory Createdump - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of CreateDump.exe being used to perform a process dump. This particular binary is not native to Windows, but is found to be brought in my many different third party applications including PowerShell 7.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if an application is dumping processes, filter as needed. Recommend reviewing createdump.exe usage across the fleet to better understand all usage and by what.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic focuses on identifying non-chrome processes that attempt to access the Chrome extensions file. This file contains crucial settings and information related to the browser's extensions installed on the computer. Adversaries and malware authors have been known to exploit this file to extract sensitive information from the Chrome browser on targeted hosts. Detecting such anomalous behavior provides valuable insights for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for access to the Chrome extensions file by non-chrome processes, we can enhance our ability to detect potential threats and protect sensitive information stored within the browser.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = Uninstall chrome browser extension application may access this file and folder path to removed chrome installation in the target host. Filter is needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to detect non-chrome processes accessing the Chrome user data file called "local state." This file contains important settings and information related to the browser's operations on the computer. Threat actors, adversaries, and malware authors have been known to exploit this file in attempts to extract the encrypted master key used for decrypting passwords saved in the Chrome browser. Detecting access to the "local state" file by non-chrome processes serves as a valuable pivot for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for this anomaly, we can improve our ability to identify potential threats and safeguard sensitive information stored within the browser.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = Uninstall chrome application may access this file and folder path to removed chrome installation in target host. Filter is needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify non-chrome processes accessing the Chrome user data file called "login data." This SQLite database file contains important information related to the browser's operations on the computer. Threat actors, adversaries, and malware authors have been known to exploit this file in attempts to extract and decrypt passwords saved in the Chrome browser. Detecting access to the "login data" file by non-chrome processes serves as a valuable pivot for analyzing suspicious processes beyond the commonly observed chrome.exe and explorer.exe executables. By monitoring for this anomaly, we can enhance our ability to detect potential threats and protect sensitive information stored within the browser.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = Uninstall application may access this registry to remove the entry of the target application. filter is needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Credentials from Password Stores Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS cmdkey.exe tool. This tool is being abused or used by several post exploitation tool and malware such as Darkgate malware to create stored user names, passwords or credentials in the targeted Windows OS host. This information can be used by the attacker to gain privilege escalation and persistence in the targeted hosts for further attacks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555"], "nist": ["DE.CM"]}
known_false_positives = network administrator can use this tool for auditing process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Credentials from Password Stores Deletion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS cmdkey.exe tool. This tool is being abused or used by several post exploitation tool and malware such as Darkgate malware to delete stored user names, passwords or credentials in the targeted Windows OS host. This information can be used by the attacker to gain privilege escalation and persistence in the targeted hosts for further attacks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555"], "nist": ["DE.CM"]}
known_false_positives = network administrator can use this tool for auditing process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Credentials from Password Stores Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS cmdkey.exe tool. This tool is being abused or used by several post exploitation tool such as winpeas that being used by ransomware prestige to list stored user names, passwords or credentials in the targeted Windows OS host. This information can be used by the attacker to gain privilege escalation and persistence in the targeted hosts for further attacks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555"], "nist": ["DE.AE"]}
known_false_positives = network administrator can use this tool for auditing process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Credentials in Registry Reg Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line related to the discovery of possible password or credentials in the registry. This technique is being abused by adversaries or post exploitation tools like winpeas to steal credentials in the registry in the targeted host. Registry can contain several sensitive information like username and credentials that can be used for privilege escalation, persistence or even in lateral movement. This Anomaly detection can be a good pivot to detect a suspicious process querying a registry related to password or private keys.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.002", "T1552"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Curl Download to Suspicious Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Windows Curl.exe downloading a file to a suspicious location. \
-O or --output is used when a file is to be downloaded and placed in a specified location. \
During triage, review parallel processes for further behavior. In addition, identify if the download was successful. If a file was downloaded, capture and analyze.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = It is possible Administrators or super users will use Curl for legitimate purposes. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Curl Upload to Remote Destination - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Windows Curl.exe uploading a file to a remote destination. \
`-T` or `--upload-file` is used when a file is to be uploaded to a remotge destination. \
`-d` or `--data` POST is the HTTP method that was invented to send data to a receiving web application, and it is, for example, how most common HTML forms on the web work. \
HTTP multipart formposts are done with `-F`, but this appears to not be compatible with the Windows version of Curl. Will update if identified adversary tradecraft. \
Adversaries may use one of the three methods based on the remote destination and what they are attempting to upload (zip vs txt). During triage, review parallel processes for further behavior. In addition, identify if the upload was successful in network logs. If a file was uploaded, isolate the endpoint and review.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = False positives may be limited to source control applications and may be required to be filtered out.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Data Destruction Recursive Exec Files Deletion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a suspicious process that is recursively deleting files on a compromised host. This behavior has been observed in several types of destructive malware, such as CaddyWiper, DoubleZero, and SwiftSlicer, which delete or overwrite files with randomly generated strings to make recovery impossible. Additionally, this analytic can detect potential recursive file writes across multiple files using Sysmon Event 23 or 26. Sysmon considers a file as deleted as soon as it is overwritten. This analytic serves as a strong indicator of potential destructive malware activity on a host machine or the uninstallation of a large software application.
how_to_implement = To successfully implement this search, you need to ingest logs that include the process name, TargetFilename, and ProcessID executions from your endpoints. If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = The uninstallation of a large software application or the use of cleanmgr.exe may trigger this detection. A filter is necessary to reduce false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Defacement Modify Transcodedwallpaper File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification to the Transcodedwallpaper file in the wallpaper theme directory to change the wallpaper of the host machine. This technique was seen in adversaries attempting to deface or change the desktop wallpaper of the targeted host. During our testing, the common process that affects or changes the wallpaper if a user changes it via desktop personalized setting is explorer.exe.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1491"], "nist": ["DE.AE"]}
known_false_positives = 3rd part software application can change the wallpaper. Filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Default Group Policy Object Modified - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 5136 to identify the modification of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the modification of the default GPOs.
how_to_implement = To successfully implement this search, the Advanced Security Audit policy setting `Audit Directory Service Changes` within `DS Access` needs to be enabled. Furthermore, the appropriate system access control lists (SACL) need to be created as the used events are not logged by default. A good guide to accomplish this can be found here https://jgspiers.com/audit-group-policy-changes/.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]}
known_false_positives = The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Default Group Policy Object Modified with GPME - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages the Endpoint datamodel to identify the potential edition of a default Group Policy Object. A fresh installation of an Active Directory network will typically contain two default group policy objects `Default Domain Controllers Policy` and `Default Domain Policy`. The default domain controllers policy is used to enforce and set policies to all the domain controllers within the domain environment. The default domain policy is linked to all users and computers by default. An adversary who has obtained privileged access to an Active Directory network may modify the default group policy objects to obtain further access, deploy persistence or execute malware across a large number of hosts. Security teams should monitor the edition of the default GPOs.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1484", "T1484.001"], "nist": ["DE.CM"]}
known_false_positives = The default Group Policy Objects within an AD network may be legitimately updated for administrative operations, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Defender ASR Audit Events - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This detection searches for Windows Defender ASR audit events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR audit events that are generated when a process or application attempts to perform an action that would be blocked by an ASR rule, but is allowed to proceed for auditing purposes.
how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. Note that Audit and block Event IDs have different fields, therefore the analytic will need to be modified for each type of event.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1059", "T1566.001", "T1566.002"], "nist": ["DE.AE"]}
known_false_positives = False positives are expected from legitimate applications generating events that are similar to those generated by malicious activity. For example, Event ID 1122 is generated when a process attempts to load a DLL that is blocked by an ASR rule. This can be triggered by legitimate applications that attempt to load DLLs that are not blocked by ASR rules. This is audit only.
providing_technologies = ["Microsoft Defender"]

[savedsearch://ESCU - Windows Defender ASR Block Events - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This detection searches for Windows Defender ASR block events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR block events that are generated when a process or application attempts to perform an action that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned.
how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. Note that Audit and block Event IDs have different fields, therefore the analytic will need to be modified for each type of event.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1059", "T1566.001", "T1566.002"], "nist": ["DE.AE"]}
known_false_positives = False positives are expected from legitimate applications generating events that are similar to those generated by malicious activity. For example, Event ID 1122 is generated when a process attempts to load a DLL that is blocked by an ASR rule. This can be triggered by legitimate applications that attempt to load DLLs that are not blocked by ASR rules. This is block only.
providing_technologies = ["Microsoft Defender"]

[savedsearch://ESCU - Windows Defender ASR Registry Modification - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This detection searches for Windows Defender ASR registry modification events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR registry modification events that are generated when a process or application attempts to modify a registry key that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned.
how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = False positives are expected from legitimate applications generating events that are similar to those generated by malicious activity. For example, Event ID 5007 is generated when a process attempts to modify a registry key that is related to ASR rules. This can be triggered by legitimate applications that attempt to modify registry keys that are not blocked by ASR rules.
providing_technologies = ["Microsoft Defender"]

[savedsearch://ESCU - Windows Defender ASR Rule Disabled - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic identifies when a Windows Defender ASR rule disabled events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR rule disabled events that are generated when an ASR rule is disabled.
how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = False positives may occur if applications are typically disabling ASR rules in the environment. Monitor for changes to ASR rules to determine if this is a false positive.
providing_technologies = ["Microsoft Defender"]

[savedsearch://ESCU - Windows Defender ASR Rules Stacking - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This hunting analytic targets a range of security events from Microsoft Defender, focusing on the Exploit Guard and Attack Surface Reduction (ASR) features. It monitors specific Event IDs - Event IDs 1121 and 1126 indicate active blocking of unauthorized operations or dangerous network connections, whereas Event IDs 1122 and 1125 represent audit logs for similar activities. Event ID 1129 shows user overrides on blocked operations. For ASR-related activities, Event IDs 1131 and 1133 signal blocked operations, while 1132 and 1134 are audit logs. Event ID 5007 alerts on configuration changes, possibly indicating security breaches. \
Additionally, the analytic utilizes a lookup to correlate ASR rule GUIDs with their descriptive names, enhancing understanding of the context behind these security alerts. This includes rules for blocking vulnerable drivers, restricting actions of Adobe Reader and Office applications, and protecting against various malware and unauthorized system changes. This comprehensive approach aids in assessing policy enforcement and potential security risks.
how_to_implement = The following analytic requires collection of Windows Defender Operational logs in either XML or multi-line. To collect, setup a new input for the Windows Defender Operational logs. In addition, it does require a lookup that maps the ID to ASR Rule name. Note that Audit and block Event IDs have different fields, therefore the analytic will need to be modified for each type of event. The analytic can be modified to look for specific ASR rules, or to look for specific Event IDs. EventID 5007 is a change in the registry, and may be a false positive. This can be removed from the search if desired.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1566.001", "T1566.002", "T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives are not expected with this analytic, since it is a hunting analytic. It is meant to show the use of ASR rules and how they can be used to detect malicious activity.
providing_technologies = ["Microsoft Defender"]

[savedsearch://ESCU - Windows Defender Exclusion Registry Entry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will detect a suspicious process that modify a registry related to windows defender exclusion feature. This registry is abused by adversaries, malware author and red teams to bypassed Windows Defender Anti-Virus product by excluding folder path, file path, process, extensions and etc. from its real time or schedule scan to execute their malicious code. This is a good indicator for a defense evasion and to look further for events after this behavior.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = admin or user may choose to use this windows features.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Delete or Modify System Firewall - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies potentially malicious 'netsh' processes that manipulate firewall configurations. This behavior has been observed in the NJRAT malware, which deletes its added firewall rules as part of its cleanup process. Leveraging this anomaly detection can be a valuable approach for detecting malware, such as NJRAT, that makes alterations to firewall configurations as a component of its malicious activities.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.004"], "nist": ["DE.AE"]}
known_false_positives = Administrator may modify or delete firewall configuration.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Deleted Registry By A Non Critical Process File Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect deletion of registry with suspicious process file path. This technique was seen in Double Zero wiper malware where it will delete all the subkey in HKLM, HKCU and HKU registry hive as part of its destructive payload to the targeted hosts. This anomaly detections can catch possible malware or advesaries deleting registry as part of defense evasion or even payload impact but can also catch for third party application updates or installation. In this scenario false positive filter is needed.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = This detection can catch for third party application updates or installation. In this scenario false positive filter is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Change Password Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to disable change password feature of the windows host. This registry modification may disables the Change Password button on the Windows Security dialog box (which appears when you press Ctrl+Alt+Del). As a result, users cannot change their Windows password on demand. This technique was seen in some malware family like ransomware to prevent the user to change the password after ownning the network or a system during attack. This windows feature may implemented by administrator to prevent normal user to change the password of a critical host or server, In this type of scenario filter is needed to minimized false positive.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = This windows feature may implemented by administrator to prevent normal user to change the password of a critical host or server, In this type of scenario filter is needed to minimized false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Lock Workstation Feature Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to disable Lock Computer windows features. This registry modification prevent the user from locking its screen or computer that are being abused by several malware for example ransomware. This technique was used by threat actor to make its payload more impactful to the compromised host.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable LogOff Button Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to disable logoff feature in windows host. This registry when enable will prevent users to log off of the system by using any method, including programs run from the command line, such as scripts. It also disables or removes all menu items and buttons that log the user off of the system. This technique was seen abused by ransomware malware to make the compromised host un-useful and hard to remove other registry modification made on the machine that needs restart to take effect. This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Memory Crash Dump - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process that is attempting to disable the ability on Windows to generate a memory crash dump. This was recently identified being utilized by HermeticWiper. To disable crash dumps, the value must be set to 0. This feature is typically modified to perform a memory crash dump when a computer stops unexpectedly because of a Stop error (also known as a blue screen, system crash, or bug check).
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` and `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Notification Center - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following search identifies a modification of registry to disable the windows notification center feature in a windows host machine. This registry modification removes notification and action center from the notification area on the task bar. This modification are seen in RAT malware to cover their tracks upon downloading other of its component or other payload.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = admin or user may choose to disable this windows features.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable or Modify Tools Via Taskkill - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify potentially malicious processes that terminate other processes using taskkill.exe. This technique has been observed in various malware instances, employed by adversaries and red teamers alike, to forcibly terminate other processes whether they be security products or other legitimate applications as part of their malicious activities. Detecting this anomaly serves as a valuable alert mechanism to identify suspicious processes or malware attempting to evade detection and disrupt system stability.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562", "T1562.001"], "nist": ["DE.AE"]}
known_false_positives = Network administrator can use this application to kill process during audit or investigation.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Shutdown Button Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to disable shutdown button on the logon user. This technique was seen in several malware especially in ransomware family like killdisk malware variant to make the compromised host un-useful and hard to remove other registry modification made on the machine that needs restart to take effect. This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = This windows feature may implement by administrator in some server where shutdown is critical. In that scenario filter of machine and users that can modify this registry is needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Windows Event Logging Disable HTTP Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies AppCmd.exe being utilized to disable HTTP logging on IIS. Adversaries may perform this action to disable logging and delete the logs so remove any trace or events on disk.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1562.002", "T1562", "T1505", "T1505.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present only if scripts or Administrators are disabling logging. Filter as needed by parent process or other.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Disable Windows Group Policy Features Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to disable windows features. These techniques are seen in several ransomware malware to impair the compromised host to make it hard for analyst to mitigate or response from the attack. Disabling these known features make the analysis and forensic response more hard. Disabling these feature is not so common but can still be implemented by the administrator for security purposes. In this scenario filters for users that are allowed doing this is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Disabling these features for legitimate purposes is not a common use case but can still be implemented by the administrators. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DisableAntiSpyware Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for the Registry Key DisableAntiSpyware set to disable. This is consistent with Ryuk infections across a fleet of endpoints. This particular behavior is typically executed when an ransomware actor gains access to an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications. Endpoint should be isolated.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DiskCryptor Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies DiskCryptor  process name of dcrypt.exe or internal name dcinst.exe. This utility has been utilized by adversaries to encrypt disks manually during an operation. In addition, during install, a dcrypt.sys driver is installed and requires a reboot in order to take effect. There are no command-line arguments used.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1486"], "nist": ["DE.AE"]}
known_false_positives = It is possible false positives may be present based on the internal name dcinst.exe, filter as needed. It may be worthy to alert on the service name.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Diskshadow Proxy Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = DiskShadow.exe is a Microsoft Signed binary present on Windows Server. It has a scripting mode intended for complex scripted backup operations. This feature also allows for execution of arbitrary unsigned code. This analytic looks for the usage of the scripting mode flags in executions of DiskShadow. During triage, compare to known backup behavior in your environment and then review the scripts called by diskshadow.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.CM"]}
known_false_positives = Administrators using the DiskShadow tool in their infrastructure as a main backup tool with scripts will cause false positives that can be filtered with `windows_diskshadow_proxy_execution_filter`
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DISM Remove Defender - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of the Windows Disk Image Utility, `dism.exe`, to remove Windows Defender. Adversaries may use `dism.exe` to disable Defender before completing their objective.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Some legitimate administrative tools leverage `dism.exe` to manipulate packages and features of the operating system. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DLL Search Order Hijacking Hunt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic is an experimental query built against a accidental feature using the latest Sysmon TA 3.0 (https://splunkbase.splunk.com/app/5709/) which maps the module load (ImageLoaded) to process_name. This analytic will deprecate once this is fixed. This hunting analytic identifies known libraries in Windows that may be used in a DLL search order hijack or DLL Sideloading setting. This may require recompiling the DLL, moving the DLL or moving the vulnerable process. The query looks for any running out of system32 or syswow64. Some libraries natively run out of other application paths and will need to be added to the exclusion as needed. The lookup is comprised of Microsoft native libraries identified within the Hijacklibs.net project.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on paths. Filter or add other paths to the exclusion as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DLL Search Order Hijacking Hunt with Sysmon - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic is query built against a accidental feature using the latest Sysmon TA 3.0 (https://splunkbase.splunk.com/app/5709/) which maps the module load (ImageLoaded) to process_name. This analytic will deprecate once this is fixed. This hunting analytic identifies known libraries in Windows that may be used in a DLL search order hijack or DLL Sideloading setting. This may require recompiling the DLL, moving the DLL or moving the vulnerable process. The query looks for any running out of system32 or syswow64. Some libraries natively run out of other application paths and will need to be added to the exclusion as needed. The lookup is comprised of Microsoft native libraries identified within the Hijacklibs.net project.
how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on paths. Filter or add other paths to the exclusion as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows DLL Search Order Hijacking with iscsicpl - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a recently disclosed search ordler DLL hijack in iscsicpl.exe. The malicious DLL must be in a new path and iscsicpl.exe, upon load, will execute the payload. The analytic is restricted to Windows shells. Two proof of concepts were identified and utilized to determine the behavior. The command-line is an option to go after, but most likely identifying a child process off iscsicpl.exe will be more effective. Monitoring for suspicious DLL loads is also an option.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filtering may be required. Remove the Windows Shells macro to determine if other utilities are using iscsicpl.exe.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DLL Side-Loading In Calc - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious DLL modules loaded by calc.exe that are not in windows %systemroot%\system32 or %systemroot%\sysWoW64 folder. This technique is well used by Qakbot malware to execute its malicious DLL file via dll side loading technique in calc process execution. This TTP detection is a good indicator that a suspicious dll was loaded in a public or non-common installation folder of Windows Operating System that needs further investigation.
how_to_implement = To successfully implement this search you need to be ingesting information on processes that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows DLL Side-Loading Process Child Of Calc - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the suspicious child process of calc.exe due to dll side loading technique to execute another executable. This technique was seen in qakbot malware that uses dll side loading technique to calc applications to load its malicious dll code. The malicious dll that abuses dll side loading technique will load the actual qakbot loader dll using regsvr32.exe application. This TTP is a good indicator of qakbot since the calc.exe will not load other child processes aside from win32calc.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DNS Gather Network Info - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line used to enumerate DNS records. Adversaries, threat actors, or red teamers may employ this technique to gather information about a victim's DNS, which can be utilized during targeting. This method was also observed as part of a tool used by the Sandworm APT group in a geopolitical cyber warfare attack. By using the dnscmd.exe Windows application, an attacker can enumerate DNS records for specific domains within the targeted network, potentially aiding in further attacks. This anomaly detection can serve as a valuable starting point for identifying users and hostnames that may be compromised or targeted by adversaries seeking to collect data information.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1590.002"], "nist": ["DE.AE"]}
known_false_positives = network administrator can execute this command to enumerate DNS record. Filter or add other paths to the exclusion as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows DnsAdmins New Member Added - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4732 to identify the addition of a new member to the DnsAdmins group within Active Directory. . Members of the DnsAdmin group can manage the DNS service which most of the times runs on the Domain Controller. By abusing legitimate DNS management functionality, a member of the DnsAdmins group can escalate privileges by executing malicious code on a Domain Controller as SYSTEM. Security teams should monitor the modification of the DnsAdmins group and validate the changes are legitimate.
how_to_implement = To successfully implement this search, Domain Controller events need to be ingested. The Advanced Security Audit policy setting `Audit Security Group Management` within `Account Management` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1098"], "nist": ["DE.CM"]}
known_false_positives = New members can be added to the DnsAdmins group as part of legitimate administrative tasks. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Domain Account Discovery Via Get-NetComputer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets Get-NetComputer. This technique was seen used in the context of PowerView's Get-NetUser cmdlet as a filter or parameter to query Active Directory user account's "samccountname", "accountexpires", "lastlogon" and so on. This hunting query is a good pivot to look for suspicious process or malware that gather user account information in a host or within network system.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.=
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.AE"]}
known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Domain Admin Impersonation Indicator - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies potential Kerberos ticket forging attacks, specifically the Diamond Ticket attack. This is detected when a user logs into a host and the GroupMembership field in event 4627 indicates a privileged group (e.g., Domain Admins), but the user does not actually belong to that group in the directory service. The detection leverages Windows Security Event Log 4627, which logs account logon events. The analytic cross-references the GroupMembership field from the event against a pre-populated lookup of actual group memberships. Its crucial to note that the accuracy and effectiveness of this detection heavily rely on the users diligence in populating and regularly updating this lookup table. Any discrepancies between the events GroupMembership and the lookup indicate potential ticket forging. Kerberos ticket forging, especially the Diamond Ticket attack, allows attackers to impersonate any user and potentially gain unauthorized access to resources. By forging a ticket that indicates membership in a privileged group, an attacker can bypass security controls and gain elevated privileges. Detecting such discrepancies in group memberships during logon events can be a strong indicator of this attack in progress, making it crucial for security teams to monitor and investigate. If validated as a true positive, this indicates that an attacker has successfully forged a Kerberos ticket and may have gained unauthorized access to critical resources, potentially with elevated privileges.
how_to_implement = To successfully implement this search, you need to be ingesting Authentication events across all endpoints and ingest Event Id 4627. Specifically, the Audit Group Membership subcategory within the Logon Logooff category needs to be enabled. Its crucial to note that the accuracy and effectiveness of this detection heavily rely on the users diligence in populating and regularly updating this lookup table.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]}
known_false_positives = False positives may trigger the detections certain scenarios like directory service delays or out of date lookups. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows DotNet Binary in Non Standard Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies native .net binaries within the Windows operating system that may be abused by adversaries by moving it to a new directory. The analytic identifies the .net binary by using a lookup and compares the process name and original file name (internal name). The analytic utilizes a lookup with the is_net_windows_file macro to identify the binary process name and original file name. if one or the other matches an alert will be generated. Adversaries abuse these binaries as they are native to windows and native DotNet. Note that not all SDK (post install of Windows) are captured in the lookup.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003", "T1218", "T1218.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering may be required. Certain utilities will run from non-standard paths based on the third-party application in use.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Driver Inventory - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following hunting / inventory query assists defenders in identifying Drivers being loaded across the fleet. This query relies upon a PowerShell script input to be deployed to critical systems and beyond. If capturing all via the input, this will provide retrospection into drivers persisting. Note, that this is not perfect across a large fleet. Modify the query as you need to view the data differently.
how_to_implement = To capture the drivers by host, utilize the referenced Gist to create the inputs, props and transforms. Otherwise, this hunt query will not work.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.AE"]}
known_false_positives = Filter and modify the analytic as you'd like. Filter based on path. Remove the system32\drivers and look for non-standard paths.
providing_technologies = null

[savedsearch://ESCU - Windows Driver Load Non-Standard Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses Windows EventCode 7045 to identify new Kernel Mode Drivers being loaded in Windows from a non-standard path. Note that, adversaries may move malicious or vulnerable drivers into these paths and load up. The idea is that this analytic provides visibility into drivers loading in non-standard file paths.
how_to_implement = To implement this analytic, the Windows EventCode 7045 will need to be logged. The Windows TA for Splunk is also recommended.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1014", "T1068"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on legitimate third party applications needing to install drivers. Filter, or allow list known good drivers consistently being installed in these paths.
providing_technologies = null

[savedsearch://ESCU - Windows Drivers Loaded by Signature - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic assists with viewing all drivers being loaded by using Sysmon EventCode 6 (Driver Load). Sysmon provides some simple fields to assist with identifying suspicious drivers. Use this analytic to look at prevalence of driver (count), path of driver, signature status and hash. Review these fields with scrutiny until the ability to prove the driver is legitimate and has a purpose in the environment.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have the latest version of the Sysmon TA. Most EDR products provide the ability to review driver loads, or module loads, and using a query as such help with hunting for malicious drivers.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1014", "T1068"], "nist": ["DE.AE"]}
known_false_positives = This analytic is meant to assist with identifying drivers loaded in the environment and not to be setup for notables off the bat.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Enable Win32 ScheduledJob via Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic searches for a registry modification that enables the use of the at.exe or wmi Win32_ScheduledJob command to add scheduled tasks on a Windows endpoint. Specifically, it looks for the creation of a new DWORD value named "EnableAt" in the following registry path: "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Configuration". If this value is set to 1, it enables the at.exe and wmi Win32_ScheduledJob commands to schedule tasks on the system. Detecting this registry modification is important because it may indicate that an attacker has enabled the ability to add scheduled tasks to the system, which can be used to execute malicious code at specific times or intervals.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005"], "nist": ["DE.AE"]}
known_false_positives = In some cases, an automated script or system may enable this setting continuously, leading to false positives. To avoid such situations, it is recommended to monitor the frequency and context of the registry modification and modify or filter the detection rules as needed. This can help to reduce the number of false positives and ensure that only genuine threats are identified. Additionally, it is important to investigate any detected instances of this modification and analyze them in the broader context of the system and network to determine if further action is necessary.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Event For Service Disabled - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious system event of services that was modified from start to disabled. This technique is seen where the adversary attempts to disable security app services, other malware services to evade the defense systems on the compromised host
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = Windows service update may cause this event. In that scenario, filtering is needed.
providing_technologies = null

[savedsearch://ESCU - Windows Event Log Cleared - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows Security Event ID 1102 or System log event 104 to identify when a Windows event log is cleared. Note that this analytic will require tuning or restricted to specific endpoints based on criticality. During triage, based on time of day and user, determine if this was planned. If not planned, follow through with reviewing parallel alerts and other data sources to determine what else may have occurred.
how_to_implement = To successfully implement this search, you need to be ingesting Windows event logs from your hosts. In addition, the Splunk Windows TA is needed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070", "T1070.001"], "nist": ["DE.CM"]}
known_false_positives = It is possible that these logs may be legitimately cleared by Administrators. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Event Triggered Image File Execution Options Injection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies EventCode 3000 in Application channel indicating a process exit. This behavior is based on process names being added to the Image File Execution Options under HKLM \SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ and \SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit. Once these are set for a process, an eventcode 3000 will generate. The example used is from Thinkst Canary where a CanaryToken is setup to monitor for a commonly abused living off the land binary (ex. Klist.exe) and generate an event when it occurs. This can be seen as settings traps to monitor for suspicious behavior. Monitor and tune this hunting analytic and setup traps across your organization and begin monitoring.
how_to_implement = This analytic requires capturing the Windows Event Log Application channel in XML.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.012"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present and tuning will be required before turning into a TTP or notable.
providing_technologies = null

[savedsearch://ESCU - Windows Excessive Disabled Services Event - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious excessive number of system events of services that was modified from start to disabled. This technique is seen where the adversary attempts to disable security app services, other malware services oer serve as an destructive impact to complete the objective on the compromised system. One good example for this scenario is Olympic destroyer where it disable all active services in the compromised host as part of its destructive impact and defense evasion.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = null

[savedsearch://ESCU - Windows Executable in Loaded Modules - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies potentially malicious 'ImageLoaded' events, particularly when they involve executable files. This behavior was observed in NjRAT instances, where, during each instance of loading a module from its C2 server onto the compromised host, Sysmon recorded the path of the actual Image or Process as an 'ImageLoaded' event, rather than the typical tracking of dynamically loaded DLL modules in memory. This event holds significance because it tracks processes that load modules and libraries, which are typically in the .dll format rather than .exe. Leveraging this 'Time-To-Perform' (TTP) detection method can prove invaluable for the identification of NjRAT malware or other malicious software instances that introduce executable files as modules within a targeted host.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1129"], "nist": ["DE.CM"]}
known_false_positives = unknown.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Execute Arbitrary Commands with MSDT - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a recently disclosed arbitraty command execution using Windows msdt.exe - a Diagnostics Troubleshooting Wizard. The sample identified will use the ms-msdt:/ protocol handler to load msdt.exe to retrieve a remote payload. During triage, review file modifications for html. Identify parallel process execution that may be related, including an Office Product.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter as needed. Added .xml to potentially capture any answer file usage. Remove as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Exfiltration Over C2 Via Invoke RestMethod - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the potential exfiltration of data using PowerShell's Invoke-RestMethod. This technique was observed in the Winter-Vivern malware, which uploads desktop screenshots and files from compromised or targeted hosts. Detecting this TTP can serve as a valuable indicator that a process is attempting to upload files to an external or internal URI link. We recommend examining the process, the files it is trying to upload, and the URL link or C2 destination where the data is being uploaded.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1041"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Exfiltration Over C2 Via Powershell UploadString - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies potential data exfiltration using the PowerShell net.webclient command. This technique was observed in the Winter-Vivern malware, which uploads desktop screenshots and files from compromised or targeted hosts. Detecting this TTP can serve as a valuable indicator that a process is attempting to upload files to an external or internal URI link. We recommend examining the process, the files it is trying to upload, and the URL link or C2 destination where the data is being uploaded.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1041"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Export Certificate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when a certificate is exported from the Windows Certificate Store. This analytic utilizes the Certificates Lifecycle log channel event ID 1007. EventID 1007 is focused on the Export of a certificate from the local certificate store. In addition, review the ProcessName field as it will help to determine automation/Admin or adversary extracting the certificate. Depending on the organization, the certificate may be used for authentication to the VPN or private resources.
how_to_implement = To implement this analytic, you must collect Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational or Microsoft-Windows-CertificateServicesClient-Lifecycle-User/Operational.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.004", "T1552", "T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives may be generated based on an automated process or service that exports certificates on the regular. Review is required before setting to alert. Monitor for abnormal processes performing an export.
providing_technologies = null

[savedsearch://ESCU - Windows File Share Discovery With Powerview - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of the Invoke-ShareFinder PowerShell commandlet part of PowerView. This module obtains the list of all active domain computers and lists the active shares on each computer. Network file shares in Active Directory environments may contain sensitive information like backups, scripts, credentials, etc. Adversaries who have obtained a foothold in an AD network may leverage PowerView to identify secrets and leverage them for Privilege Escalation or Lateral Movement.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.=
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1135"], "nist": ["DE.CM"]}
known_false_positives = Security teams may leverage PowerView proactively to identify and remediate sensitive file shares. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows File Transfer Protocol In Non-Common Process Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a possible windows application having a FTP connection in a non common installation path in windows operating system.This network protocol is being used by adversaries, threat actors and malware like AgentTesla as a Command And Control communication to transfer its collected stolen information like the desktop screenshots, browser information and system information of a targeted or compromised host.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 3 connection events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.003", "T1071"], "nist": ["DE.AE"]}
known_false_positives = third party application may use this network protocol as part of its feature. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows File Without Extension In Critical Folder - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for suspicious file creation in the critical folder like "System32\Drivers" folder without file extension. This artifacts was seen in latest hermeticwiper where it drops its driver component in Driver Directory both the compressed(without file extension) and the actual driver component (with .sys file extension). This TTP is really a good indication that a host might be compromised by this destructive malware that wipes the boot sector of the system.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.CM"]}
known_false_positives = Unknown at this point
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Njrat Fileless Storage via Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification associated with NjRat, a telltale sign of its fileless technique. NjRat employs this method to manage its keylogs and execute downloaded DLL module plugins discreetly on the compromised host. This approach is particularly effective at evading conventional file-based detection systems, as it stores indicators of compromise (IOCs) in the registry. Leveraging this TTP (Tactics, Techniques, and Procedures) detection can significantly enhance the identification of NjRAT infections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027.011", "T1027"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Files and Dirs Access Rights Modification Via Icacls - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic aims to identify potential adversaries who manipulate the security permissions of specific files or directories. This technique is frequently observed in the tradecraft of Advanced Persistent Threats (APTs) and coinminer scripts. By modifying the security permissions, adversaries seek to evade detection and impede access to their component files. Such actions indicate a deliberate effort to maintain control over compromised systems and hinder investigation or remediation efforts. Detecting these security permission changes can serve as a valuable indicator of an ongoing attack and enable timely response to mitigate the impact of the adversary's activities.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1222.001", "T1222"], "nist": ["DE.CM"]}
known_false_positives = Unknown. It is possible some administrative scripts use ICacls. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Find Domain Organizational Units with GetDomainOU - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Get-DomainOU` commandlet. `Get-DomainOU` is a component of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Identifying the use of `Get-DomainOU` is crucial as adversaries and Red Teams might employ it to gain insights into organizational units within Active Directory, potentially aiding in lateral movement or privilege escalation strategies.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Find Interesting ACL with FindInterestingDomainAcl - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Find-InterestingDomainAcl` commandlet. `Find-InterestingDomainAcl` is part of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Find-InterestingDomainAcl` is crucial as adversaries and Red Teams might employ it to identify unusual or misconfigured Access Control Lists (ACLs) within the domain. Such ACLs can provide attackers with insights into potential privilege escalation opportunities or weak security postures within Active Directory.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Findstr GPP Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of the findstr command employed to search for unsecured credentials Group Policy Preferences (GPP). GPP are tools that allow administrators to create domain policies with embedded credentials. These policies allow administrators to set local accounts. These group policies are stored in SYSVOL on a domain controller. This means that any domain user can view the SYSVOL share and decrypt the password (using the AES key that has been made public). While Microsoft released a patch that impedes Administrators to create unsecure credentials, existing Group Policy Preferences files with passwords are not removed from SYSVOL.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552", "T1552.006"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage findstr to find passwords in GPO to validate exposure. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Forest Discovery with GetForestDomain - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic utilizes PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Get-ForestDomain` commandlet. `Get-ForestDomain` is a component of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Get-ForestDomain` is essential as adversaries and Red Teams might employ it to gain insights into the forest and domain configurations of an Active Directory environment.  Such information can provide attackers with a broader understanding of the domain structure and potential avenues for lateral movement or privilege escalation.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Gather Victim Host Information Camera - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a powershell script that enumerate camera mounted to the targeted host. This technique was seen in DCRat malware, where it runs a powershell command to look for camera information that will be pass on to its C2 server. This anomaly detection can be a good pivot to check who and why this enumeration is needed and what parent process execute this powershell script command.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592.001", "T1592"], "nist": ["DE.AE"]}
known_false_positives = Administrators may execute this powershell command to get hardware information related to camera on $dest$.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Gather Victim Identity SAM Info - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process that loads the samlib.dll module. This module is being abused by adversaries, threat actors and red teamers to access information of SAM objects or access credentials information in DC. This hunting query can be a good indicator that a process is capable of accessing the SAM object.
how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1589.001", "T1589"], "nist": ["DE.AE"]}
known_false_positives = this module can be loaded by a third party application. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Gather Victim Network Info Through Ip Check Web Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies process that attempts to connect to a known IP web services. This technique is commonly used by trickbot and other malware to perform reconnaissance against the infected machine and look for its IP address.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, dns query name process path , and query ststus from your endpoints like EventCode 22. If you are using Sysmon, you must have at least version 12 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1590.005", "T1590"], "nist": ["DE.AE"]}
known_false_positives = Filter internet browser application to minimize the false positive of this detection.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Get-AdComputer Unconstrained Delegation Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the Get-ADComputer commandlet used with specific parameters to discover Windows endpoints with Kerberos Unconstrained Delegation. Red Teams and adversaries alike may leverage use this technique for situational awareness and Active Directory Discovery.
how_to_implement = The following  analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may leverage PowerView for system management or troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Get Local Admin with FindLocalAdminAccess - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic leverages PowerShell Script Block Logging (EventCode=4104) to detect the execution of the `Find-LocalAdminAccess` commandlet. `Find-LocalAdminAccess` is part of PowerView, a PowerShell toolkit designed for Windows domain enumeration. Detecting the use of `Find-LocalAdminAccess` is vital as adversaries and Red Teams might employ it to identify machines where the current user context has local administrator access. Such information can provide attackers with potential targets for lateral movement or privilege escalation within the network.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1087.002"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage PowerSploit tools for legitimate reasons, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Group Policy Object Created - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event IDs 5136 and 51137 to identify the creation of a new Group Policy Object. With GPOs, system administrators can manage and configure applications, software operations, and user settings throughout an entire organization. GPOs can be abused and leveraged by adversaries to escalate privileges or deploy malware across an Active Directory network. As an example, the Lockbit ransomware malware will create new group policies on the domain controller that are then pushed out to every device on the network. Security teams should monitor the creation of new Group Policy Objects.
how_to_implement = To successfully implement this search, the Advanced Security Audit policy setting `Audit Directory Service Changes` within `DS Access` needs to be enabled. Furthermore, the appropriate system access control lists (SACL) need to be created as the used events are not logged by default. A good guide to accomplish this can be found here https://jgspiers.com/audit-group-policy-changes/.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1484", "T1484.001", "T1078.002"], "nist": ["DE.CM"]}
known_false_positives = Group Policy Objects are created as part of regular administrative operations, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Hidden Schedule Task Settings - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects creation of hidden scheculed tasks such that it this task is not visible on the UI. Such behavior is indicative of certain malware, such as Industroyer2, or attacks leveraging living-off-the-land binaries (LOLBINs) to download additional payloads to a compromised machine. This analytic relies on the Windows Security EventCode 4698, indicating the creation of a scheduled task. The search focuses on identifying instances where the 'Hidden' setting is enabled, signaling potential nefarious activity. To implement this search, you need to ingest logs with task scheduling details from your endpoints. As false positives are currently unknown, it is advised to tune and filter based on the known use of task scheduling in your environment. This analytic provides crucial visibility into stealthy, potentially harmful scheduled tasks on Windows systems.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the task schedule (Exa. Security Log EventCode 4698) endpoints. Tune and filter known instances of Task schedule used in your environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Hide Notification Features Through Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious registry modification to hide common windows notification feature from compromised host. This technique was seen in some ransomware family to add more impact to its payload that are visually seen by user aside from the encrypted files and ransomware notes. Even this a good anomaly detection, administrator may implement this changes for auditing or security reason. In this scenario filter is needed.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows High File Deletion Frequency - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search identifies a high frequency of file deletions relative to the process name and process ID. Such events typically occur when ransomware attempts to encrypt files with specific extensions, leading Sysmon to treat the original files as deleted as soon as they are replaced with encrypted data.
how_to_implement = To successfully implement this search, you need to ingest logs that include the deleted target file name, process name, and process ID from your endpoints. If you are using Sysmon, ensure you have at least version 2.0 of the Sysmon TA installed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1485"], "nist": ["DE.AE"]}
known_false_positives = Users may delete a large number of pictures or files in a folder, which could trigger this detection. Additionally, heavy usage of PowerBI and Outlook may also result in false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Hijack Execution Flow Version Dll Side Load - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a process loading version.dll that is not in %windir%\\system32 or %windir%\\syswow64 dir path. This event is seen in ransomware and APT malware that executes malicious version.dll placed in the same folder of onedrive application that will execute that module. This technique is known to be DLL side loading. This technique was used to execute an agent of Brute Ratel C4 red teaming tools to serve as remote admin tool to collect and compromise target host.
how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Hunting System Account Targeting Lsass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies all processes requesting access into Lsass.exe. his behavior may be related to credential dumping or applications requiring access to credentials. Triaging this event will require understanding the GrantedAccess from the SourceImage. In addition, whether the account is privileged or not. Review the process requesting permissions and review parallel processes.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Enabling EventCode 10 TargetProcess lsass.exe is required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.AE"]}
known_false_positives = False positives will occur based on GrantedAccess and SourceUser, filter based on source image as needed. Utilize this hunting analytic to tune out false positives in TTP or anomaly analytics.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Identify Protocol Handlers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic will identify any protocol handlers utilized on the command-line. A protocol handler is an application that knows how to handle particular types of links: for example, a mail client is a protocol handler for "mailto:" links. When the user clicks a "mailto:" link, the browser opens the application selected as the handler for the "mailto:" protocol (or offers them a choice of handlers, depending on their settings). To identify protocol handlers we can use NirSoft https://www.nirsoft.net/utils/url_protocol_view.html URLProtocolView or query the registry using PowerShell.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives will be found. https and http is a URL Protocol handler that will trigger this analytic. Tune based on process or command-line.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows IIS Components Add New Module - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the process AppCmd.exe installing a new module into IIS. AppCmd is a utility to manage IIS web sites and App Pools. An adversary may run this command to install a webshell or backdoor. This has been found to be used for credit card scraping, persistence, and further post-exploitation. An administrator may run this to install new modules for a web site or during IIS updates.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present until properly tuned. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows IIS Components Get-WebGlobalModule Module Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic requires the use of PowerShell inputs to run Get-WebGlobalModule to list out all the IIS Modules installed. The output is a list of Module names and the Image path of the DLL.
how_to_implement = You must ingest the PwSh cmdlet Get-WebGlobalModule in order to utilize this analytic. Follow https://gist.github.com/MHaggis/64396dfd9fc3734e1d1901a8f2f07040
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505.004", "T1505"], "nist": ["DE.AE"]}
known_false_positives = This analytic is meant to assist with hunting modules across a fleet of IIS servers. Filter and modify as needed.
providing_technologies = null

[savedsearch://ESCU - Windows IIS Components Module Failed to Load - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes EventCode 2282 which generates when a Module DLL could not be loaded due to a configuration problem. This typically occurs when a IIS module is installed but is failing to load. This typically results in thousands of events until the issue is resolved. Review the module that is failing and determine if it is legitimate or not.
how_to_implement = IIS must be installed and Application event logs must be collected in order to utilize this analytic.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present until all module failures are resolved or reviewed.
providing_technologies = null

[savedsearch://ESCU - Windows IIS Components New Module Added - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses the Windows Event log - Microsoft-IIS-Configuration/Operational - which must be enabled and logged on Windows IIS servers before it can be Splunked. The following analytic identifies newly installed IIS modules. Per Microsoft, IIS modules are not commonly added to a production IIS server, so alerting on this event ID should be enabled.IIS modules can be installed at a global level or at a site level. In detecting malicious IIS modules, it is important to check both the global and site level for unauthorized modules. Regular monitoring of these locations for such modules and comparing against a known good list can help detect and identify malicious IIS modules.
how_to_implement = You must enabled the IIS Configuration Operational log before ingesting in Splunk. Setup and inputs may be found here https://gist.github.com/MHaggis/64396dfd9fc3734e1d1901a8f2f07040.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present when updates or an administrator adds a new module to IIS. Monitor and filter as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Impair Defense Add Xml Applocker Rules - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a process that imports applocker xml policy using PowerShell commandlet. This technique was seen in Azorult malware where it drop an xml Applocker policy that will deny several AV products and further executed the PowerShell Applocker commandlet.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = Administrators may execute this command that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Change Win Defender Health Check Intervals - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to change the health check interval of Windows Defender. Specifically, a value of 1 typically signifies that Windows Defender would perform health checks at a much higher frequency than the default settings. However, it's important to note that modifying this value to 1 might not necessarily conform to the actual behavior, as certain registry settings may have specific accepted values or a defined range that differs from a simple binary representation. Changing registry values, especially those related to system services, should be approached cautiously. Incorrect modifications can potentially impact system stability or performance. Always ensure you understand the implications and have a backup before altering registry settings.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Change Win Defender Quick Scan Interval - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to change Windows Defender Quick Scan Interval. The "QuickScanInterval" in Windows Defender, specifically within the context of antivirus software, typically refers to the interval or frequency at which the system conducts quick scans for malware or potential threats. This setting dictates how often Windows Defender performs quick scans on the system. Quick scans are less comprehensive than full system scans but provide a faster way to check critical areas for potential threats or malware. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Change Win Defender Throttle Rate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to change the ThrottleDetectionEventsRate of Windows Defender. The ThrottleDetectionEventsRate registry setting in Windows Defender is related to controlling the rate at which detection events are logged or reported by Windows Defender Antivirus. This registry setting determines how frequently Windows Defender logs or reports detection events. Adjusting the ThrottleDetectionEventsRate value can impact the logging frequency of detection events such as malware detections, scanning results, or security-related events recorded by Windows Defender. A higher value might mean that detection events are reported less frequently, potentially reducing the volume of recorded events, while a lower value could increase the reporting frequency, resulting in more frequent logs of detection events.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Change Win Defender Tracing Level - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to change the Windows Defender Wpp Tracing levels. The "WppTracingLevel" registry setting is typically related to Windows software tracing and diagnostics, specifically involving Windows Software Trace Preprocessor (WPP) tracing. WPP tracing is a mechanism used by developers to instrument code for diagnostic purposes, allowing for the collection of detailed logs and traces during software execution. It helps in understanding the behavior of the software, identifying issues, and analyzing its performance. Without specific documentation or references to "WppTracingLevel" within Windows Defender settings or its functionalities, it's challenging to provide precise details about its intended use or configuration within Windows Defender. Modifying registry settings without understanding their implications can affect system behavior or security. Always proceed cautiously and ensure changes align with best practices and organizational requirements.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Configure App Install Control - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to change or disable Windows Defender smartscreen app install control. Microsoft Edge's App Install Control feature helps manage the installation of web-based applications. When attackers modify "ConfigureAppInstallControlEnabled" to 0, they are likely attempting to disable the App Install Control feature in Microsoft Edge. This change might allow users to bypass restrictions imposed by the browser on the installation of web-based applications. Disabling this feature might increase the risk of users being able to install potentially malicious or untrusted web applications without restrictions or controls imposed by the browser. This action could potentially lead to security vulnerabilities or compromise if users inadvertently install harmful applications.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Define Win Defender Threat Action - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to define the threat action of Windows Defender. The ThreatSeverityDefaultAction registry setting in Windows Defender is used to define the default action taken by Windows Defender when it encounters threats of specific severity levels. A setting like ThreatSeverityDefaultAction is designed to define how Windows Defender responds to threats based on their severity. For example, it might determine whether Windows Defender quarantines, removes, or takes other actions against threats based on their severity levels. In this context, a registry value of 1 typically indicates an action to "clean," aiming to disinfect or resolve the detected threat, while a registry value of 9 signifies "no action," meaning that the antivirus software refrains from taking immediate steps against the identified threat.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Delete Win Defender Context Menu - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for the deletion of Windows Defender context menu within the registry. This is consistent behavior with RAT malware across a fleet of endpoints. This particular behavior is executed when an adversary gains access to an endpoint and begins to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Delete Win Defender Profile Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for the deletion of Windows Defender main profile within the registry. This was used by RAT malware across a fleet of endpoints. This particular behavior is typically executed when an adversary gains access to an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Deny Security Software With Applocker - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry by the Applocker utility that contains details or registry data values related to denying the execution of several security products. This technique was seen in Azorult malware where it drops an xml Applocker policy that will deny several AV products and then loaded by using PowerShell Applocker commandlet.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on organization use of Applocker. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Controlled Folder Access - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender Controlled Folder Access feature. The EnableControlledFolderAccess registry setting is associated with the Controlled Folder Access feature in Windows Defender. Controlled Folder Access is a security feature designed to protect certain folders from unauthorized access or modification by malicious applications, including ransomware. When EnableControlledFolderAccess is set to 0, it usually indicates that the Controlled Folder Access feature within Windows Defender is not active. Consequently, the protection mechanism for the specified folders against unauthorized access by potentially malicious applications or ransomware is not enabled.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Defender Firewall And Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable firewall and network protection section settings of windows security. The specific impact of this change depends on the context and the purpose behind modifying this registry value. In general, setting UILockdown to 1 might imply enforcing a restriction or lockdown in the user interface (UI) related to firewall and network protection settings within Windows Defender Security Center. This could potentially restrict users from modifying certain firewall or network protection settings through the UI.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Defender Protocol Recognition - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender protocol recognition feature. The DisableProtocolRecognition setting in Windows Defender is not a commonly known or documented registry setting. It's possible that this specific setting might not exist within the standard Windows Defender configurations or that it might be specific to certain environments, versions, or configurations. It might potentially control or influence the antivirus software's ability to recognize and handle specific protocols or communication methods used by malware or suspicious software.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable PUA Protection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender PUA protection. Setting PUAProtection to 0 typically disables the detection and protection against Potentially Unwanted Applications by Microsoft Defender Antivirus. Potentially Unwanted Applications include software that may not be inherently malicious but could exhibit behaviors that users may find undesirable, such as adware, browser toolbars, or software bundlers. Disabling this feature might be preferred in certain situations, but it's essential to consider potential security implications. Enabling PUA protection provides an additional layer of defense against software that might negatively impact user experience or security.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Realtime Signature Delivery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable windows defender realtime signature delivery feature. This setting governs how Windows Defender Antivirus receives updated signature definitions for identifying and combating malware threats in real-time. The actual impact and behaviors associated with different values for RealtimeSignatureDelivery can vary based on specific Windows Defender configurations and policies. For instance, setting this value to 0 or 1 might control whether real-time signatures are delivered via different methods such as through Windows Update or directly from Microsoft's cloud-based services.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Web Evaluation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender web content evaluation. The "EnableWebContentEvaluation" registry entry typically relates to security settings within Microsoft Edge or Internet Explorer, enabling the evaluation of web content for security purposes. When attackers modify "EnableWebContentEvaluation" to 0, they might attempt to disable the browser's capability to evaluate web content for security purposes. Disabling this feature could potentially impact the browser's ability to assess the security risks associated with web content, such as potentially malicious scripts, active content, or unsafe web elements. By turning off content evaluation, attackers might aim to exploit security vulnerabilities present in web content without triggering security warnings or blocks. This manipulation increases the risk of users accessing or interacting with malicious content, potentially leading to security compromises or system exploitation.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender App Guard - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender audit application guard. Microsoft Defender Application Guard provides enhanced security by isolating potentially malicious documents and websites in a containerized environment, protecting the system against various threats. Auditing and logging are essential components of security measures, providing visibility into activities within the isolated environment. Disabling auditing events within Application Guard might not be a standard or recommended practice since auditing is crucial for security monitoring and threat detection within the isolated container. However, there might be settings or configurations related to audit policies in the broader Windows Defender or operating system settings. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender Compute File Hashes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender file hashes computation. The EnableFileHashComputation registry setting likely pertains to whether Windows Defender's MpEngine (Malware Protection Engine) computes file hashes. Setting this value to 0 might disable the file hash computation feature within Windows Defender, which could affect certain malware detection or scanning functionalities that rely on file hash analysis. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender Gen reports - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender generic ports. This registry can disable the sending of Watson events in Windows Defender. This is by preventing the transmission of generic or non-specific error reports to Microsoft's Windows Error Reporting service, commonly known as Watson. This kind of setting could potentially be employed to limit or control the data sent to Microsoft for error analysis, often in scenarios where privacy or specific reporting requirements are in place. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender Network Protection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender exploit guard network protection. The EnableNetworkProtection registry entry controls the activation or deactivation of Network Protection within Windows Defender Exploit Guard. When set to 1, it typically signifies that Network Protection is enabled, offering additional security measures against network-based threats by analyzing and blocking potentially malicious network activity. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender Report Infection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable windows defender report infection information. Setting this registry key to 1, Instructs Windows Defender not to report detailed information about infections or threats detected on the system to Microsoft. Enabling this setting might limit or prevent the transmission of specific data related to infections, such as details about the detected malware, to Microsoft's servers for analysis or logging purposes. This registry is being abused by adversaries, threat actors and red-teamers to bypasses Windows Defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender Scan On Update - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender Scan On Update. The "DisableScanOnUpdate" registry setting in Windows Defender, when set to a value of 1, typically signifies the feature that prevents automatic scans from initiating when updates to Windows Defender or its antivirus definitions are installed. Any modifications to registry settings, it's important to ensure that changes align with security policies and best practices. Incorrect settings might affect the system's security or functionality. Always consider the implications and ensure changes are made based on accurate information and organizational requirements. This registry setting is being abuse by several threat actors, adversaries and red teamers to bypasses Windows defender detections.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Disable Win Defender Signature Retirement - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable windows defender Signature Retirement. The DisableSignatureRetirement registry setting in Windows Defender controls the retirement or expiration of antivirus signatures used by Windows Defender Antivirus. When DisableSignatureRetirement is set to 1, it usually indicates that Windows Defender won't automatically retire or expire antivirus signatures. Antivirus signatures are files containing information about known malware and are used by Windows Defender to detect and protect against threats. Disabling signature retirement might prevent Windows Defender from automatically removing or retiring older or less relevant antivirus signatures. This can potentially increase the number of signatures in use and might impact system resources or the effectiveness of threat detection.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Overide Win Defender Phishing Filter - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable windows defender phishing filter. This setting controls whether users can manually disable or modify the browser's built-in phishing filter. When attackers modify "PreventOverride" to 0, it might indicate an attempt to disable the prevention of user overrides for the phishing filter within Microsoft Edge. This change allows users to bypass or disable the built-in phishing protection provided by the browser. By allowing users to override the phishing filter, attackers may attempt to deceive users into visiting phishing websites or malicious pages without triggering warnings or protections from the browser's built-in security measures. This manipulation increases the risk of users unknowingly accessing potentially harmful websites, leading to potential security incidents or compromises.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Override SmartScreen Prompt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to override windows defender smartscreen prompt. The "PreventSmartScreenPromptOverride" registry setting is associated with the Windows SmartScreen feature, specifically related to controlling whether users can override SmartScreen prompts. When attackers modify "PreventSmartScreenPromptOverride" to 0, it signifies an attempt to disable the prevention of user overrides for SmartScreen prompts. By doing so, attackers aim to allow users to bypass or ignore SmartScreen warnings or prompts. This change increases the risk by permitting users to disregard warnings about potentially unsafe or malicious files or websites that would typically trigger SmartScreen alerts. It could lead to users unintentionally executing or accessing malicious content, potentially resulting in security incidents or system compromises.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defense Set Win Defender Smart Screen Level To Warn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to set windows defender smart screen level to warn. Setting the ShellSmartScreenLevel to warn implies a SmartScreen configuration where the system displays a warning prompt when users attempt to run or access potentially risky or unrecognized files or applications. This warning serves as a cautionary alert to users, advising them about the potential risks associated with the file or application they are trying to execute. Changing SmartScreen settings to "warn" might be employed by attackers to reduce the likelihood of triggering immediate suspicion from users when running malicious executables. By setting it to "warn," the system prompts a cautionary warning rather than outright blocking the execution, potentially increasing the chances of users proceeding with running the file despite the warning.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defenses Disable HVCI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic refers to a detection mechanism designed to identify when the Hypervisor-protected Code Integrity (HVCI) feature is disabled within the Windows registry. HVCI is a security feature in Windows 10 and Windows Server 2016 that helps protect the kernel and system processes from being tampered with by malicious code. HVCI relies on hardware-assisted virtualization and Microsoft's Hyper-V hypervisor to ensure that only kernel-mode code that has been signed by Microsoft or the system's hardware manufacturer can be executed. This prevents attackers from exploiting vulnerabilities to run unsigned code, like kernel-mode rootkits or other malicious software, at the kernel level. Disabling HVCI may expose the system to security risks and could be an indicator of a potential compromise or unauthorized activity. The analytic aims to detect and report events or configurations that lead to the disabling of HVCI.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = False positives will be limited to administrative scripts disabling HVCI. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Impair Defenses Disable Win Defender Auto Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for the Registry Key DefenderApiLogger or DefenderAuditLogger set to disable. This is consistent with RAT malware across a fleet of endpoints. This particular behavior is typically executed when an adversary gains access to an endpoint and beings to perform execution. Usually, a batch (.bat) will be executed and multiple registry and scheduled task modifications will occur. During triage, review parallel processes and identify any further file modifications.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = It is unusual to turn this feature off a Windows system since it is a default security control, although it is not rare for some policies to disable it. Although no false positives have been identified, use the provided filter macro to tune the search.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Indicator Removal Via Rmdir - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execute rmdir commandline to delete files and directory tree. This technique has been observed in the actions of various malware strains, such as DarkGate, as they attempt to eliminate specific files or components during their cleanup operations within compromised hosts. Notably, this deletion method doesn't exclusively require elevated privileges and can be executed by regular users or network administrators, although it's not the typical approach used for file deletion.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1070"], "nist": ["DE.AE"]}
known_false_positives = user and network administrator can execute this command.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Indirect Command Execution Via forfiles - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects programs that have been started by forfiles.exe. According to Microsoft, the 'The forfiles command lets you run a command on or pass arguments to multiple files'. While this tool can be used to start legitimate programs, usually within the context of a batch script, it has been observed being used to evade protections on command line execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1202"], "nist": ["DE.CM"]}
known_false_positives = Some legacy applications may be run using pcalua.exe. Similarly, forfiles.exe may be used in legitimate batch scripts.  Filter these results as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Indirect Command Execution Via pcalua - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects programs that have been started by pcalua.exe. pcalua.exe is the Microsoft Windows Program Compatability Assistant.  While this tool can be used to start legitimate programs, it has been observed being used to evade protections on command line execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1202"], "nist": ["DE.CM"]}
known_false_positives = Some legacy applications may be run using pcalua.exe.  Filter these results as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Indirect Command Execution Via Series Of Forfiles - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect suspicious excessive usage of forfiles.exe process. This event was seen in post exploitation tool WINPEAS that was used by Ransomware Prestige. Forfiles command lets you run a command on or pass arguments to multiple files. This Windows OS built-in tool being abused to list all files in specific directory or drive.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1202"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Information Discovery Fsutil - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS built-in tool FSUTIL to discover file system information. This tool is being abused or used by several adversaries or threat actor to query/list all drives, drive type, volume information or volume statistics by using the FSINFO parameter of this tool. This technique was seen in WINPEAS post exploitation tool that is being used by ransomware prestige to gain privilege and persistence to the targeted host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1082"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Ingress Tool Transfer Using Explorer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows Explorer process with a URL within the command-line. Explorer.exe is known Windows process that handles start menu, taskbar, desktop and file manager. Many adversaries abuse this process, like DCRat malware, where it attempts to open the URL with the default browser application on the target host by putting the URL as a parameter on explorer.exe process. This anomaly detection might be a good pivot to check which user and how this process was executed, what is the parent process and what is the URL link. This technique is not commonly used to open an URL.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present based on legitimate applications or third party utilities. Filter out any additional parent process names.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows InProcServer32 New Outlook Form - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic identifies the creation or modification of registry keys associated with new Outlook form installations that could indicate exploitation of CVE-2024-21378. The vulnerability allows for authenticated remote code execution via synced form objects by abusing the InProcServer32 registry key. The attack involves syncing malicious form objects that carry special properties and attachments used to "install" the form on a client, potentially leading to arbitrary file and registry key creation under HKEY_CLASSES_ROOT (HKCR), and ultimately, remote code execution. This detection focuses on monitoring for registry modifications involving InProcServer32 keys or equivalent that are linked to Outlook form installations, which are indicative of an attempt to exploit this vulnerability.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1566", "T1112"], "nist": ["DE.AE"]}
known_false_positives = False positives are possible if the organization adds new forms to Outlook via an automated method. Filter by name or path to reduce false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Input Capture Using Credential UI Dll - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process that loads the credui.dll module. This legitimate module is typically abused by adversaries, threat actors and red teamers to create a credential UI prompt dialog box to lure users for possible credential theft or can be used to dump the credentials of a targeted host. This hunting query is a good pivot to check why the process loaded this dll and if it is a legitimate file. This hunting query may hit false positive for a third party application that uses a credential login UI for user login.
how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1056.002", "T1056"], "nist": ["DE.AE"]}
known_false_positives = this module can be loaded by a third party application. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows InstallUtil Credential Theft - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows InstallUtil.exe binary loading `vaultcli.dll` and Samlib.dll`. This technique may be used to execute code to bypassing application control and capture credentials by utilizing a tool like MimiKatz. \
When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \
If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \
During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and module loads from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Typically this will not trigger as by it's very nature InstallUtil does not need credentials. Filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows InstallUtil in Non Standard Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows binary InstallUtil.exe running from a non-standard location. The analytic utilizes a macro for InstallUtil and identifies both the process_name and original_file_name.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036", "T1036.003", "T1218", "T1218.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering may be required. Certain utilities will run from non-standard paths based on the third-party application in use.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows InstallUtil Remote Network Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows InstallUtil.exe binary making a remote network connection. This technique may be used to download and execute code while bypassing application control. \
When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \
If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \
During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives should be present as InstallUtil is not typically used to download remote files. Filter as needed based on Developers requirements.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows InstallUtil Uninstall Option - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows InstallUtil.exe binary. This will execute code while bypassing application control using the `/u` (uninstall) switch. \
InstallUtil uses the functions install and uninstall within the System.Configuration.Install namespace to process .net assembly. Install function requires admin privileges, however, uninstall function can be run as an unprivileged user.\
When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \
If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \
During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives should be present. Filter as needed by parent process or application.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows InstallUtil Uninstall Option with Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows InstallUtil.exe binary making a remote network connection. This technique may be used to download and execute code while bypassing application control using the `/u` (uninstall) switch. \
InstallUtil uses the functions install and uninstall within the System.Configuration.Install namespace to process .net assembly. Install function requires admin privileges, however, uninstall function can be run as an unprivileged user.\
When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \
If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \
During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives should be present as InstallUtil is not typically used to download remote files. Filter as needed based on Developers requirements.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows InstallUtil URL in Command Line - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows InstallUtil.exe binary passing a HTTP request on the command-line. This technique may be used to download and execute code while bypassing application control. \
When `InstallUtil.exe` is used in a malicous manner, the path to an executable on the filesystem is typically specified. Take note of the parent process. In a suspicious instance, this will be spawned from a non-standard process like `Cmd.exe`, `PowerShell.exe` or `Explorer.exe`. \
If used by a developer, typically this will be found with multiple command-line switches/arguments and spawn from Visual Studio. \
During triage review resulting network connections, file modifications, and parallel processes. Capture any artifacts and review further.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.004", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Limited false positives should be present as InstallUtil is not typically used to download remote files. Filter as needed based on Developers requirements.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows ISO LNK File Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of a delivered ISO file that has been mounted and the afformention lnk or file opened within it. When the ISO file is opened, the files are saved in the %USER%\AppData\Local\Temp\<random folder name>\ path. The analytic identifies .iso.lnk written to the path. The name of the ISO file is prepended.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1566.001", "T1566", "T1204.001", "T1204"], "nist": ["DE.AE"]}
known_false_positives = False positives may be high depending on the environment and consistent use of ISOs mounting. Restrict to servers, or filter out based on commonly used ISO names. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Java Spawning Shells - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the process name of java.exe and w3wp.exe spawning a Windows shell. This is potentially indicative of exploitation of the Java application and may be related to current event CVE-2021-44228 (Log4Shell). The shells included in the macro are "cmd.exe", "powershell.exe". Upon triage, review parallel processes and command-line arguments to determine legitimacy.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = Filtering may be required on internal developer build systems or classify assets as web facing and restrict the analytic based on that.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Kerberos Local Successful Logon - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a local successful authentication event on a Windows endpoint using the Kerberos package. The target user security identified will be set to the built-in local Administrator account, along with the remote address as localhost - 127.0.0.1. This may be indicative of a kerberos relay attack. Upon triage, review for recently ran binaries on disk. In addition, look for new computer accounts added to Active Directory and other anomolous AD events.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4624 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible, filtering may be required to restrict to workstations vs domain controllers. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Known Abused DLL Created - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify instances where Dynamic Link Libraries (DLLs) with a known history of being exploited are created in locations that are not typical for their use. This could indicate that an attacker is attempting to exploit the DLL search order hijacking or sideloading techniques. DLL search order hijacking involves tricking an application into loading a malicious DLL instead of the legitimate one it was intending to load. This is often achieved by placing the malicious DLL in a directory that is searched before the directory containing the legitimate DLL. Sideloading, similarly, involves placing a malicious DLL with the same name as a legitimate DLL that an application is known to load, in a location that the application will search before finding the legitimate version. Both of these techniques can be used by attackers to execute arbitrary code, maintain persistence on a system, and potentially elevate their privileges, all while appearing as legitimate operations to the untrained eye. This analytic aims to shed light on such suspicious activities by monitoring for the creation of known abused DLLs in unconventional locations, thereby helping in the early detection of these stealthy attack techniques.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` and `Filesystem` nodes of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.001", "T1574.002", "T1574"], "nist": ["DE.AE"]}
known_false_positives = This analytic may flag instances where DLLs are loaded by user mode programs for entirely legitimate and benign purposes. It is important for users to be aware that false positives are not only possible but likely, and that careful tuning of this analytic is necessary to distinguish between malicious activity and normal, everyday operations of applications. This may involve adjusting thresholds, whitelisting known good software, or incorporating additional context from other security tools and logs to reduce the rate of false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Known GraphicalProton Loaded Modules - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a potential suspicious process loading dll modules related to Graphicalproton backdoor implant of SVR. These DLL modules have been observed in SVR attacks, commonly used to install backdoors on targeted hosts. This anomaly detection highlights the need for thorough investigation and immediate mitigation measures to safeguard the network against potential breaches.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows KrbRelayUp Service Creation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the default service name created by KrbRelayUp. Defenders should be aware that attackers could change the hardcoded service name of the KrbRelayUp tool and bypass this detection.
how_to_implement = To successfully implement this search, you need to be ingesting Windows System Event Logs with 7045 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this is specific to KrbRelayUp based attack. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Large Number of Computer Service Tickets Requested - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4769, `A Kerberos service ticket was requested`, to identify more than 30 computer service ticket requests from one source. When a domain joined endpoint connects to other remote endpoint, it will first request a Kerberos Service Ticket with the computer name as the Service Name. A user requesting a large number of computer service tickets for different endpoints could represent malicious behavior like lateral movement, malware staging, reconnaissance, etc.\
Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold as needed.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1135", "T1078"], "nist": ["DE.AE"]}
known_false_positives = An single endpoint requesting a large number of kerberos service tickets is not common behavior. Possible false positive scenarios include but are not limited to vulnerability scanners, administration systems and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Lateral Tool Transfer RemCom - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the use of RemCom.exe - The open source psexec. This utility provides the ability to move laterally and run scripts or commands remotely.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1570"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on Administrative use. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Ldifde Directory Object Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Ldifde.exe, which provides the ability to create, modify, or delete LDAP directory objects. Natively, the binary is only installed on a domain controller. However, adversaries or administrators may install the Windows Remote Server Admin Tools for ldifde.exe. Ldifde.exe is a Microsoft Windows command-line utility used to import or export LDAP directory entries. LDAP stands for Lightweight Directory Access Protocol, which is a protocol used for accessing and managing directory information services over an IP network. LDIF, on the other hand, stands for LDAP Data Interchange Format, a standard plain-text data interchange format for representing LDAP directory entries. -i This is a flag used with Ldifde.exe to denote import mode. In import mode, Ldifde.exe takes an LDIF file and imports its contents into the LDAP directory. The data in the LDIF file might include new objects to be created, or modifications or deletions to existing objects. -f This flag is used to specify the filename of the LDIF file that Ldifde.exe will import from (in the case of the -i flag) or export to (without the -i flag). For example, if you wanted to import data from a file called data.ldif, you would use the command ldifde -i -f data.ldif. Keep in mind that while the use of Ldifde.exe is legitimate in many contexts, it can also be used maliciously. For instance, an attacker who has gained access to a domain controller could potentially use Ldifde.exe to export sensitive data or make unauthorized changes to the directory. Therefore, it's important to monitor for unusual or unauthorized use of this tool.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1105", "T1069.002"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Linked Policies In ADSI Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate domain organizational unit for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Local Administrator Credential Stuffing - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages events 4625 and 4624 to identify an endpoint using the builtin local Administrator account to authenticate to a large numbers of endpoints. Specifically, the logic will trigger when an endpoints attempts to authenticate to more than 30 target computers within a 5 minute timespan. This behavior could represent an adversary who has obtained access to local credentials and is trying to validate if these credentials work on other hosts to escalate their privileges. As environments differ across organizations, security teams should customize the thresholds of this detection as needed.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110", "T1110.004"], "nist": ["DE.CM"]}
known_false_positives = Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows LSA Secrets NoLMhash Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry related to the Local Security Authority (LSA) in Windows. This registry value is used to determine whether the system should store passwords in the weaker Lan Manager (LM) hash format. Setting it to 0 disables this feature, meaning LM hashes will be stored. Modifying these settings should be done carefully and with a clear understanding of the impact it might have on system security and functionality. This command is often used in security configurations to enforce stronger password storage methods and prevent the storage of weaker LM hashes, which are more susceptible to certain types of attacks. This TTP detection can be a good indicator of any process or user that tries to modify the LSA security configuration.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.004"], "nist": ["DE.CM"]}
known_false_positives = Administrator may change this registry setting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Mail Protocol In Non-Common Process Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a possible windows application having a SMTP connection in a non common installation path in windows operating system.This network protocol is being used by adversaries, threat actors and malware like AgentTesla as a Command And Control communication to transfer its collected stolen information like the desktop screenshots, browser information and system information of a targeted or compromised host.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 3 connection events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.003", "T1071"], "nist": ["DE.AE"]}
known_false_positives = third party application may use this network protocol as part of its feature. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Mark Of The Web Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious process that delete mark-of-the-web data stream. This technique has been observed in various instances of malware and adversarial activities aimed at circumventing security restrictions within the Windows Operating System, particularly pertaining to files downloaded from the internet. An example of this scenario is demonstrated by Ave Maria RAT, which attempts to delete this data stream as a means to evade such restrictions.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the deleted target file name, process name and process id  from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.005"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Masquerading Explorer As Child Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious parent process of explorer.exe. Explorer is usually executed by userinit.exe that will exit after execution that causes the main explorer.exe no parent process. Some malware like qakbot spawn another explorer.exe to inject its code. This TTP detection is a good indicator that a process spawning explorer.exe might inject code or masquerading its parent child process to evade detections.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1574"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Masquerading Msdtc Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious msdtc.exe with specific command-line parameters, particularly -a or -b, which are regarded as potential indicators of the presence of the insidious PlugX malware. This malware is notorious for its covert operations and is frequently utilized by threat actors for unauthorized access, data exfiltration, and espionage. The analytic's focus on the -a or -b command-line parameters within msdtc.exe is rooted in the PlugX malware's sophisticated tactic of masquerading its activities. To elude detection, PlugX employs a technique where it injects a concealed, headless PlugX Dynamic Link Library (DLL) module into the legitimate msdtc.exe process. By leveraging these specific command-line parameters, the malware attempts to disguise its presence within a system's legitimate processes, thereby evading immediate suspicion.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1036"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Mimikatz Binary Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = As simple as it sounds, this analytic identifies when the native mimikatz.exe binary executes on Windows. It does look for the original file name as well, just in case the binary is renamed. Adversaries sometimes bring in the default binary and run it directly. Benjamin Delpy originally created Mimikatz as a proof of concept to show Microsoft that its authentication protocols were vulnerable to an attack. Instead, he inadvertently created one of the most widely used and downloaded threat actor tools of the past 20 years. Mimikatz is an open-source application that allows users to view and save authentication credentials such as Kerberos tickets.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this is directly looking for Mimikatz, the credential dumping utility.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Mimikatz Crypto Export File Extensions - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies hardcoded extensions related to the Crypo module within Mimikatz. Moving certificates or downloading them is not malicious, however with Mimikatz having hardcoded names it helps to identify potential usage of certificates being exported.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present and may need to be reviewed before this can be turned into a TTP. In addition, remove .pfx (standalone) if it's too much volume.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry AuthenticationLevelOverride - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry related to authentication level settings. This registry is the configuration for authentication level settings within the Terminal Server Client settings in Windows. AuthenticationLevelOverride might be used to control or override the authentication level used by the Terminal Server Client for remote connections. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Auto Minor Updates - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will "Treat minor updates like other updates".
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Auto Update Notif - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update notification. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will switch the automatic windows update to "Notify before download".
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Default Icon Setting - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect suspicious registry modification to change the default icon association of windows to ransomware . This technique was seen in Lockbit ransomware where it modified the default icon association of the compromised Windows OS  host with its dropped ransomware icon file as part of its  defacement payload. This registry is not commonly modified by a normal user so having this anomaly detection may help to catch possible lockbit ransomware infection or other malware.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Disable Restricted Admin - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry related to DisableRestrictedAdmin. This registry entry is used to control the behavior of Restricted Admin mode, which is a security feature that limits the exposure of sensitive credentials when connecting remotely to another computer. When this registry value is set to 0 it indicates that Restricted Admin mode is enabled (default behavior). As with any modifications to registry settings, changing this entry should be approached cautiously, ensuring a clear understanding of the implications for system security and functionality. Unauthorized changes to these security settings can pose risks and should be monitored closely for any signs of tampering or unauthorized alterations.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrator may change this registry setting. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Disable Toast Notifications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows registry to disable toast notifications. This Windows Operating System feature is responsible for alerting or notifying user if application or OS need some updates. Adversaries and malwares like Azorult abuse this technique to disable important update notification in compromised host. This anomaly detection is a good pivot to look for further events related to defense evasion and execution.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Disable Win Defender Raw Write Notif - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows Defender raw write notification feature. This policy controls whether raw volume write notifications are sent to behavior monitoring or not. This registry was recently identified in Azorult malware to bypass Windows Defender detections or behavior monitoring in terms of volume write.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Disable WinDefender Notifications - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification to disable Windows Defender notification. This technique was being abused by several adversaries, malware authors and also red-teamers to evade detection on the targeted machine. RedLine Stealer is one of the malware we've seen that uses this technique to bypass Windows defender detection.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Disable Windows Security Center Notif - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows registry to disable windows center notifications. This Windows Operating System feature is responsible for alerting or notifying user if application or OS need some updates. Adversaries and malwares like Azorult abuse this technique to disable important update notification in compromised host. This anomaly detection is a good pivot to look for further events related to defense evasion and execution.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry DisableRemoteDesktopAntiAlias - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to DisableRemoteDesktopAntiAlias. This registry setting might be intended to manage or control anti-aliasing behavior (smoothing of edges and fonts) within Remote Desktop sessions. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry DisableSecuritySettings - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable security settings of Terminal Services. altering or disabling security settings within Terminal Services. Terminal Services, now known as Remote Desktop Services (RDS) in more recent Windows versions, allows users to access applications, data, and even an entire desktop remotely. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Disabling WER Settings - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to disable Windows error reporting settings. This Windows feature allows the user to report bugs, errors, failure or problems encountered in specific application or processes. Adversaries use this technique to hide any error or failure that some of its malicious components trigger.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry DisAllow Windows App - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies modification in the Windows registry to prevent user running specific computer programs that could aid them in manually removing malware or detecting it using security products. This technique was recently identified in Azorult malware where it uses this registry value to prevent several AV products to execute on the compromised host machine.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Do Not Connect To Win Update - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will disable Windos update functionality, and may cause connection to public services such as the Windows Store to stop working. This policy applies only when this PC is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry DontShowUI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows Error Reporting registry to DontShowUI. DarkGate malware modify this registry as part of its malicious installation in a targeted host for its remote desktop capabilities. When this registry value is present and set to a specific configuration, it can influence the behavior of error reporting dialogs or prompts, suppressing them from being displayed to the user.For instance, setting DontShowUI to a value of 1 often indicates that the Windows Error Reporting UI prompts will be suppressed, meaning users won't see error reporting pop-ups when errors occur.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry EnableLinkedConnections - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows linked connection configuration. This technique was being abused by several adversaries, malware like BlackByte ransomware to enable the linked connections feature, that allows network shares to be accessed using both standard and administrator-level privileges simultaneously. By default, Windows does not enable this feature to enhance security.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry LongPathsEnabled - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows long path enable configuration. This technique was being abused by several adversaries, malware like BlackByte to enable long file path support in the operating system. By default, Windows has a limitation on the maximum length of a file path, which is set to 260 characters. Enabling the LongPathsEnabled setting allows you to work with file paths longer than 260 characters.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry MaxConnectionPerServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows max connection per server configuration. This particular technique has been observed in various threat actors, adversaries, and even in malware such as the Warzone (Ave Maria) RAT. By altering the max connection per server setting in the Windows registry, attackers can potentially increase the number of concurrent connections allowed to a remote server. This modification could be exploited for various malicious purposes, including facilitating distributed denial-of-service (DDoS) attacks or enabling more effective lateral movement within a compromised network.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry No Auto Reboot With Logon User - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will allow "Logged-on user gets to choose whether or not to restart his or her compute".
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry No Auto Update - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will "Disable Automatic Updates".
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry NoChangingWallPaper - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies alterations in the Windows registry aimed at restricting wallpaper modifications. This tactic has been exploited by the Rhysida ransomware as a part of its destructive payload within compromised systems. By making this registry modification, the ransomware seeks to impede users from changing the wallpaper forcibly set by the malware, restricting the user's control over their system's visual settings.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry ProxyEnable - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to enable proxy. This method has been exploited by various malware and adversaries to establish proxy communication on compromised hosts, facilitating connections to malicious Command and Control (C2) servers. Identifying this anomaly serves as a crucial indicator to unveil suspicious processes attempting to activate the proxy feature within the Windows operating system. Detecting such attempts becomes pivotal in flagging potential threats, especially those aiming to leverage proxy configurations for unauthorized communication with malicious entities.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry ProxyServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification in the Windows registry to setup proxy server. This method has been exploited by various malware and adversaries to establish proxy communication on compromised hosts, facilitating connections to malicious Command and Control (C2) servers. Identifying this anomaly serves as a crucial indicator to unveil suspicious processes attempting to activate the proxy feature within the Windows operating system. Detecting such attempts becomes pivotal in flagging potential threats, especially those aiming to leverage proxy configurations for unauthorized communication with malicious entities.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive, however is not common. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Qakbot Binary Data Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry entry created by Qakbot malware as part of its malicious execution. This "Binary Data" Registry  was created by newly spawn explorer.exe where its malicious code is injected to it. The registry consist of 8 random registry value name with encrypted binary data on its registry value data. This anomaly detections can be a good pivot for possible Qakbot malware infection or other malware that uses registry to save or store there config or malicious code on the registry data stream.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Reg Restore - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of reg.exe with "restore" parameter. This reg.exe parameter is commonly used to restore registry backup data in a targeted host. This approach or technique was also seen in post-exploitation tool like winpeas where it uses "reg save" and "reg restore" to check the registry modification restriction in targeted host after gaining access to it.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = network administrator can use this command tool to backup registry before updates or modifying critical registries.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Regedit Silent Reg Import - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies modification of Windows registry using regedit.exe application with silent mode parameter. regedit.exe windows application is commonly used as GUI app to check or modify registry. This application is also has undocumented command-line parameter and one of those are silent mode parameter that performs action without stopping for confirmation with dialog box. Importing registry from .reg files need to monitor in a production environment since it can be used adversaries to import RMS registry in compromised host.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may execute this command that may cause some false positive. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Risk Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify instances where three or more distinct analytics associated with Mitre ID T1112 - Modification of registry information are triggered. Such occurrences could indicate the presence of multiple malicious registry modifications on a host. Malicious actors frequently manipulate the Windows Registry to hide important configuration details within specific Registry keys. This technique allows them to obscure their activities, erase any evidence during cleanup operations, and establish continuous access and execution of malicious code.
how_to_implement = Splunk Enterprise Security is required to utilize this correlation. In addition, modify the source_count value to your environment. In our testing, a count of 4 or 5 was decent in a lab, but the number may need to be increased base on internal testing. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers.
providing_technologies = null

[savedsearch://ESCU - Windows Modify Registry Suppress Win Defender Notif - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows registry to suppress windows defender notification. This technique was abuse by adversaries and threat actor to bypassed windows defender on the targeted host. Azorult malware is one of the malware use this technique that also disable toast notification and other windows features as part of its malicious behavior.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry Tamper Protection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification to tamper Windows Defender protection. This technique was being abused by several adversaries, malware authors and also red-teamers to evade detection on the targeted machine. RedLine Stealer is one of the malware we've seen that uses this technique to bypass Windows defender detection.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry UpdateServiceUrlAlternate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that specifies an intranet server to host updates from Microsoft Update.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry USeWuServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification that will use "The WUServer value unless this key is set".
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry With MD5 Reg Key Name - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to identify potentially malicious registry modification characterized by MD5-like registry key names. This technique has been notably observed in NjRAT malware, which employs such registries for fileless storage of keylogs and .DLL plugins. Detecting this tactic serves as an effective means of identifying possible NjRAT malware instances that create or modify registries as part of their malicious activities.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry WuServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification related to the WSUS server used by Automatic Updates and (by default) API callers. This policy is paired with WUStatusServer; both must be set to the same value in order for them to be valid.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = Administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Registry wuStatusServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious registry modification of Windows auto update configuration. This technique was being abused by several adversaries, malware authors and also red-teamers to bypass detection or to be able to compromise the target host with zero day exploit or as an additional defense evasion technique. RedLine Stealer is one of the malware we've seen that uses this technique to evade detection and add more payload on the target host. This detection looks for registry modification related to the server to which reporting information will be sent for client computers that use the WSUS server configured by the WUServer key. This policy is paired with WUServer; both must be set to the same value in order for them to be valid.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify Show Compress Color And Info Tip Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for suspicious registry modification related to file compression color and information tips. This IOC was seen in hermetic wiper where it has a thread that will create this registry entry to change the color of compressed or encrypted files in NTFS file system as well as the pop up information tips. This is a good indicator that a process tries to modified one of the registry GlobalFolderOptions related to file compression attribution in terms of color in NTFS file system.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Modify System Firewall with Notable Process Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects a potential suspicious modification of firewall rule allowing to execute specific application in public and suspicious windows process file path. This technique was identified when an adversary and red teams to bypassed firewall file execution restriction in a targetted host. Take note that this event or command can run by administrator during testing or allowing legitimate tool or application.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.004", "T1562"], "nist": ["DE.CM"]}
known_false_positives = A network operator or systems administrator may utilize an automated or manual execution of this firewall rule that may generate false positives. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MOF Event Triggered Execution via WMI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following anaytic identifies MOFComp.exe loading a MOF file. The Managed Object Format (MOF) compiler parses a file containing MOF statements and adds the classes and class instances defined in the file to the WMI repository. Typically, MOFComp.exe does not reach out to the public internet or load a MOF file from User Profile paths. A filter and consumer is typically registered in WMI. Review parallel processes and query WMI subscriptions to gather artifacts. The default path of mofcomp.exe is C:\Windows\System32\wbem.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.003"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present from automation based applications (SCCM), filtering may be required. In addition, break the query out based on volume of usage. Filter process names or f
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MOVEit Transfer Writing ASPX - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of new ASPX files in the MOVEit Transfer application's "wwwroot" directory. This activity is indicative of the recent critical vulnerability found in MOVEit Transfer, where threat actors have been observed exploiting a zero-day vulnerability to install a malicious ASPX file (e.g., "human2.aspx") in the wwwroot directory. The injected file could then be used to exfiltrate sensitive data, including user credentials and file metadata. The vulnerability affects the MOVEit Transfer managed file transfer software developed by Progress, a subsidiary of US-based Progress Software Corporation. This analytic requires endpoint data reflecting process and filesystem activity. The identified process must be responsible for the creation of new ASPX or ASHX files in the specified directory.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` node and `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = The query is structured in a way that `action` (read, create) is not defined. Review the results of this query, filter, and tune as necessary. It may be necessary to generate this query specific to your endpoint product.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSExchange Management Mailbox Cmdlet Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses the Exchange Management logs, that are enabled by default, to identify suspicious Cmdlet usage related to ProxyShell and ProxyNotShell abuse.
how_to_implement = The following analytic requires collecting the Exchange Management logs via a input. An example inputs is here https://gist.github.com/MHaggis/f66f1d608ea046efb9157020cd34c178. We used multiline as the XML format of the logs will require props/transforms. Multiline gives us everything we need in Message for now. Update the macro with your correct sourcetype.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059", "T1059.001"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present when an Administrator utilizes the cmdlets in the query. Filter or monitor as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Mshta Execution In Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the usage of mshta.exe Windows binary in registry to execute malicious script. This technique was seen in kovter malware where it create several registry entry which is a encoded javascript and will be executed by another registry containing mshta and javascript activexobject to execute the encoded script using wscript.shell. This TTP is a good indication of kovter malware or other adversaries or threat actors leveraging fileless detection that survive system reboot.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.005"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSHTA Writing to World Writable Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection identifies instances of the Windows utility `mshta.exe` being used to write files to world-writable directories, a technique commonly leveraged by adversaries to execute malicious scripts or payloads. Starting from 26 February 2024, APT29 has been observed distributing phishing attachments that lead to the download and execution of the ROOTSAW dropper via a compromised website. The ROOTSAW payload, utilizing obfuscated JavaScript, downloads a file named `invite.txt` to the `C:\Windows\Tasks` directory. This file is then decoded and decompressed to execute a malicious payload, often leveraging legitimate Windows binaries for malicious purposes, as seen with `SqlDumper.exe` in this campaign. \
The analytic is designed to detect the initial file write operation by `mshta.exe` to directories that are typically writable by any user, such as `C:\Windows\Tasks`, `C:\Windows\Temp`, and others. This behavior is indicative of an attempt to establish persistence, execute code, or both, as part of a multi-stage infection process. The detection focuses on the use of `mshta.exe` to write to these locations, which is a deviation from the utility's legitimate use cases and thus serves as a strong indicator of compromise (IoC). \
The ROOTSAW campaign associated with APT29 utilizes a sophisticated obfuscation technique and leverages multiple stages of payloads, ultimately leading to the execution of the WINELOADER malware. This detection aims to catch the early stages of such attacks, enabling defenders to respond before full compromise occurs.
how_to_implement = The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The search focuses on EventCode 11 where the Image is `mshta.exe` and the TargetFilename is within world-writable directories such as `C:\Windows\Tasks`, `C:\Windows\Temp`, and others. The detection is designed to catch the initial file write operation by `mshta.exe` to these locations, which is indicative of an attempt to establish persistence or execute malicious code. The analytic can be modified to include additional world-writable directories as needed.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.005"], "nist": ["DE.CM"]}
known_false_positives = False positives may occur if legitimate processes are writing to world-writable directories. It is recommended to investigate the context of the file write operation to determine if it is malicious or not. Modify the search to include additional known good paths for `mshta.exe` to reduce false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows MSIExec DLLRegisterServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the usage of msiexec.exe using the /y switch parameter, which grants the ability for msiexec to load DLLRegisterServer. Upon triage, review parent process and capture any artifacts for further review.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]}
known_false_positives = This analytic will need to be tuned for your environment based on legitimate usage of msiexec.exe. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MsiExec HideWindow Rundll32 Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a msiexec.exe process with hidewindow rundll32 process commandline. One such tactic involves utilizing system processes like "msiexec," "hidewindow," and "rundll32" through command-line execution. By leveraging these legitimate processes, QakBot masks its malicious operations, hiding behind seemingly normal system activities. This clandestine approach allows the trojan to carry out unauthorized tasks discreetly, such as downloading additional payloads, executing malicious code, or establishing communication with remote servers. This obfuscation through trusted system processes enables QakBot to operate stealthily, evading detection by security mechanisms and perpetuating its harmful actions without raising suspicion.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007", "T1218"], "nist": ["DE.CM"]}
known_false_positives = Other possible 3rd party msi software installers use this technique as part of its installation process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSIExec Remote Download - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies msiexec.exe with http in the command-line. This procedure will utilize msiexec.exe to download a remote file and load it. During triage, review parallel processes and capture any artifacts on disk for review.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter by destination or parent process as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSIExec Spawn Discovery Command - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies MSIExec spawning multiple discovery commands, including spawning Cmd.exe or PowerShell.exe. Typically, child processes are not common from MSIExec other than MSIExec spawning itself.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present with MSIExec spawning Cmd or PowerShell. Filtering will be needed. In addition, add other known discovery processes to enhance query.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSIExec Spawn WinDBG - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the unusual behavior of MSIExec spawning WinDBG. It is designed to detect potential malicious activities. The search specifically looks for instances where the parent process name is 'msiexec.exe' and the process name is 'windbg.exe'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]}
known_false_positives = False positives will only be present if the MSIExec process legitimately spawns WinDBG. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSIExec Unregister DLLRegisterServer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the usage of msiexec.exe using the /z switch parameter, which grants the ability for msiexec to unload DLLRegisterServer. Upon triage, review parent process and capture any artifacts for further review.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]}
known_false_positives = This analytic will need to be tuned for your environment based on legitimate usage of msiexec.exe. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows MSIExec With Network Connections - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies MSIExec with any network connection over port 443 or 80. Typically, MSIExec does not perform network communication to the internet.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.007"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present and filtering is required.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Multi hop Proxy TOR Website Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a dns query to a known TOR proxy website. This technique was seen in several adversaries, threat actors and malware like AgentTesla to To disguise the source of its malicious traffic. adversaries may chain together multiple proxies. This Anomaly detection might be a good pivot for a process trying to download or use TOR proxies in a compromised host machine.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and sysmon eventcode = 22 dns query events from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.003", "T1071"], "nist": ["DE.AE"]}
known_false_positives = third party application may use this proxies if allowed in production environment. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Multiple Account Passwords Changed - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This Splunk detection identifies situations where over five unique Windows account passwords are changed within a 10-minute interval, captured by Event Code 4724 in the Windows Security Event Log. The query utilizes the wineventlog_security dataset, organizing data into 10-minute periods to monitor the count and distinct count of TargetUserName, the accounts with altered passwords. Rapid password changes across multiple accounts are atypical and might indicate unauthorized access or an internal actor compromising account security. Teams should calibrate the detection's threshold and timeframe to fit their specific operational context.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events with the Windows TA. The Advanced Security Audit policy setting `Audit User Account Management` within `Account Management` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation", "Delivery"], "mitre_attack": ["T1098", "T1078"], "nist": ["DE.CM"]}
known_false_positives = Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Accounts Deleted - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic flags when more than five unique Windows accounts are deleted within a 10-minute period, identified by Event Code 4726 in the Windows Security Event Log. Using the wineventlog_security dataset, it segments data into 10-minute intervals to monitor account deletions, a pattern that could suggest malicious intent like an attacker erasing traces. Teams should adjust the detection's threshold and timeframe to suit their specific environment.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events with the Windows TA. The Advanced Security Audit policy setting `Audit User Account Management` within `Account Management` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation", "Delivery"], "mitre_attack": ["T1098", "T1078"], "nist": ["DE.CM"]}
known_false_positives = Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Accounts Disabled - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This Splunk detection focuses on instances where more than five unique Windows accounts are disabled within a 10-minute window, as indicated by Event Code 4725 in the Windows Security Event Log. The query analyzes the wineventlog_security dataset, grouping data into 10-minute segments, and tracks the count and distinct count of TargetUserName, the accounts being disabled. This pattern of disabling multiple accounts rapidly is unusual and could signal internal policy breaches or an external attacker's attempt to disrupt normal operations. Teams are advised to tailor the threshold and timeframe of this detection to their environment's specifics
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events with the Windows TA. The Advanced Security Audit policy setting `Audit User Account Management` within `Account Management` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation", "Delivery"], "mitre_attack": ["T1098", "T1078"], "nist": ["DE.CM"]}
known_false_positives = Service accounts may be responsible for the creation, deletion or modification of accounts for legitimate purposes. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Disabled Users Failed To Authenticate Wth Kerberos - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique disabled domain users using the Kerberos protocol within 5 minutes. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack against disabled users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code `0x12` stands for `clients credentials have been revoked` (account disabled, expired or locked out).\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A host failing to authenticate with multiple disabled domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Invalid Users Fail To Authenticate Using Kerberos - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique invalid domain users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code 0x6 stands for `client not found in Kerberos database` (the attempted user is not a valid domain user).\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Invalid Users Failed To Authenticate Using NTLM - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique invalid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC0000064 stands for `The username you typed does not exist` (the attempted user is a legitimate domain user).\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation' within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Users Fail To Authenticate Wth ExplicitCredentials - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a source user failing to authenticate with 30 unique users using explicit credentials on a host. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4648 is generated when a process attempts an account logon by explicitly specifying that accounts credentials. This event generates on domain controllers, member servers, and workstations.\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source account, attempted user accounts and the endpoint were the behavior was identified.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A source user failing attempting to authenticate multiple users on a host is not a common behavior for regular systems. Some applications, however, may exhibit this behavior in which case sets of users hosts can be added to an allow list. Possible false positive scenarios include systems where several users connect to like Mail servers, identity providers, remote desktop services, Citrix, etc.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Users Failed To Authenticate From Host Using NTLM - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique valid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC000006A means: misspelled or bad password (the attempted user is a legitimate domain user).\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Users Failed To Authenticate From Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a source process name failing to authenticate with 30 uniquer users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4625 generates on domain controllers, member servers, and workstations when an account fails to logon. Logon Type 2 describes an iteractive logon attempt.\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed. This could be a domain controller as well as a member server or workstation.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers aas well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A process failing to authenticate with multiple users is not a common behavior for legitimate user sessions. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Users Failed To Authenticate Using Kerberos - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with 30 unique users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4771 is generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT). Failure code 0x18 stands for `wrong password provided` (the attempted user is a legitimate domain user).\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, missconfigured systems and multi-user systems like Citrix farms.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Multiple Users Remotely Failed To Authenticate From Host - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a source host failing to authenticate against a remote host with 30 unique users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Active Directory environments can be very different depending on the organization. Users should test this detection and customize the arbitrary threshold when needed. Event 4625 documents each and every failed attempt to logon to the local computer. This event generates on domain controllers, member servers, and workstations. Logon Type 3 describes an remote authentication attempt.\
This logic can be used for real time security monitoring as well as threat hunting exercises. This detection will trigger on the host that is the target of the password spraying attack. This could be a domain controller as well as a member server or workstation.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.CM"]}
known_false_positives = A host failing to authenticate with multiple valid users against a remote host is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, remote administration tools, missconfigyred systems, etc.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows New InProcServer32 Added - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to detect the addition of new InProcServer32 registry keys, which could indicate suspicious or malicious activity on a Windows endpoint. The InProcServer32 registry key specifies the path to a COM object that can be loaded into the process space of calling processes. Malware often abuses this mechanism to achieve persistence or execute code by registering a new InProcServer32 key pointing to a malicious DLL. By monitoring for the creation of new InProcServer32 keys, this analytic helps identify potential threats that leverage COM hijacking or similar techniques for execution and persistence. Understanding the normal behavior of legitimate software in your environment will aid in distinguishing between benign and malicious use of InProcServer32 modifications.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.AE"]}
known_false_positives = False positives are expected. Filtering will be needed to properly reduce legitimate applications from the results.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Ngrok Reverse Proxy Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of ngrok.exe being utilized on the Windows operating system. Unfortunately, there is no original file name for Ngrok, so it may be worth an additional hunt to identify any command-line arguments. The sign of someone using Ngrok is not malicious, however, more recently it has become an adversary tool.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1572", "T1090", "T1102"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on organizations that allow the use of Ngrok. Filter or monitor as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows NirSoft AdvancedRun - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of AdvancedRun.exe. AdvancedRun.exe has similar capabilities as other remote programs like psexec. AdvancedRun may also ingest a configuration file with all settings defined and perform its activity. The analytic is written in a way to identify a renamed binary and also the common command-line arguments.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1588.002"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as it is specific to AdvancedRun. Filter as needed based on legitimate usage.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows NirSoft Utilities - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic assists with identifying the proces execution of commonly used utilities from NirSoft. Potentially not adversary behavior, but worth identifying to know if the software is present and being used.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Weaponization"], "mitre_attack": ["T1588.002"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present. Filtering may be required before setting to alert.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Non Discord App Access Discord LevelDB - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects suspicious file access within the Discord LevelDB database. This database contains critical data such as user profiles, messages, guilds, channels, settings, and cached information. Access to this data poses a risk of Discord credential theft or unauthorized access to sensitive information on the compromised system. Detecting such anomalies can serve as an effective pivot to identify non-Discord applications accessing this database, potentially indicating the presence of malware or trojan stealers aimed at data theft.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Non-System Account Targeting Lsass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies non SYSTEM accounts requesting access to lsass.exe. This behavior may be related to credential dumping or applications requiring access to credentials. Triaging this event will require understanding the GrantedAccess from the SourceImage. In addition, whether the account is privileged or not. Review the process requesting permissions and review parallel processes.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Enabling EventCode 10 TargetProcess lsass.exe is required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = False positives will occur based on legitimate application requests, filter based on source image as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Odbcconf Hunting - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies Odbcconf.exe running in the environment to assist with identifying tuning higher fidelity analytics related to Odbcconf.exe.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.008"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present as this is meant to assist with filtering and tuning.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Odbcconf Load DLL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies odbcconf.exe, Windows Open Database Connectivity utility, utilizing the action function of regsvr to load a DLL. An example will look like - odbcconf.exe /A { REGSVR T1218-2.dll }. During triage, review parent process, parallel procesess and file modifications.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.008"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering may need to occur based on legitimate application usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Odbcconf Load Response File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the odbcconf.exe, Windows Open Database Connectivity utility, loading up a resource file. The file extension is arbitrary and may be named anything. The resource file itself may have different commands supported by Odbcconf to load up a DLL (REGSVR) on disk or additional commands. During triage, review file modifications and parallel processes.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.008"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and filtering may need to occur based on legitimate application usage. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Office Product Spawning MSDT - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a Microsoft Office product spawning the Windows msdt.exe process. MSDT is a Diagnostics Troubleshooting Wizard native to Windows. This behavior is related to a recently identified sample utilizing protocol handlers to evade preventative controls, including if macros are disabled in the document. During triage, review file modifications for html. In addition, parallel processes including PowerShell and CertUtil.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, however filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows PaperCut NG Spawn Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect instances where the PaperCut NG application (pc-app.exe) spawns a Windows shell, specifically cmd.exe or PowerShell. This behavior may indicate potential malicious activity, such as an attacker attempting to gain unauthorized access or execute harmful commands on the affected system.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1059", "T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, but most likely not. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Parent PID Spoofing with Explorer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious explorer.exe process that has "/root" process commandline. The presence of this parameter is considered a significant indicator as it could indicate attempts at spoofing the parent process by a specific program or malware. By spoofing the parent process, the malicious entity aims to circumvent detection mechanisms and operate undetected within the system. This technique of manipulating the command-line parameter (/root) of explorer.exe is a form of masquerading utilized by certain malware or suspicious processes. The objective is to obscure the true nature of the activity by imitating a legitimate system process. By doing so, it attempts to evade scrutiny and evade detection by security measures.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1134.004", "T1134"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Password Managers Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line that retrieves information related to password manager software. This technique was seen in several post exploitation tools like winpeas that are being used by Ransomware Prestige to gather this type of information. Password Managers applications are designed to store user credentials, normally in an encrypted database. Credentials are typically accessible after a user provides a master password that unlocks the database. After the database is unlocked, these credentials may be copied to memory. These databases can be stored as files on disk. Due to this password manager software designed adversaries may find or look for keywords related to the Password Manager databases that can be stolen or extracted for further attacks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1555.005"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Phishing Outlook Drop Dll In FORM Dir - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious outlook.exe process dropped a dll file. This technique was seen in CVE-2024-21378, involves the loading of a custom MAPI form to execute a potentially malicious DLL. Detecting such TTPs serves as a crucial pivot point to identify potential adversaries, malware, or red team activity attempting to leverage this method within phishing campaigns.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Phishing PDF File Executes URL Link - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect suspicious pdf viewer processes that have a browser application child processes. This event was seen in a pdf spear phishing attachment containing a malicious URL link to download the actual payload. When a user clicks the malicious link the pdf viewer application will execute a process of the host default browser to connect to the malicious site. This anomaly detection can be a good indicator that a possible pdf file has a link executed by a user. The pdf viewer and browser list in this detection is still in progress, add the common browser and pdf viewer you use in opening pdf in your network.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives in PDF file opened PDF Viewer having legitimate URL link, however filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Phishing Recent ISO Exec Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies registry artifacts when an ISO container is opened, clicked or mounted on the Windows operating system. As Microsoft makes changes to macro based document execution, adversaries have begun to utilize container based initial access based phishing campaigns to evade preventative controls. Once the ISO is clicked or mounted it will create a registry artifact related to this event as a recent application executed or opened.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives may be high depending on the environment and consistent use of ISOs. Restrict to servers, or filter out based on commonly used ISO names. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Possible Credential Dumping - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is an enhanced version of two previous analytics that identifies common GrantedAccess permission requests and CallTrace DLLs in order to detect credential dumping. \
GrantedAccess is the requested permissions by the SourceImage into the TargetImage. \
CallTrace Stack trace of where open process is called. Included is the DLL and the relative virtual address of the functions in the call stack right before the open process call. \
dbgcore.dll or dbghelp.dll  are two core Windows debug DLLs that have minidump functions which provide a way for applications to produce crashdump files that contain a useful subset of the entire process context. \
The idea behind using ntdll.dll is to blend in by using native api of ntdll.dll. For example in sekurlsa module there are many ntdll exported api, like RtlCopyMemory, used to execute this module which is related to lsass dumping.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA. Enabling EventCode 10 TargetProcess lsass.exe is required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.001", "T1003"], "nist": ["DE.CM"]}
known_false_positives = False positives will occur based on GrantedAccess 0x1010 and 0x1400, filter based on source image as needed or remove them. Concern is Cobalt Strike usage of Mimikatz will generate 0x1010 initially, but later be caught.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Post Exploitation Risk Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following correlation identifies a four or more number of distinct analytics associated with the Windows Post-Exploitation analytic story, which enables the identification of potentially suspicious behavior. Windows Post-Exploitation refers to the phase that occurs after an attacker successfully compromises a Windows system. During this stage, attackers strive to maintain persistence, gather sensitive information, escalate privileges, and exploit the compromised environment further. Timely detection of post-exploitation activities is crucial for prompt response and effective mitigation. Common post-exploitation detections encompass identifying suspicious processes or services running on the system, detecting unusual network connections or traffic patterns, identifying modifications to system files or registry entries, monitoring abnormal user account activities, and flagging unauthorized privilege escalations. Ensuring the detection of post-exploitation activities is essential to proactively prevent further compromise, minimize damage, and restore the security of the Windows environment.
how_to_implement = Splunk Enterprise Security is required to utilize this correlation. In addition, modify the source_count value to your environment. In our testing, a count of 4 or 5 was decent in a lab, but the number may need to be increased base on internal testing. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012", "T1049", "T1069", "T1016", "T1003", "T1082", "T1115", "T1552"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers.
providing_technologies = null

[savedsearch://ESCU - Windows PowerShell Add Module to Global Assembly Cache - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following PowerShell Script Block analytic identifies the native ability to add a DLL to the Windows Global Assembly Cache. Each computer where the Common Language Runtime is installed has a machine-wide code cache called the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer. By adding a DLL to the GAC, this allows an adversary to call it via any other means across the operating systems. This is native and built into Windows. Per the Microsoft blog, the more high fidelity method may be to look for W3WP.exe spawning PowerShell that includes the same CommandLine as identified in this analytic.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on developers or third party utilities adding items to the GAC.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Powershell Cryptography Namespace - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104 that is processing cryptography namespace library. This technique was seen in several powershell malware, loader, downloader and stager that will decrypt or decode the next malicious stager or the actual payload. This Anomaly detection can be a good indicator that a powershell process to decrypt code. We recommend to further check the parent_process_name, the file or data it tries to decrypt, network connection and user who execute the script.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerShell Disable HTTP Logging - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analtyic identifies the use of get-WebConfigurationProperty and Set-ItemProperty attempting to disable HTTP logging on windows via PowerShell. Adversaries may perform this action to disable HTTP logging to cover tracks and delete logs on disk.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1562", "T1562.002", "T1505", "T1505.004"], "nist": ["DE.CM"]}
known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerShell Export Certificate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the PowerShell Cmdlet export-certificate utilizing Script Block Logging. This particular behavior is related to an adversary attempting to steal certificates local to the Windows endpoint within the Certificate Store.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.004", "T1552", "T1649"], "nist": ["DE.AE"]}
known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerShell Export PfxCertificate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the PowerShell Cmdlet export-pfxcertificate utilizing Script Block Logging. This particular behavior is related to an adversary attempting to steal certificates local to the Windows endpoint within the Certificate Store.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.004", "T1552", "T1649"], "nist": ["DE.AE"]}
known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerShell Get CIMInstance Remote Computer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the use of Get-CimInstance cmdlet with the -ComputerName parameter, which indicates that the cmdlet is being used to retrieve information from a remote computer. This can be useful for detecting instances of remote access, such as when an attacker uses PowerShell to connect to a remote system and gather information. By monitoring for this cmdlet with the -ComputerName parameter, security analysts can identify potential malicious activity on remote systems and take appropriate action to mitigate any threats.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001"], "nist": ["DE.AE"]}
known_false_positives = This is meant to be a low risk RBA anomaly analytic or to be used for hunting. Enable this with a low risk score and let it generate risk in the risk index.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerShell IIS Components WebGlobalModule Usage - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the usage of PowerShell Cmdlets - New-WebGlobalModule, Enable-WebGlobalModule and Set-WebGlobalModule being utilized to create (new), enable (start) or modify a current IIS Module. These commands are equivalent to AppCmd.exe parameters. Adversaries may utilize these cmdlets as they are lesser known and perform the same activity as AppCmd.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.AE"]}
known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Powershell Import Applocker Policy - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify the imports of Windows PowerShell Applocker commandlets. This technique was seen in Azorult malware where it drops an xml Applocker policy that will deny several AV product and then loaded using PowerShell Applocker commandlet.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1059.001", "T1059", "T1562.001", "T1562"], "nist": ["DE.CM"]}
known_false_positives = administrators may execute this command that may cause some false positive.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Powershell RemoteSigned File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the use of "remotesigned" execution policy for a file. This security setting determines whether PowerShell scripts can be executed on a computer. When the execution policy is set to "remotesigned," it allows locally created scripts to run without any restrictions, but scripts downloaded from the internet must have a digital signature from a trusted publisher.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.AE"]}
known_false_positives = It is possible administrators or scripts may run these commands, filtering may be required.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows PowerShell ScheduleTask - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects potential malicious activities related to PowerShell's task scheduling cmdlets. It looks for anomalies in PowerShell logs, specifically EventCode 4104, associated with script block logging. The analytic flags unusual or suspicious use patterns of key task-related cmdlets such as 'New-ScheduledTask', 'Set-ScheduledTask', and others, which are often used by attackers for persistence and remote execution of malicious code. If a true positive is found, it suggests an possible attacker is attempting to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. To implement this analytic, PowerShell Script Block Logging needs to be enabled on some or all endpoints. Analysts should be aware of benign administrative tasks that can trigger alerts and tune the analytic accordingly to reduce false positives. Upon triage, review the PowerShell logs for any unusual or unexpected cmdlet usage, IP addresses, user accounts, or timestamps. If these factors align with known malicious behavior patterns, immediate mitigation steps, such as isolation of the affected systems, user account changes, and relevant threat hunting activities, should be initiated. This proactive analysis significantly enhances an organization's capacity to swiftly respond to, and potentially prevent, the execution of advanced persistent threats in their network.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1059.001", "T1059"], "nist": ["DE.AE"]}
known_false_positives = Benign administrative tasks can also trigger alerts, necessitating a firm understanding of the typical system behavior and precise tuning of the analytic to reduce false positives.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerShell WMI Win32 ScheduledJob - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the use of the PowerShell script block logging mechanism to detect the use of the Win32_ScheduledJob WMI class. This class allows the creation and management of scheduled tasks on Windows systems. However, due to security concerns, the class has been disabled by default in Windows systems, and its use must be explicitly enabled by modifying the registry. As a result, the detection of the use of this class may indicate malicious activity, especially if the class was enabled on the system by the attacker. Therefore, it is recommended to monitor the use of Win32_ScheduledJob through PowerShell script block logging and to investigate any suspicious activity.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059.001", "T1059"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on legacy applications or utilities. Win32_ScheduledJob uses the Remote Procedure Call (RPC) protocol to create scheduled tasks on remote computers. It uses the DCOM (Distributed Component Object Model) infrastructure to establish a connection with the remote computer and invoke the necessary methods. The RPC service needs to be running on both the local and remote computers for the communication to take place.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerSploit GPP Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of the Get-GPPPassword PowerShell commandlet employed to search for unsecured credentials Group Policy Preferences (GPP). GPP are tools that allow administrators to create domain policies with embedded credentials. These policies allow administrators to set local accounts. These group policies are stored in SYSVOL on a domain controller. This means that any domain user can view the SYSVOL share and decrypt the password (using the AES key that has been made public). While Microsoft released a patch that impedes Administrators to create unsecure credentials, existing Group Policy Preferences files with passwords are not removed from SYSVOL.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552", "T1552.006"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerView AD Access Control List Enumeration - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4104 to identify the execution of the PowerView powershell commandlets `Get-ObjectAcl` or `Get-DomainObjectAcl`. This commandlets are used to enumerate Access Control List permissions given to Active Directory objects. In an active directory environment, an object is an entity that represents an available resource within the organizations network, such as domain controllers, users, groups, computers, shares, etc.  Maintaining Active Directory permissions is complicated and hard to manage, especially in complex and large environments with multiple domains. Weak permissions may allow adversaries and red teamers to escalate their privileges in Active Directory. PowerView is a common tool leveraged by attackers to identify and exploit configuration weaknesses.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.=
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1078.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = Administrators may leverage PowerView for legitimate purposes, filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerView Constrained Delegation Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify commandlets used by the PowerView hacking tool leveraged to discover Windows endpoints with Kerberos Constrained Delegation. Red Teams and adversaries alike may leverage use this technique for situational awareness and Active Directory Discovery.
how_to_implement = The following  analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may leverage PowerView for system management or troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerView Kerberos Service Ticket Request - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainSPNTicket` commandlets with specific parameters. This commandlet is a part of PowerView, a PowerShell tool used to perform enumeration and discovery on Windows Active Directory networks. As the name suggests, this commandlet is used to request the kerberos ticket for a specified service principal name (SPN). Once the ticket is received, it may be cracked using password cracking tools like hashcat to extract the password of the SPN account. Red Teams and adversaries alike may leverage PowerView and these commandlets to identify accounts that can be attacked with the Kerberoasting technique.
how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.CM"]}
known_false_positives = False positive may include Administrators using PowerView for troubleshooting and management.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerView SPN Discovery - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the execution of the `Get-DomainUser` or `Get-NetUSer` commandlets with specific parameters. These commandlets are part of PowerView, a PowerShell tool used to perform enumeration and discovery on Windows Active Directory networks. As the names suggest, these commandlets are used to identify domain users in a network and combining them with the `-SPN` parameter allows adversaries to discover domain accounts associated with a Service Principal Name (SPN). Red Teams and adversaries alike may leverage PowerView and these commandlets to identify accounts that can be attacked with the Kerberoasting technique.
how_to_implement = The following analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558", "T1558.003"], "nist": ["DE.CM"]}
known_false_positives = False positive may include Administrators using PowerView for troubleshooting and management.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows PowerView Unconstrained Delegation Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify commandlets used by the PowerView hacking tool leveraged to discover Windows endpoints with Kerberos Unconstrained Delegation. Red Teams and adversaries alike may leverage use this technique for situational awareness and Active Directory Discovery.
how_to_implement = The following  analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1018"], "nist": ["DE.CM"]}
known_false_positives = Administrators or power users may leverage PowerView for system management or troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Private Keys Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line that retrieves information related to private keys files. This technique was seen in several post exploitation tools like winpeas that are being used by Ransomware Prestige to search for private key certificates on the compromised host for insecurely stored credentials. This files can be used by adversaries to gain privileges, persistence or remote service authentication to collect more sensitive information. Some private keys required password for operation, so in this case adversaries may need to have that passphrase either via keylogging or brute force attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552.004", "T1552"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Privilege Escalation Suspicious Process Elevation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when any low->high integrity level process running from a user account spawns an elevated (high/system integrity) process in a suspicious location or with system level process integrity. This behavior may indicate when a threat actor has successfully elevated privileges.
how_to_implement = Target environment must ingest process execution data sources such as Windows process monitoring and/or Sysmon EID 1.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068", "T1548", "T1134"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated by administrators installing benign applications using run-as/elevation.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Privilege Escalation System Process Without System Parent - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects any system integrity level process that was spawned by a process not running as a system account. This behavior is often seen when attackers successfully escalate privileges to SYSTEM from a user controlled process or service.
how_to_implement = Target environment must ingest sysmon data, specifically Event ID 1 with process integrity and parent user data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068", "T1548", "T1134"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Privilege Escalation User Process Spawn System Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when any process low->high integrity level process spawns a system integrity process from a user controlled location. This behavior is often seen when attackers successfully escalate privileges to SYSTEM from a user controlled process or service.
how_to_implement = Target environment must ingest sysmon data, specifically Event ID 15.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068", "T1548", "T1134"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Process Commandline Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects Windows Management Instrumentation Command-line (WMIC) command used to retrieve information about running processes and specifically fetches the command lines used to launch those processes. This Hunting detection can be a good indicator for possible suspicious user or process getting list of process with its command line using wmic application which is not a common practice for a non-technical user.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1057"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Process Injection In Non-Service SearchIndexer - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a non-service searchindexer.exe process. QakBot, a notorious banking trojan and information stealer, often deploys a process named "searchindexer.exe" as part of its malicious activities. This legitimate Windows process, "Search Indexer," is manipulated by QakBot to masquerade and evade detection within the system. The malware uses this deceptive tactic to camouflage its presence, remaining inconspicuous while performing unauthorized actions like data exfiltration, keystroke logging, and communication with command and control servers. By adopting the guise of a genuine system process, the malicious "searchindexer.exe" process helps QakBot evade scrutiny and continue its malevolent operations without arousing suspicion.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Process Injection into Notepad - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Sysmon to identify process injection into Notepad.exe, based on GrantedAccess requests - 0x40 and 0x1fffff. This particular behavior is attributed to the defaults of the SliverC2 framework by BishopFox. By default, the analytic filters out any SourceImage paths of System32, Syswow64 and program files. Add more as needed, or remove and monitor what is consistently injecting into notepad.exe. This particular behavior will occur from a source image that is the initial payload dropped.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.002"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present based on SourceImage paths. If removing the paths is important, realize svchost and many native binaries inject into notepad consistently. Restrict or tune as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Process Injection Of Wermgr to Known Browser - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies the suspicious Remote Thread execution of wermgr.exe process to "firefox.exe", "chrome.exe" and other known browsers. This technique was seen in Qakbot malware that executes its malicious code by injecting its code in legitimate Windows Operating System processes such as wermgr.exe to steal information in the compromised host. This TTP detection can be a good pivot to detect wermgr.exe process injected with qakbot code that tries to remote thread code execution in known browsers like firefox and edge which is not a common behavior of this wermgr.exe application.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the SourceImage, TargetImage, and EventCode executions from your endpoints related to create remote thread or injecting codes. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055.001", "T1055"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Process Injection Remote Thread - Rule]
type = detection
asset_type = 80
confidence = medium
explanation = The following analytic identifies a suspicious remote thread execution in some process being abused by threat actor and malware like qakbot. Qakbot is one of the malware using this technique to load its malicious dll module or malicious code in the targeted host. This TTP can be a good pivot to verify what is the behavior of the targeted Image process after this detection trigger. look for network connection, child process execution, file access and many more that helps to verify the indication of malware infection.
how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts like remote thread EventCode=8 of sysmon. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.002"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Process Injection Wermgr Child Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious wermgr.exe parent process having a child process not related to error, fault or windows werfault event. This technique was seen in Qakbot malware where it inject its malicious code in wermgr to evade detections and hide from the analyst to execute its recon and its malicious behavior. This Anomaly detection can be a good pivot to start investigating a possible qakbot infection in the network. The Wermgr.exe process is not known to have other child processes aside from itself or werfault.exe
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Process Injection With Public Source Path - Rule]
type = detection
asset_type = 80
confidence = medium
explanation = The following analytic identifies a process in a non-standard file path on Windows attempting to create a remote thread into a process. This Windows API,CreateRemoteThread, is commonly used by adversaries for process injection to evade detections or gain privilege escalation.
how_to_implement = To successfully implement this search, you must be ingesting data that records process activity from your hosts to populate the endpoint data model in the processes node. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055", "T1055.002"], "nist": ["DE.AE"]}
known_false_positives = Some security products or third party applications may utilize CreateRemoteThread, filter as needed before enabling as a notable.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Process With NamedPipe CommandLine - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for process commandline that contains named pipe. This technique was seen in some adversaries, threat actor and malware like olympic destroyer to communicate to its other child processes after process injection that serve as defense evasion and privilege escalation. On the other hand this analytic may catch some normal process that using this technique for example browser application. In that scenario we include common process path we've seen during testing that cause false positive which is the program files. False positive may still be arise if the normal application is in other folder path.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.AE"]}
known_false_positives = Normal browser application may use this technique. Please update the filter macros to remove false positives.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Processes Killed By Industroyer2 Malware - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to look for known processes killed by industroyer2 malware. This technique was seen in the industroyer2 malware attack that tries to kill several processes of windows host machines related to the energy facility network. This anomaly might be a good indicator to check which process kill these processes or why the process was killed.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]}
known_false_positives = False positives are possible if legitimate applications are allowed to terminate this process during testing or updates. Filter as needed based on paths that are used legitimately.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Protocol Tunneling with Plink - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Plink being utilized to proxy egress or laterally in an organization. The analytic is limited to specific Plink options on the command-line, including -R -L and -D which will have the remote and local IP address or port and -l for a username. Modify the options as seen fit for your organization.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1572", "T1021.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if the organization allows for SSH tunneling outbound or internally. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Proxy Via Netsh - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes launching netsh.exe for connection proxy. Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper DLL when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe and executing commands via the command line.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090.001", "T1090"], "nist": ["DE.AE"]}
known_false_positives = Some VPN applications are known to launch netsh.exe. Outside of these instances, it is unusual for an executable to launch netsh.exe and run commands.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Proxy Via Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for processes launching netsh.exe for connection proxy. Netsh is a command-line scripting utility that allows you to, either locally or remotely, display or modify the network configuration of a computer that is currently running. Netsh can be used as a persistence proxy technique to execute a helper DLL when netsh.exe is executed. In this search, we are looking for processes spawned by netsh.exe and executing commands via the command line.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090.001", "T1090"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Query Registry Browser List Application - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious process accessing default internet browsers registry entry. This registry is used by Windows to store information about default internet browsers installed on a system. Malware, adversaries or red-teamers can abuse this registry key to collect data about the installed internet browsers and their associated settings. This information can be used to steal sensitive data such as login credentials, browsing history, and saved passwords. We observed noise that needs to be filter out so we add several known path of Windows Application to make this detection more stable.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = uninstall application may access this registry to remove the entry of the target application. filter is needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Query Registry Reg Save - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of reg.exe with "save" parameter. This reg.exe parameter is commonly being abused by threat actors, adversaries and red-teamers to dump credentials or to check the registry modification capabilities of certain users or administrators in targeted hosts. This approach was seen in post-exploitation tool like winpeas where it uses "reg save" and "reg restore" to check registry modification restriction in targeted host after gaining access to it.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = network administrator can use this command tool to backup registry before updates or modifying critical registries.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Query Registry UnInstall Program List - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious query on uninstall application list in Windows OS registry. This registry  is commonly used by legitimate software to store information about installed applications on a Windows system, such as their name, version, publisher, and installation path. However, malware, adversaries or even red-teamers can abuse this registry key to retrieve information stored in the "Uninstall" key to gather data about installed applications in the target host. This Anomaly detection can be a good pivot to detect a possible suspicious process accessing this registry which is not commonly accessed by a normal user.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1012"], "nist": ["DE.AE"]}
known_false_positives = Uninstall application may access this registry to remove the entry of the target application. Filter is needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Raccine Scheduled Task Deletion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Raccine Rules Updater scheduled task being deleted. Adversaries may attempt to remove this task in order to prevent the update of Raccine.  Raccine is a "ransomware vaccine" created by security researcher Florian Roth, designed to intercept and prevent precursors and active ransomware behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, however filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Rapid Authentication On Multiple Hosts - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4624 to identify a source computer authenticating to a large number of remote endpoints within an Active Directory network. Specifically, the logic will trigger when a source endpoint authenticates to 30 or more target computers within a 5 minute timespan. This behavior could represent an adversary who is moving laterally across the environment or enumerating network shares in the search for sensitive files. As environments differ across organizations, security teams should customize the thresholds of this detection as needed.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003.002"], "nist": ["DE.CM"]}
known_false_positives = Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Rasautou DLL Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows Windows Remote Auto Dialer, rasautou.exe executing an arbitrary DLL. This technique is used to execute arbitrary shellcode or DLLs via the rasautou.exe LOLBin capability. During triage, review parent and child process behavior including file and image loads.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055.001", "T1218", "T1055"], "nist": ["DE.CM"]}
known_false_positives = False positives will be limited to applications that require Rasautou.exe to load a DLL from disk. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Raw Access To Disk Volume Partition - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for suspicious raw access read to device disk partition of the host machine. This technique was seen in several attacks by adversaries or threat actor to wipe, encrypt or overwrite the boot sector of each partition as part of their impact payload for example the "hermeticwiper" malware. This detection is a good indicator that there is a process try to read or write on boot sector.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1561.002", "T1561"], "nist": ["DE.AE"]}
known_false_positives = This event is really notable but we found minimal number of normal application from system32 folder like svchost.exe accessing it too. In this case we used 'system32' and 'syswow64' path as a filter for this detection.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Raw Access To Master Boot Record Drive - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for suspicious raw access read to drive where the master boot record is placed. This technique was seen in several attacks by adversaries or threat actor to wipe, encrypt or overwrite the master boot record code as part of their impact payload. This detection is a good indicator that there is a process try to read or write on MBR sector.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the raw access read event (like sysmon eventcode 9), process name and process guid from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1561.002", "T1561"], "nist": ["DE.CM"]}
known_false_positives = This event is really notable but we found minimal number of normal application from system32 folder like svchost.exe accessing it too. In this case we used 'system32' and 'syswow64' path as a filter for this detection.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows RDP Connection Successful - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies successful remote desktop connections. Utilize this analytic to hunt for successful attempts. In addition, the query may be modified for EventCode=1148 to potentially identify failed attempts. In testing, 1148 would not generate based on a failed logon attempt. Note this analytic requires enabling and a stanza in a inputs.conf.
how_to_implement = The following analyic requires the WIndows TerminalServices RemoteConnectionManager Operational log to be enabled and ingested into Splunk. For the inputs, review https://gist.github.com/MHaggis/138c6bf563bacbda4a2524f089773706.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1563.002"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present, filter as needed or restrict to critical assets on the perimeter.
providing_technologies = null

[savedsearch://ESCU - Windows Registry BootExecute Modification - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic monitors the BootExecute registry key for any modifications from its default value, which could indicate potential malicious activity. The BootExecute registry key, located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager, manages the list of applications and services that are executed during system boot. By default, the BootExecute value is set to "autocheck autochk *". Attackers might attempt to modify this value to achieve persistence, load malicious code, or tamper with the system's boot process.
how_to_implement = To successfully implement this search you need to be ingesting information on Windows Registry that include the name of the path and key responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542", "T1547.001"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and will need to be filtered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Registry Certificate Added - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies installation of a root CA certificate by monitoring the registry. The base paths may be found [here](https://gist.github.com/mattifestation/75d6117707bcf8c26845b3cbb6ad2b6b/raw/ae65ef15c706140ffc2e165615204e20f2903028/RootCAInstallationDetection.xml). In short, there are specific certificate registry paths that will be written to (SetValue) when a new certificate is added. The high-fidelity events to pay attention to are SetValue events where the TargetObject property ends with "<THUMBPRINT_VALUE>\Blob" as this indicates the direct installation or modification of a root certificate binary blob. The other high fidelity reference will be which process is making the registry modifications. There are very few processes that modify these day to day, therefore monitoring for all to start (hunting) provides a great beginning.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Processes` and `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.004", "T1553"], "nist": ["DE.AE"]}
known_false_positives = False positives will be limited to a legitimate business applicating consistently adding new root certificates to the endpoint. Filter by user, process, or thumbprint.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Registry Delete Task SD - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process attempting to delete a scheduled task SD (Security Descriptor) from within the registry path of that task. This may occur from a non-standard process running and may not come from reg.exe. This particular behavior will remove the actual Task Name from the Task Scheduler GUI and from the command-line query - schtasks.exe /query. In addition, in order to perform this action, the user context will need to be SYSTEM.\ Identifying the deletion of a scheduled task's Security Descriptor from the registry is significant for a SOC as it may indicate malicious activity attempting to remove evidence of a scheduled task, potentially for defense evasion purposes. If a true positive is detected, it suggests an attacker with privileged access attempting to remove traces of their activities, which can have a significant impact on the security and functionality of affected systems. Immediate investigation and response are required to mitigate further risks and preserve the integrity of the environment.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1562"], "nist": ["DE.AE"]}
known_false_positives = False positives should be limited as the activity is not common to delete ONLY the SD from the registry. Filter as needed. Update the analytic Modified or Deleted values based on product that is in the datamodel.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Registry Modification for Safe Mode Persistence - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a modification or registry add to the safeboot registry as an autostart mechanism. This technique is utilized by adversaries to persist a driver or service into Safe Mode. Two keys are monitored in this analytic,  Minimal and Network. adding values to Minimal will load into Safe Mode and by adding into Network it will provide the service or drive the ability to perform network connections in Safe Mode.
how_to_implement = To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black or endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report reads and writes to the registry.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.001", "T1547"], "nist": ["DE.CM"]}
known_false_positives = updated windows application needed in safe boot may used this registry
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Registry Payload Injection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when suspiciouly long data is written to the registry. This behavior is often associated with certain fileless malware threats or persistence techniques used by threat actors. Data stored in the registy is considered fileless since it does not get written to disk and is traditionally not well defended since normal users can modify thier own registry.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027", "T1027.011"], "nist": ["DE.CM"]}
known_false_positives = Unknown, possible custom scripting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Registry SIP Provider Modification - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic detects modifications to the Windows Registry SIP Provider. It identifies this behavior by monitoring Sysmon Event ID 7, which logs registry modification events. The analytic specifically looks for changes in registry paths and values associated with Cryptography Providers and OID Encoding Types. This behavior is worth identifying as it may indicate an attempt to subvert trust controls, a technique often used by adversaries to bypass security measures and maintain persistence in an environment. If a true positive is found, it suggests an attacker is trying to manipulate the system's cryptographic functions, potentially leading to unauthorized access, data theft, or other damaging outcomes. Upon triage, review the registry paths and values modified, and look for concurrent processes to identify the attack source. Review the path of the SIP being added. This approach helps analysts detect potential threats earlier and mitigate the risks.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.003"], "nist": ["DE.CM"]}
known_false_positives = Be aware of potential false positives - legitimate applications may cause benign activities to be flagged.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Regsvr32 Renamed Binary - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies renamed instances of regsv32.exe executing. regsv32.exe is natively found in C:\Windows\system32 and C:\Windows\syswow64. During investigation, validate if it is the legitimate regsv32.exe executing and what dll module content it is loading. This query relies on the original filename or internal name from the PE meta data. Expand the query as needed by looking for specific command line arguments outlined in other analytics.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.010", "T1218"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Access Software BRC4 Loaded Dll - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following anomaly detection identifies the behavior related to 4 native Windows DLLs being loaded by a non-standard process. Identified by MDSec during their research into Brute Ratel, MDSec identified a high signal analytic by calling out these 4 DLLs being loaded into a process. LogonCLI.dll is the Net Logon Client DLL and is related to users and other domain services to get authenticated. Credui.dll is Credential Manager User Interface. Credential managers receive notifications when authentication information changes. For example, credential managers are notified when a user logs on or an account password changes. Samcli.dll is the Security Accounts Manager Client DLL. Adversaries may attempt to extract credential material from the Security Account Manager (SAM) database either through in-memory techniques or through the Windows Registry where the SAM database is stored. Dbghelp.dll is Windows Image Helper. Windows Image Helper is commonly seen in credential dumping due to native functions. All of these modules are important to monitor and track and combined may lead to credentail access or dumping.
how_to_implement = The latest Sysmon TA 3.0 https://splunkbase.splunk.com/app/5709 will add the ImageLoaded name to the process_name field, allowing this query to work. Use as an example and implement for other products.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control", "Exploitation"], "mitre_attack": ["T1219", "T1003"], "nist": ["DE.AE"]}
known_false_positives = This module can be loaded by a third party application. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Remote Access Software Hunt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic is meant to help organizations understand what remote access software is being used in the environment. When reviewing this hunt, confirm the software identified is authorized to be utilized. Based on fidelity, create a new analytic for specific utilities banned within the organization. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = False positives will be found. Filter as needed and create higher fidelity analytics based off banned remote access software.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Access Software RMS Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification or creation of Windows registry related to the Remote Manipulator System (RMS) Remote Admin tool. RMS is a legitimate tool developed by russian organization TektonIT and has been observed being abused by adversaries to gain remote access to the targeted host. Azorult malware utilized RMS to gain remote access.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.CM"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Assistance Spawning Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of Microsoft Remote Assistance, msra.exe, spawning PowerShell.exe or cmd.exe as a child process. Msra.exe by default has no command-line arguments and typically spawns itself. It will generate a network connection to the remote system that is connected. This behavior is indicative of another process injected into msra.exe. Review the parent process or cross process events to identify source.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, filter as needed. Add additional shells as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Create Service - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies an endpoint that remotely connects to another endpoint to create a new service using sc.exe. On the remote endpoint, the new service will be created and this action will trigger the creation of EventCode 7045 along with all the resulting service information.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.AE"]}
known_false_positives = Note that false positives may occur, and filtering may be necessary, especially when it comes to remote service creation by administrators or software management utilities.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Service Rdpwinst Tool Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies RDPWInst.exe tool, which is a RDP wrapper library tool designed to enable remote desktop host support and concurrent RDP session on reduced functionality system. Unfortunately, this open project was abused by adversaries to enable RDP connection to the targeted host for remote access and potentially be for lateral movement.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]}
known_false_positives = This tool was designed for home usage and not commonly seen in production environment. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Services Allow Rdp In Firewall - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows firewall to enable remote desktop protocol on a targeted machine. This technique was seen in several adversaries, malware or red teamer to remotely access the compromised or targeted host by allowing this protocol in firewall. Even this protocol might be allowed in some production environment, This TTP behavior is a good pivot to check who and why the user want to enable this feature through firewall which is also common traits of attack to start lateral movement.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Services Allow Remote Assistance - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows registry to enable remote desktop assistance on a targeted machine. This technique was seen in several adversaries, malware or red teamer like azorult to remotely access the compromised or targeted host by enabling this protocol in registry. Even this protocol might be allowed in some production environment, This Anomaly behavior is a good pivot to check who and why the user want to enable this feature through registry which is un-common. And as per stated in microsoft documentation the default value of this registry is false that makes this a good indicator of suspicious behavior.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Remote Services Rdp Enable - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is to identify a modification in the Windows registry to enable remote desktop protocol on a targeted machine. This technique was seen in several adversaries, malware or red teamer to remotely access the compromised or targeted host by enabling this protocol in registry. Even this protocol might be allowed in some production environment, This TTP behavior is a good pivot to check who and why the user want to enable this feature through registry which is un-common.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]}
known_false_positives = administrators may enable or disable this feature that may cause some false positive.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Replication Through Removable Media - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is developed to detect suspicious executable or script files created or dropped in the root drive of a targeted host. This technique is commonly used by threat actors, adversaries or even red teamers to replicate or spread in possible removable drives. Back then, WORM malware was popular for this technique where it would drop a copy of itself in the root drive to be able to spread or to have a lateral movement in other network machines. Nowadays, Ransomware like CHAOS ransomware also use this technique to spread its malicious code in possible removable drives. This TTP detection can be a good indicator that a process might create a persistence technique or lateral movement of a targeted machine. We suggest checking the process name that creates this event, the file created, user type, and the reason why that executable or scripts are dropped in the root drive.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Exploitation"], "mitre_attack": ["T1091"], "nist": ["DE.CM"]}
known_false_positives = Administrators may allow creation of script or exe in the paths specified. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Root Domain linked policies Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes PowerShell Script Block Logging (EventCode=4104) to identify the `[Adsisearcher]` type accelerator being used to query Active Directory for domain groups. Red Teams and adversaries may leverage `[Adsisearcher]` to enumerate root domain linked policies for situational awareness and Active Directory Discovery.
how_to_implement = The following Hunting analytic requires PowerShell operational logs to be imported. Modify the powershell macro as needed to match the sourcetype or add index. This analytic is specific to 4104, or PowerShell Script Block Logging.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1087"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Rundll32 Apply User Settings Changes - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious rundll32 commandline to update a user's system parameters related to desktop backgrounds, display settings, and visual themes. Specifically, it triggers the system to refresh and apply changes to the user-specific settings, such as wallpaper modifications or visual theme updates, ensuring that the changes take effect without the need to restart the system or log out and log back in. This technique was seen in Rhysida Ransomware and script as part of its defense evasion. This technique is not a common practice to lock a screen and maybe a good indicator of compromise. This command could also potentially be exploited by malware to disguise its activities or make unauthorized changes to a user's system settings without their knowledge or consent.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218", "T1218.011"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Rundll32 WebDAV Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe with the commandline arguments loading davclnt.dll function - davsetcookie - to be used to access a remote WebDav instance. This particular behavior was recently showcased in CVE-2023-23397.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present based on legitimate software, filtering may need to occur.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Rundll32 WebDav With Network Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies rundll32.exe with the commandline arguments loading davclnt.dll function - davsetcookie - to be used to access a remote WebDav instance. The analytic attempts to use join from Processes and All_Traffic to identify the network connection. This particular behavior was recently showcased in CVE-2023-23397.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present based on legitimate software, filtering may need to occur.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Scheduled Task Created Via XML - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of suspicious scheduled tasks in Windows, specifically tasks created using schtasks.exe with the -create flag and an XML parameter in the command-line. This technique is commonly employed by threat actors, adversaries, and red teamers to establish persistence or achieve privilege escalation on targeted hosts. Notably, malware like Trickbot and Winter-Vivern have been observed using XML files to create scheduled tasks. Monitoring and investigating this activity is crucial to mitigate potential security risks. It is important to be aware that scripts or administrators may trigger this analytic, leading to potential false positives. To minimize false positives, adjust the filter based on the parent process or application.\
When a true positive is detected, it suggests an attacker's attempt to gain persistence or execute additional malicious payloads, potentially resulting in data theft, ransomware, or other damaging outcomes. During triage, review the source of the scheduled task, the command to be executed, and capture any relevant on-disk artifacts. Analyze concurrent processes to identify the source of the attack. This analytic enables analysts to detect and respond to potential threats early, mitigating the associated risks effectively.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = It is possible scripts or administrators may trigger this analytic. Filter as needed based on parent process, application.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Scheduled Task Service Spawned Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when the Task Scheduler service "svchost.exe -k netsvcs -p -s Schedule" is the parent process to common command line, scripting, or shell execution binaries. Attackers often abuse the task scheduler service with these binaries as an execution and persistence mechanism in order to blend in with normal Windows operations. This TTP is also commonly seen for legitimate purposes such as business scripts or application updates.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1059"], "nist": ["DE.CM"]}
known_false_positives = Unknown, possible custom scripting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Scheduled Task with Highest Privileges - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of a new task with the highest execution privilege via Schtasks.exe. This tactic is often observed in AsyncRAT attacks, where the scheduled task is used for persistence and privilege escalation. AsyncRAT sets up a scheduled task with parameters '/rl' and 'highest', triggering this technique. It's a strong indicator of potential malware or adversaries seeking to establish persistence and escalate privileges through scheduled tasks. This is crucial for a Security Operations Center (SOC) as it can prevent unauthorized system access and potential data breaches.\
The analytic works by monitoring logs for process name, parent process, and command-line executions. In the presence of the '*/rl ' and ' highest *' commands in a schtasks.exe process, an alert is triggered.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053", "T1053.005"], "nist": ["DE.CM"]}
known_false_positives = False positives may arise from legitimate applications that create tasks to run as SYSTEM. Therefore, it's recommended to adjust filters based on parent process or modify the query to include world writable paths for restriction.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Schtasks Create Run As System - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the creation of a new task to start and run as an elevated user - SYSTEM using Schtasks.exe. This behavior is commonly used by adversaries to spawn a process in an elevated state. If a true positive is found, it suggests an attacker is attempting to persist within the environment or potentially deliver additional malicious payloads, leading to data theft, ransomware, or other damaging outcomes. Upon triage, review the scheduled task's source and the command to be executed. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = False positives will be limited to legitimate applications creating a task to run as SYSTEM. Filter as needed based on parent process, or modify the query to have world writeable paths to restrict it.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Screen Capture Via Powershell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a potential PowerShell script that captures screen images on compromised or targeted hosts. This technique was observed in the Winter-Vivern malware, which attempts to capture desktop screens using a PowerShell script and send the images to its C2 server as part of its exfiltration strategy. This TTP serves as a useful indicator that a PowerShell process may be gathering desktop screenshots from a host system, potentially signaling malicious activity.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1113"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Security Account Manager Stopped - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The search looks for a Windows Security Account Manager (SAM) was stopped via command-line. This is consistent with Ryuk infections across a fleet of endpoints.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]}
known_false_positives = SAM is a critical windows service, stopping it would cause major issues on an endpoint this makes false positive rare. AlthoughNo false positives have been identified.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Security Support Provider Reg Query - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line related to the discovery of possible Security Support Providers in the registry. This technique is being abused by adversaries or post exploitation tools like winpeas to gather LSA protection and configuration in the registry in the targeted host. This registry entry can contain several information related to LSA that validates users for local and remote sign-ins and enforces local security policies. Understanding LSA protection may give a good information in accessing LSA content in memory which is commonly attack by adversaries and tool like mimikatz to scrape password hashes or clear plain text passwords.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.005", "T1547"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Server Software Component GACUtil Install to GAC - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the Windows SDK utility - GACUtil.exe, being utilized to add a DLL into the Global Assembly Cache (GAC). Each computer where the Common Language Runtime is installed has a machine-wide code cache called the Global Assembly Cache. The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer. By adding a DLL to the GAC, this allows an adversary to call it via any other means across the operating systems. As outlined by Microsoft in their blog, it is not common to see this spawning from W3WP.exe, however, in a non-development environment it may not be common at all. Note that in order to utilize GACutil.exe, The Windows SDK must be installed, this is not a native binary.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1505", "T1505.004"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if gacutil.exe is utilized day to day by developers. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Create Kernel Mode Driver - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifes a new kernel driver being added to Windows using sc.exe. Adding a Kernel driver is not common day to day and should be investigated to further understand the source.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003", "T1543", "T1068"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on common applications adding new drivers, however, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Create RemComSvc - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies RemComSvc installed on an endpoint. This typically occurs when someone is moving laterally with RemCom.exe.
how_to_implement = To implement this analytic, the Windows EventCode 7045 will need to be logged. The Windows TA for Splunk is also recommended.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003", "T1543"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filter as needed based on administrative activity.
providing_technologies = null

[savedsearch://ESCU - Windows Service Create SliverC2 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = When an adversary utilizes SliverC2 to laterally move with the Psexec module, it will create a service with the name and description of "Sliver" and "Sliver Implant". Note that these may be easily changed and are specific to only SliverC2. We have also created the same regex as Microsoft has outlined to attempt to capture the suspicious service path (regex101 reference).
how_to_implement = To implement this analytic, the Windows EventCode 7045 will need to be logged from the System Event log. The Windows TA for Splunk is also recommended.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, but if another service out there is named Sliver, filtering may be needed.
providing_technologies = null

[savedsearch://ESCU - Windows Service Create with Tscon - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects potential RDP Hijacking attempts by monitoring a series of actions taken by an attacker to gain unauthorized access to a remote system. The attacker first runs the quser command to query the remote host for disconnected user sessions. Upon identifying a disconnected session, they use the sc.exe command to create a new Windows service with a binary path that launches tscon.exe. By specifying the disconnected session ID and a destination ID, the attacker can transfer the disconnected session to a new RDP session, effectively hijacking the user's session. This analytic allows security teams to detect and respond to RDP Hijacking attempts, mitigating potential risks and impacts on targeted systems.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1563.002", "T1563", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = False positives may arise in the RDP Hijacking analytic when legitimate administrators access remote sessions for maintenance or troubleshooting purposes. These activities might resemble an attacker''s attempt to hijack a disconnected session, leading to false alarms. To mitigate the risk of false positives and improve the overall security posture, organizations can implement Group Policy to automatically disconnect RDP sessions when they are complete. By enforcing this policy, administrators ensure that disconnected sessions are promptly terminated, reducing the window of opportunity for an attacker to hijack a session. Additionally, organizations can also implement access control mechanisms and monitor the behavior of privileged accounts to further enhance security and reduce the chances of false positives in RDP Hijacking detection.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Created with Suspicious Service Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytics uses Windows Event Id 7045, `New Service Was Installed`, to identify the creation of a Windows Service where the service binary path path is located in a non-common Service folder in Windows. Red Teams and adversaries alike may create malicious Services for lateral movement or remote code execution as well as persistence and execution. The Clop ransomware has also been seen in the wild abusing Windows services.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1569", "T1569.002"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may install services with uncommon services paths.
providing_technologies = null

[savedsearch://ESCU - Windows Service Created Within Public Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytc uses Windows Event Id 7045, `New Service Was Installed`, to identify the creation of a Windows Service where the service binary path is located in public paths. This behavior could represent the installation of a malicious service. Red Teams and adversaries alike may create malicious Services for lateral movement or remote code execution
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may install services with uncommon services paths.
providing_technologies = null

[savedsearch://ESCU - Windows Service Creation on Remote Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `sc.exe` with command-line arguments utilized to create a Windows Service on a remote endpoint. Red Teams and adversaries alike may abuse the Service Control Manager for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may create Windows Services on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Creation Using Registry Entry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when reg.exe modify registry keys that define Windows services and their configurations in Windows to detect potential threats earlier and mitigate the risks. This detection is made by a Splunk query that searches for specific keywords in the process name, parent process name, user, and process ID. This detection is important because it suggests that an attacker has modified the registry keys that define Windows services and their configurations, which can allow them to maintain access to the system and potentially move laterally within the network. It is a common technique used by attackers to gain persistence on a compromised system and its impact can lead to data theft, ransomware, or other damaging outcomes. False positives can occur since legitimate uses of reg.exe to modify registry keys for Windows services can also trigger this alert. Next steps include reviewing the process and user context of the reg.exe activity and identify any other concurrent processes that might be associated with the attack upon triage.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the registry value name, registry path, and registry value data from your endpoints. If you are using Sysmon, you must have at least version 2.0 of the offical Sysmon TA. https://splunkbase.splunk.com/app/5709
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.011"], "nist": ["DE.CM"]}
known_false_positives = Third party tools may used this technique to create services but not so common.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Deletion In Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a service being deleted from the Windows Registry under CurrentControlSet\Services. Adversaries may delete a service as part of defense evasion.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. Also make sure that this registry was included in your config files ex. sysmon config to be monitored.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]}
known_false_positives = This event can be seen when administrator delete a service or uninstall/reinstall a software that creates service entry, but it is still recommended to check this alert with high priority.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Initiation on Remote Endpoint - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `sc.exe` with command-line arguments utilized to start a Windows Service on a remote endpoint. Red Teams and adversaries alike may abuse the Service Control Manager for lateral movement and remote code execution.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543", "T1543.003"], "nist": ["DE.CM"]}
known_false_positives = Administrators may start Windows Services on remote systems, but this activity is usually limited to a small set of hosts or users.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Stop By Deletion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies Windows Service Control, `sc.exe`, attempting to delete a service. This is typically identified in parallel with other instances of service enumeration of attempts to stop a service and then delete it. Adversaries utilize this technique to terminate security services or other related services to continue there objective and evade detections.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]}
known_false_positives = It is possible administrative scripts may start/stop/delete services. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Stop Via Net  and SC Application - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies suspicious attempts to stop services on a system using either `net.exe` or `sc.exe`. This technique is used by adversaries to terminate security services or other related services to continue their objective and evade detections. This technique is also commonly used by ransomware threat actors to successfully encrypt databases or files being processed or used by Windows OS Services.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]}
known_false_positives = Windows OS or software may stop and restart services due to some critical update.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Service Stop Win Updates - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a windows update service being disabled in Windows OS. This technique is being abused by adversaries or threat actors to add defense mechanisms to their malware implant in the targeted host. Disabling windows update will put the compromised host vulnerable in some zero day exploit or even some update features against threats. RedLine Stealer kills this service as part of its defense evasion mechanism.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints (like Windows system.log Event ID 7040)
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.AE"]}
known_false_positives = Network administrator may disable this services as part of its audit process within the network. Filter is needed.
providing_technologies = null

[savedsearch://ESCU - Windows SIP Provider Inventory - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following inventory analytic is used with a PowerShell scripted inputs to capture all SIP providers on a Windows system. This analytic is used to identify potential malicious SIP providers that may be used to subvert trust controls. Upon review, look for new and non-standard paths for SIP providers.
how_to_implement = To implement this analytic, one must first perform inventory using a scripted inputs. Review the following Gist - https://gist.github.com/MHaggis/75dd5db546c143ea67703d0e86cdbbd1
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.003"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited as this is a hunting query for inventory.
providing_technologies = null

[savedsearch://ESCU - Windows SIP WinVerifyTrust Failed Trust Validation - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic utilizes a Windows Event Log - CAPI2 - or CryptoAPI 2, to identify failed trust validation. Typically, this event log is meant for diagnosing PKI issues, however is a great source to identify failed trust validation. Note that this event log is noisy as it captures common PKI requests from many different processes. EventID 81 is generated anytime a trust validation fails. The description for EventID 81 is "The digital signature of the object did not verify." STRT tested this analytic using Mimikatz binary.
how_to_implement = To implement this analytic, one will need to enable the Microsoft-Windows-CAPI2/Operational log within the Windows Event Log. Note this is a debug log for many purposes, and the analytic only focuses in on EventID 81. Review the following gist for additional enabling information.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1553.003"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present in some instances of legitimate binaries with invalid signatures. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Snake Malware File Modification Crmlog - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identfies a .crmlog written to windows\registration. Per the report, typically, this file has been found within the %windows%\Registration directory with the format of <RANDOM_GUID>.<RANDOM_GUID>.crmlog and is decrypted by Snake's kernel driver.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1027"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present as the file pattern does match legitimate files on disk. It is possible other native tools write the same file name scheme.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Snake Malware Kernel Driver Comadmin - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the comadmin.dat file written to disk, which is related to Snake Malware. From the report, Snakes installer drops the kernel driver and a custom DLL which is used to load the driver into a single AES encrypted file on disk. Typically, this file is named comadmin.dat and is stored in the %windows%\system32\Com directory.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.006"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Snake Malware Registry Modification wav OpenWithProgIds - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The follow analytic identifies the registry being modified at .wav\\OpenWithProgIds\, which is related to the Snake Malware campaign. Upon execution, Snake's WerFault.exe will attempt to decrypt an encrypted blob within the Windows registry that is typically found at HKLM:\SOFTWARE\Classes\.wav\OpenWithProgIds. The encrypted data includes the AES key, IV, and path that is used to find and decrypt the file containing Snake's kernel driver and kernel driver loader.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the process responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Registry` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1112"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present and will require tuning based on program Ids in large organizations.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Snake Malware Service Create - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a new service WerFaultSvc being created with a binary path located in the windows winsxs path. Per the report, the Snake version primarily discussed in this advisory registers a service to maintain persistence on a system. Typically this service is named WerFaultSvc which we assess was used to blend in with the legitimate Windows service WerSvc. On boot, this service will execute Snakes WerFault.exe, which Snake developers chose to hide among the numerous valid Windows WerFault.exe files in the windows WinSxS directory. Executing WerFault.exe will start the process of decrypting Snakes components and loading them into memory.
how_to_implement = To successfully implement this search, you need to be ingesting Windows System logs with the Service name, Service File Name Service Start type, and Service Type from your endpoints.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1547.006", "T1569.002"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this is a strict primary indicator used by Snake Malware.
providing_technologies = null

[savedsearch://ESCU - Windows SOAPHound Binary Execution - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the common command-line argument used by SOAPHound `soaphound.exe`. Being the script is publicly available, function names may be modified, but these changes are dependent upon the operator. In most instances the defaults are used. It does not cover the entirety of every argument in order to avoid false positives.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087.002", "T1069.001", "T1482", "T1087.001", "T1087", "T1069.002", "T1069"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as the command-line arguments are specific to SOAPHound. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Spearphishing Attachment Connect To None MS Office Domain - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = this detection was designed to identifies suspicious office documents that connect to a website aside from Microsoft Office Domain. This technique was seen in several malicious documents that abuses .rels xml properties of MS office to connect or download malicious files. This hunting query can be a good pivot or guide to check what URL link it tries to connect, what domain, where the documents came from and how the connection happens.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.AE"]}
known_false_positives = Windows Office document may contain legitimate url link other than MS office Domain. filter is needed
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Spearphishing Attachment Onenote Spawn Mshta - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies the latest behavior utilized by different malware families (including TA551, AsyncRat, Redline and DCRAT). This detection identifies onenote Office Product spawning `mshta.exe`. In malicious instances, the command-line of `mshta.exe` will contain the `hta` file locally, or a URL to the remote destination. In addition, Threat Research has released a detections identifying suspicious use of `mshta.exe`. In this instance, we narrow our detection down to the Office suite as a parent process. During triage, review all file modifications. Capture and analyze any artifacts on disk. The Office Product, or `mshta.exe` will have reached out to a remote destination, capture and block the IPs or domain. Review additional parallel processes for further activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566.001", "T1566"], "nist": ["DE.CM"]}
known_false_positives = No false positives known. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Special Privileged Logon On Multiple Hosts - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Event ID 4672 to identify a source user authenticating with special privileges across a large number remote endpoints. Specifically, the logic will trigger when a source user obtains special privileges across 30 or more target computers within a 5 minute timespan. Special privileges are assigned to a new logon session when sensitive privileges like SeDebugPrivilege and SeImpersonatePrivilege are assigned. This behavior could represent an adversary who is moving laterally and executing remote code across the network. It can also be triggered by other behavior like an adversary enumerating network shares. As environments differ across organizations, security teams should customize the thresholds of this detection as needed.
how_to_implement = To successfully implement this search, you need to be ingesting special logon events. The Advanced Security Audit policy setting `Audit Special Logon` within `Logon/Logoff` need to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1087", "T1021.002", "T1135"], "nist": ["DE.CM"]}
known_false_positives = Vulnerability scanners or system administration tools may also trigger this detection. Filter as needed.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows SQL Spawning CertUtil - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the use of certutil to download software, a behavior exhibited by the threat actor Flax Typhoon. This actor deploys a VPN connection by downloading an executable file for SoftEther VPN from their network infrastructure using one of several LOLBins, including certutil. The actor then uses the Service Control Manager (SCM) to create a Windows service that launches the VPN connection automatically when the system starts. This behavior allows the actor to monitor the availability of the compromised system and establish an RDP connection. This analytic identifies this behavior by monitoring for the use of certutil in conjunction with the downloading of software. This behavior is worth identifying for a SOC as it indicates a potential compromise of the system and the establishment of a persistent threat. If a true positive is found, it suggests an attacker has gained access to the environment and is attempting to maintain that access, potentially leading to further malicious activities such as data theft or ransomware attacks. Be aware of potential false positives - legitimate uses of certutil in your environment may cause benign activities to be flagged. Upon triage, review the command executed and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = The occurrence of false positives should be minimal, given that the SQL agent does not typically download software using CertUtil.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows SqlWriter SQLDumper DLL Sideload - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the abuse of SqlWriter and SQLDumper executables to sideload the vcruntime140.dll library. This technique is commonly used by adversaries to load malicious code into a legitimate process. The analytic searches for EventCode 7 from Sysmon logs where the Image is either SQLDumper.exe or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading of vcruntime140.dll from the System32 directory to reduce false positives.
how_to_implement = The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The analytic searches for EventCode 7 where the Image is either SQLDumper.exe or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading of vcruntime140.dll from the System32 directory to reduce false positives. The analytic can be modified to include additional known good paths for vcruntime140.dll to further reduce false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible if legitimate processes are loading vcruntime140.dll from non-standard directories. It is recommended to investigate the context of the process loading vcruntime140.dll to determine if it is malicious or not. Modify the search to include additional known good paths for vcruntime140.dll to reduce false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Steal Authentication Certificates - ESC1 Abuse - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when a new certificate is requested and/or granted against the Active Directory Certificate Services (AD CS) using a Subject Alternative Name (SAN). This action by its self is not malicious, however improperly configured certificate templates can be abused to permit privilege escalation and environment compromise due to over permissive settings (AD CS ESC1)
how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. Recommend throttle correlation by RequestId/ssl_serial at minimum.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated in environments where administrative users or processes are allowed to generate certificates with Subject Alternative Names. Sources or templates used in these processes may need to be tuned out for accurate function.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Steal Authentication Certificates - ESC1 Authentication - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when a suspicious certificate is granted using Active Directory Certificate Services (AD CS) with a Subject Alternative Name (SAN) and then immediately used for authentication. This action alone may not be malicious, however improperly configured certificate templates can be abused to permit privilege escalation and environment compromise due to over permissive settings (AD CS ESC1).
how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference. Recommend throttle correlation by RequestId/ssl_serial at minimum.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649", "T1550"], "nist": ["DE.CM"]}
known_false_positives = False positives may be generated in environments where administrative users or processes are allowed to generate certificates with Subject Alternative Names for authentication. Sources or templates used in these processes may need to be tuned out for accurate function.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Steal Authentication Certificates Certificate Issued - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when a new certificate is issued against the Certificate Services - AD CS. By its very nature this is not malicious, but should be tracked and correlated with other events related to certificates being issued. When the CA issues the certificate, it creates EID 4887 'Certificate Services approved a certificate request and issued a certificate". The event supplies the requester user context, the DNS hostname of the machine they requested the certificate from, and the time they requested the certificate. The attributes fields in these event commonly has values for CDC, RMD, and CCM which correspond to Client DC, Request Machine DNS name, and Cert Client Machine, respectively.
how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives will be generated based on normal certificates issued. Leave enabled to generate Risk, as this is meant to be an anomaly analytic.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Steal Authentication Certificates Certificate Request - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when a new certificate is requested against the Certificate Services - AD CS. By its very nature this is not malicious, but should be tracked and correlated with other events related to certificate requests. When an account requests a certificate, the CA generates event ID (EID) 4886 "Certificate Services received a certificate request".
how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 115 of first reference.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives will be generated based on normal certificate requests. Leave enabled to generate Risk, as this is meant to be an anomaly analytic.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Steal Authentication Certificates CertUtil Backup - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is focused on CertUtil.exe performing a backup of the Certificate Store. Typically, administrators may perform this task to migrate or perform backups of the store, however it may be found uncommon in most organizations.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives will be generated based on normal certificate store backups. Leave enabled to generate Risk, as this is meant to be an anomaly analytic. If CS backups are not normal, enable as TTP.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Steal Authentication Certificates CryptoAPI - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes a Windows Event Log - CAPI2 - or CryptoAPI 2, to identify suspicious certificate extraction. Typically, this event log is meant for diagnosing PKI issues, however is a great source to identify certificate exports. Note that this event log is noisy as it captures common PKI requests from many different processes. EventID 70 is generated anytime a certificate is exported. The description for EventID 70 is "Acquire Certificate Private Key". STRT tested this analytic using Mimikatz binary and the implementation of Mimikatz in Cobalt Strike.
how_to_implement = To implement this analytic, one will need to enable the Microsoft-Windows-CAPI2/Operational log within the Windows Event Log. Note this is a debug log for many purposes, and the analytic only focuses in on EventID 70. Review the following gist for additional enabling information.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present in some instances of legitimate applications requiring to export certificates. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Windows Steal Authentication Certificates CS Backup - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies when the Active Directory Certificate Services store is backed up utilizing Event ID 4876. This event triggers whenever the backup occurs in the UI of CertSrv.msc or via CertUtil.exe -BackupDB occurs.
how_to_implement = To implement this analytic, enhanced Audit Logging must be enabled on AD CS and within Group Policy Management for CS server. See Page 128 of first reference.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = False positives will be generated based on normal certificate store backups. Leave enabled to generate Risk, as this is meant to be an anomaly analytic. If CS backups are not normal, enable as TTP.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Steal Authentication Certificates Export Certificate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of export-certificate, the PowerShell cmdlet, being utilized on the command-line in an attempt to export the certifcate from the local Windows Certificate Store.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = Filtering may be requried based on automated utilities and third party applications that may export certificates.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Steal Authentication Certificates Export PfxCertificate - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the use of export-pfxcertificate, the PowerShell cmdlet, being utilized on the command-line in an attempt to export the certifcate from the local Windows Certificate Store.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1649"], "nist": ["DE.AE"]}
known_false_positives = Filtering may be requried based on automated utilities and third party applications that may export certificates.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Steal or Forge Kerberos Tickets Klist - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS klist.exe tool. This tool is being abused or used by several post exploitation tool such as winpeas that being used by ransomware prestige to display or gather list of currently cached kerberos ticket. This cahced data can be used for lateral movement or even privilege escalation on the targeted host. This hunting query can be a good pivot in possible kerberos attack or pass the hash technique.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1558"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Suspect Process With Authentication Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies executables running from public or temporary locations that are communicating over windows domain authentication ports/protocol. The ports/protocols include LDAP(389), LDAPS(636), and Kerberos(88). Authentications from applications  running from user controlled locations may not be malicious, however actors often attempt to access domain resources after initial  compromise from executables in these locations.
how_to_implement = To implement this analytic, Sysmon should be installed in the environment and generating network events for  userland and/or known public writable locations.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1087", "T1087.002", "T1204", "T1204.002"], "nist": ["DE.AE"]}
known_false_positives = Known applications running from these locations for legitimate purposes. Targeting only kerberos (port 88) may significantly reduce noise.
providing_technologies = null

[savedsearch://ESCU - Windows System Binary Proxy Execution Compiled HTML File Decompile - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the decompile parameter with the HTML Help application, HH.exe. This is a uncommon command to see ran and behavior. Most recently this was seen in a APT41 campaign where a CHM file was delivered and a script inside used a technique for running an arbitrary command in a CHM file via an ActiveX object. This unpacks an HTML help file to a specified path for launching the next stage.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1218.001", "T1218"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Discovery Using ldap Nslookup - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the execution of nslookup.exe tool to get domain information. Nslookup.exe is a command-line tool that can display information to diagnose domain name systems. This Nslookup feature is being abused by Qakbot malware to gather domain information such as SRV service location records, server name and many more.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = dministrator may execute this commandline tool for auditing purposes. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Discovery Using Qwinsta - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the execution of qwinsta.exe executable in Windows Operating System. This Windows executable file can display information about sessions on a remote desktop session host server. The information includes servername, sessionname, username and many more. This tool is being abused of Qakbot malware to gather information to the targeted or compromised host that will be send back to its Command And Control server.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrator may execute this commandline tool for auditing purposes. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System File on Disk - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic will assist with identifying new .sys files introduced in the environment. This query is meant to identify sys file creates on disk. There will be noise, but reducing common process names or applications should help to limit any volume. The idea is to identify new sys files written to disk and identify them before they're added as a new kernel mode driver.
how_to_implement = To successfully implement this search you need to be ingesting information on files from your endpoints into the `Endpoint` datamodel in the `Filesystem` node. In addition, confirm the latest CIM App 4.20 or higher is installed and the latest TA for the endpoint product. In addition, filtering may occur by adding NOT (Filesystem.file_path IN ("*\\Windows\\*", "*\\Program File*", "*\\systemroot\\*","%SystemRoot%*", "system32\*")). This will level out the noise generated to potentally lead to generating notables.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System LogOff Commandline - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies Windows commandline to logoff a windows host machine. This technique was seen in several APT, RAT like dcrat and other commodity malware to shutdown the machine to add more impact, interrupt access, aid destruction of the system like wiping disk or inhibit system recovery. This TTP is a good pivot to check why application trigger this commandline which is not so common way to logoff a machine.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.AE"]}
known_false_positives = Administrator may execute this commandline to trigger shutdown, logoff or restart the host machine.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Network Config Discovery Display DNS - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process command line that retrieves dns reply information using Windows OS built-in tool IPConfig. This technique is being abused by threat actors, adversaries and post exploitation tools like WINPEAS to retrieve DNS information for the targeted host. This IPConfig parameter (/displaydns) can show dns server resource record, record name, record type, time to live data length and dns reply. This hunting detection can be a good pivot to check which process is executing this command line in specific host system that may lead to malware or adversaries gathering network information.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1016"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Network Connections Discovery Netsh - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS built-in tool netsh.exe to show state, configuration and profile of host firewall. This tool is being used or abused by several adversaries or even post exploitation tool to bypass firewall rules or to discover firewall settings. This hunting detection can help to detect a possible suspicious usage of netsh.exe to retrieve firewall settings or even firewall wlan profile. We recommend checking which parent process and process name execute this command. Also check the process file path for verification that may lead to further TTP's threat behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1049"], "nist": ["DE.AE"]}
known_false_positives = network administrator can use this tool for auditing process.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Reboot CommandLine - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies Windows commandline to reboot a windows host machine. This technique was seen in several APT, RAT like dcrat and other commodity malware to shutdown the machine to add more impact, interrupt access, aid destruction of the system like wiping disk or inhibit system recovery. This TTP is a good pivot to check why application trigger this commandline which is not so common way to reboot a machine. Compare to shutdown and logoff shutdown.exe feature, reboot seen in some automation script like ansible to reboot the machine.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.AE"]}
known_false_positives = Administrator may execute this commandline to trigger shutdown or restart the host machine.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Script Proxy Execution Syncappvpublishingserver - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the abuse of Syncappvpublishingserver.vbs, which is a native script on Windows that may be utilized to download remote files or perform privilege escalation.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1216", "T1218"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if the vbscript syncappvpublishingserver is used for legitimate purposes. Filter as needed. Adding a n; to the command-line arguments may help reduce any noise.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Shutdown CommandLine - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection rule is designed to identify the execution of the Windows shutdown command via command line interface. The shutdown command can be utilized by system administrators to properly halt, power off, or reboot a computer. However, in a security context, attackers who have gained unauthorized access to a system may also use this command in an effort to erase tracks, or to cause disruption and denial of service. In some instances, they might execute the shutdown command after installing a backdoor, to force the system to restart, ensuring that changes take effect or evading detection by security tools. Monitoring for the use of the Windows shutdown command, especially in conjunction with other unusual or unauthorized activities, can be an important part of identifying malicious behavior within a network. It is advised that security professionals analyze the context in which the shutdown command is being executed to differentiate between legitimate administrative functions and potentially malicious activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1529"], "nist": ["DE.AE"]}
known_false_positives = Administrator may execute this commandline to trigger shutdown or restart the host machine.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System Time Discovery W32tm Delay - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies DCRat delay time tactics using w32tm. This technique was seen in DCRAT malware where it uses stripchart function of w32tm.exe application to delay the execution of its payload like c2 communication , beaconing and execution. This anomaly detection may help the analyst to check other possible event like the process who execute this command that may lead to DCRat attack.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1124"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System User Discovery Via Quser - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a process execution of Windows OS quser.exe tool. This tool is being abused or used by several post exploitation tool such as winpeas that being used by ransomware prestige to display or gather information about user sessions on a Remote Desktop Session Host server. This command can find out if a specific user is logged on to a specific Remote Desktop Session Host server. This tool can retrieve some RDP information that can be use by attacker for further attack like Name of the user , Name of the session on the Remote Desktop Session Host server, Session ID, State of the session (active or disconnected), Idle time (the number of minutes since the last keystroke or mouse movement at the session) and Date and time the user logged on.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = network administrator can use this command tool to audit RDP access of user in specific network or host.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows System User Privilege Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the execution of `whoami.exe` with /priv parameter. This whoami command is used to display or shows the privileges assigned to the current user account. This hunting query can be a good pivot start to look for suspicious usage of whoami application that might related to a malware or adversaries.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1033"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Terminating Lsass Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to detect a suspicious process terminating Lsass process. Lsass process is known to be a critical process that is responsible for enforcing security policy system. This process was commonly targetted by threat actor or red teamer to gain privilege escalation or persistence in the targeted machine because it handles credentials of the logon users. In this analytic we tried to detect a suspicious process having a granted access PROCESS_TERMINATE to lsass process to modify or delete protected registrys. This technique was seen in doublezero malware that tries to wipe files and registry in compromised hosts. This anomaly detection can be a good pivot of incident response for possible credential dumping or evading security policy in a host or network environment.
how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10 for lsass.exe. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = unknown
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Time Based Evasion - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to detect potentially malicious processes that initiate a ping delay using an invalid IP address. This evasion technique was observed in NJRAT, where the malware employed ping commands as a means to introduce a time delay before self-deletion on the compromised host. Identifying this (TTP) behavior can serve as a valuable indicator for detecting NJRAT infections or other malware that employ time delays as evasion tactics.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1497", "T1497.003"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Time Based Evasion via Choice Exec - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is designed to detect potentially suspicious batch files that leverage choice.exe as a delay tactic. This technique, observed in the SnakeKeylogger malware, is utilized for time delays or 'Sleep' commands in its code execution or before the deletion of its copies on compromised hosts. Detecting this anomaly serves as a valuable pivot to uncover suspicious processes attempting to evade detection through time-based evasion techniques.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1497.003", "T1497"], "nist": ["DE.AE"]}
known_false_positives = administrator may use choice.exe to allow user to choose from and indexes of choices from a batch script.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows UAC Bypass Suspicious Child Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when an executable known for User Account Control bypass exploitation, spawns a child process in user controlled location or a command shell executable (cmd, powershell, etc). This behavioral chain may indicate that an attacker has used a UAC Bypass exploit to successfully escalate privileges.
how_to_implement = Target environment must ingest sysmon data, specifically Event ID 1 with process integrity level data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548", "T1548.002"], "nist": ["DE.CM"]}
known_false_positives = Including Werfault.exe may cause some unintended false positives related to normal application faulting, but is used in a number of UAC bypass techniques.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows UAC Bypass Suspicious Escalation Behavior - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when a process spawns an executable known for User Account Control bypass exploitation, and then monitors for any subsequent child processes that are above the integrity level of the original spawning process. This behavioral chain may indicate that an attacker has used a UAC Bypass exploit to successfully escalate privileges.
how_to_implement = Target environment must ingest sysmon data, specifically Event ID 1 with process integrity level data.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548", "T1548.002"], "nist": ["DE.CM"]}
known_false_positives = Including Werfault.exe may cause some unintended false positives related to normal application faulting, but is used in a number of UAC bypass techniques.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Unsecured Outlook Credentials Access In Registry - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a suspicious query on outlook credentials registry in Windows OS registry. typically refers to user profiles associated with Microsoft Outlook. Within this key, Outlook stores configuration settings, including account information such as email addresses, server details, and authentication credentials. Accessing or modifying this registry key can potentially compromise users' email security, making it a target for attackers seeking to steal sensitive information or execute unauthorized actions within Outlook. This anomaly detection is a good pivot to catch possible Trojan Stealer or RAT that tries to steal sensitive information to its targeted host.
how_to_implement = To successfully implement this search, you must ingest Windows Security Event logs and track event code 4663. For 4663, enable "Audit Object Access" in Group Policy. Then check the two boxes listed for both "Success" and "Failure."
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1552"], "nist": ["DE.AE"]}
known_false_positives = third party software may access this outlook registry.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unsigned DLL Side-Loading - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic focuses on detecting potentially malicious unsigned DLLs created in either the c:\windows\system32 or c:\windows\syswow64 folders. This particular technique was observed in the context of the Warzone (Ave Maria) RAT, where it employed a method known as DLL hijacking (dll-side-loading) by dropping the "dismcore.dll" to achieve privilege escalation. DLL hijacking is a stealthy attack technique used by cybercriminals to exploit the way Windows searches and loads DLLs. By placing a malicious DLL with the same name as one that a legitimate application is expected to load, the attacker can gain unauthorized access and execute malicious code. In the case of Warzone RAT (Ave Maria), the dropped "dismcore.dll" was intended to deceive the system into loading the rogue DLL instead of the legitimate version, thereby granting the malware elevated privileges and enabling further compromise of the target system. Detecting such suspicious DLLs is crucial in preventing privilege escalation attacks and other potential security breaches. Regular security assessments, thorough monitoring, and implementing security best practices are essential in safeguarding systems from such threats.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name and imageloaded executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002"], "nist": ["DE.AE"]}
known_false_positives = It is possible some Administrative utilities will load dismcore.dll outside of normal system paths, filter as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Unsigned MS DLL Side-Loading - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analysis identifies potential DLL side-loading instances involving unsigned DLLs with a company detail signature mimicking Microsoft. This technique is frequently exploited by adversaries to execute malicious code automatically by running a legitimate process. The analytics involves searching Sysmon logs for Event Code 7, where both the `Image` and `ImageLoaded` paths do not match system directories (`system32`, `syswow64`, and `programfiles`). Additionally, it verifies whether the loaded DLL is signed and checks if the folder paths of the `Image` and `ImageLoaded` are identical. This anomaly detection mechanism serves as a valuable indicator for identifying suspicious processes that load unsigned DLLs. Add other paths based on org hunting.
how_to_implement = The analytic is designed to be run against Sysmon event logs collected from endpoints. The analytic requires the Sysmon event logs to be ingested into Splunk. The analytic searches for EventCode 7 where the Image is either SQLDumper.exe or SQLWriter.exe and the ImageLoaded is vcruntime140.dll. The search also filters out the legitimate loading of vcruntime140.dll from the System32 directory to reduce false positives. The analytic can be modified to include additional known good paths for vcruntime140.dll to further reduce false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1574.002", "T1547"], "nist": ["DE.AE"]}
known_false_positives = False positives are possible if legitimate processes are loading vcruntime140.dll from non-standard directories. It is recommended to investigate the context of the process loading vcruntime140.dll to determine if it is malicious or not. Modify the search to include additional known good paths for vcruntime140.dll to reduce false positives.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Unusual Count Of Disabled Users Failed Auth Using Kerberos - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with multiple disabled domain users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack against disabled users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code `0x12` stands for `clients credentials have been revoked` (account disabled, expired or locked out).\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A host failing to authenticate with multiple disabled domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Invalid Users Fail To Auth Using Kerberos - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with multiple invalid domain users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4768 is generated every time the Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT). Failure code 0x6 stands for `client not found in Kerberos database` (the attempted user is not a valid domain user).\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, multi-user systems and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Invalid Users Failed To Auth Using NTLM - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with multiple invalid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. As attackers progress in a breach, mistakes will be made. In certain scenarios, adversaries may execute a password spraying attack using an invalid list of users. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC0000064 stands for `The username you typed does not exist` (the attempted user is a legitimate domain user).\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation' within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A host failing to authenticate with multiple invalid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Users Fail To Auth Wth ExplicitCredentials - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a source user failing to authenticate with multiple users using explicit credentials on a host. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Event 4648 is generated when a process attempts an account logon by explicitly specifying that accounts credentials. This event generates on domain controllers, member servers, and workstations.\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source account, attempted user accounts and the endpoint were the behavior was identified.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A source user failing attempting to authenticate multiple users on a host is not a common behavior for regular systems. Some applications, however, may exhibit this behavior in which case sets of users hosts can be added to an allow list. Possible false positive scenarios include systems where several users connect to like Mail servers, identity providers, remote desktop services, Citrix, etc.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Users Failed To Auth Using Kerberos - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with multiple valid users using the Kerberos protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using Kerberos to obtain initial access or elevate privileges. Event 4771 is generated when the Key Distribution Center fails to issue a Kerberos Ticket Granting Ticket (TGT). Failure code 0x18 stands for `wrong password provided` (the attempted user is a legitimate domain user).\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source ip and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller and Kerberos events. The Advanced Security Audit policy setting `Audit Kerberos Authentication Service` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, missconfigured systems and multi-user systems like Citrix farms.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Users Failed To Authenticate From Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a source process name failing to authenticate with multiple users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Event 4625 generates on domain controllers, member servers, and workstations when an account fails to logon. Logon Type 2 describes an iteractive logon attempt.\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will trigger on the potenfially malicious host, perhaps controlled via a trojan or operated by an insider threat, from where a password spraying attack is being executed. This could be a domain controller as well as a member server or workstation.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers aas well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A process failing to authenticate with multiple users is not a common behavior for legitimate user sessions. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Users Failed To Authenticate Using NTLM - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies one source endpoint failing to authenticate with multiple valid users using the NTLM protocol. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment using NTLM to obtain initial access or elevate privileges. Event 4776 is generated on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative. Error code 0xC000006A means: misspelled or bad password (the attempted user is a legitimate domain user).\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will only trigger on domain controllers, not on member servers or workstations.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source workstation name and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Domain Controller events. The Advanced Security Audit policy setting `Audit Credential Validation` within `Account Logon` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A host failing to authenticate with multiple valid domain users is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners and missconfigured systems. If this detection triggers on a host other than a Domain Controller, the behavior could represent a password spraying attack against the host's local accounts.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows Unusual Count Of Users Remotely Failed To Auth From Host - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a source host failing to authenticate against a remote host with multiple users. This behavior could represent an adversary performing a Password Spraying attack against an Active Directory environment to obtain initial access or elevate privileges. Event 4625 documents each and every failed attempt to logon to the local computer. This event generates on domain controllers, member servers, and workstations. Logon Type 3 describes an remote authentication attempt.\
The detection calculates the standard deviation for each host and leverages the 3-sigma statistical rule to identify an unusual number of users. To customize this analytic, users can try different combinations of the `bucket` span time and the calculation of the `upperBound` field. This logic can be used for real time security monitoring as well as threat hunting exercises.\
This detection will trigger on the host that is the target of the password spraying attack. This could be a domain controller as well as a member server or workstation.\
The analytics returned fields allow analysts to investigate the event further by providing fields like source process name, source account and attempted user accounts.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Event Logs from domain controllers as as well as member servers and workstations. The Advanced Security Audit policy setting `Audit Logon` within `Logon/Logoff` needs to be enabled.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1110.003", "T1110"], "nist": ["DE.AE"]}
known_false_positives = A host failing to authenticate with multiple valid users against a remote host is not a common behavior for legitimate systems. Possible false positive scenarios include but are not limited to vulnerability scanners, remote administration tools, missconfigyred systems, etc.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - Windows User Execution Malicious URL Shortcut File - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic will identify suspicious creation of URL shortcut link files. This technique was seen in CHAOS ransomware where it will drop this .url link file in %startup% folder that contains the path of its malicious dropped file to execute upon the reboot of the targeted host. The creation of this file can be created by a normal application or software but it is a good practice to verify this type of file specially the resource it tries to execute which is commonly a website.
how_to_implement = To successfully implement this search you need to be ingesting information on process that include the name of the Filesystem responsible for the changes from your endpoints into the `Endpoint` datamodel in the `Filesystem` node.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1204.002", "T1204"], "nist": ["DE.CM"]}
known_false_positives = Administrators may allow creation of script or exe in this path.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Valid Account With Never Expires Password - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies net.exe updating user account policies for password requirement with non-expiring password. This technique was seen in several adversaries and malware like Azorult to maintain the foothold (persistence), gaining privilege escalation, defense evasion and possible for lateral movement for specific users or created user account on the targeted host. This TTP detections is a good pivot to see further what other events that users executes on the machines.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1489"], "nist": ["DE.CM"]}
known_false_positives = This behavior is not commonly seen in production environment and not advisable, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows Vulnerable 3CX Software - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic leverages Sysmon, a powerful system monitoring and logging tool, to pinpoint instances of the 3CXDesktopApp.exe with a FileVersion of 18.12.x.Recently, 3CX has discovered a vulnerability specifically in versions 18.12.407 and 18.12.416 of the desktop app.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the process name, parent process, and command-line executions from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1195.002"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on file version, modify the analytic to only look for version between 18.12.407 and 18.12.416 as needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows Vulnerable Driver Loaded - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes a known list of vulnerable Windows drivers to help defenders find potential persistence or privelege escalation via a vulnerable driver. This analytic uses Sysmon EventCode 6, driver loading. A known gap with this lookup is that it does not use the hash or known signer of the vulnerable driver therefore it is up to the defender to identify version and signing info and confirm it is a vulnerable driver.
how_to_implement = Sysmon collects driver loads via EventID 6, however you may modify the query to utilize this lookup to identify potentially persistent drivers that are known to be vulnerable.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present. Drill down into the driver further by version number and cross reference by signer. Review the reference material in the lookup. In addition, modify the query to look within specific paths, which will remove a lot of "normal" drivers.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows WinDBG Spawning AutoIt3 - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies instances of the WinDBG process spawning AutoIt3. This behavior may indicate malicious activity as AutoIt3 is often used by threat actors for scripting malicious automation. The search specifically looks for instances where the parent process name is 'windbg.exe' and the process name is 'autoit3.exe' or 'autoit*.exe'. During the triage process, it is recommended to review the file path for additional artifacts that may provide further insights into the event.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1059"], "nist": ["DE.CM"]}
known_false_positives = False positives will only be present if the WinDBG process legitimately spawns AutoIt3. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows WinLogon with Public Network Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic is designed to detect anomalous behavior associated with the BlackLotus Campaign, a sophisticated bootkit attack reported by ESET and further investigated in a blog by Microsoft, which provided hunting queries for security analysts. The primary focus of this analytic is to identify instances of Winlogon.exe, a critical Windows process, connecting to public IP space, which is indicative of potential malicious activity.\ The BlackLotus Campaign is a bootkit-based attack that compromises system integrity by infecting the Master Boot Record (MBR) and Volume Boot Record (VBR). This malware variant can bypass traditional security measures, load before the operating system, and maintain persistence on the target system.\
Winlogon.exe is a critical Windows process responsible for managing user logon and logoff processes. Under normal circumstances, Winlogon.exe should not be connecting to public IP addresses. However, if it does, it may indicate that the process has been compromised as part of the BlackLotus Campaign or another malicious operation.\
This analytic monitors network connections made by Winlogon.exe and triggers an alert if it detects connections to public IP space. By identifying such anomalous behavior, security analysts can investigate further and respond swiftly to potential threats.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542.003"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present and filtering will be required. Legitimate IPs will be present and need to be filtered.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows WMI Impersonate Token - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies a possible wmi token impersonation activities in a process or command. This technique was seen in Qakbot malware where it will execute a vbscript code contains wmi impersonation object to gain privilege escalation or as defense evasion. This Anomaly detection looks for wmiprvse.exe SourceImage having a duplicate handle or full granted access in a target process.
how_to_implement = This search requires Sysmon Logs and a Sysmon configuration, which includes EventCode 10. This search uses an input macro named `sysmon`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Sysmon logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]}
known_false_positives = administrator may execute impersonate wmi object script for auditing. Filter is needed.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - Windows WMI Process And Service List - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious process command line, where WMI is performing an event query looking for running processes or running services. This technique is commonly found where the adversary will identify services and system information on the compromised machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]}
known_false_positives = netowrk administrator or IT may execute this command for auditing processes and services.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Windows WMI Process Call Create - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic is to look for wmi commandlines to execute or create process. This technique was used by adversaries or threat actor to execute their malicious payload in local or remote host. This hunting query is a good pivot to start to look further which process trigger the wmi or what process it execute locally or remotely.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.AE"]}
known_false_positives = Administrators may execute this command for testing or auditing.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following query utilizes Windows Security EventCode 4698, indicating 'a scheduled task was created', to identify potentially suspicious tasks. These tasks may be registered on Windows through either schtasks.exe or TaskService, and are set up to execute a command with a native Windows shell such as PowerShell, Cmd, Wscript, or Cscript.\
The search will return the initial and final times the task was registered, along with details like the 'Command' set to be executed, 'Task Name', 'Author', whether it's 'Enabled', and if it is 'Hidden'.\
Schtasks.exe is typically found in C:\Windows\system32 and C:\Windows\syswow64. The DLL 'taskschd.dll' is loaded when either schtasks.exe or TaskService is launched. If this DLL is found loaded by another process, it's possible that a scheduled task is being registered within the context of that process in memory.\
During triage, it's essential to identify the source of the scheduled task. Was it registered via schtasks.exe or TaskService? Review the job that was created and the command set to be executed. It's also recommended to capture and review any artifacts on disk, and identify any parallel processes within the same timeframe to locate the source.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible if legitimate applications are allowed to register tasks that call a shell to be spawned. Filter as needed based on command-line or processes that are used legitimately.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - WinEvent Scheduled Task Created Within Public Path - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic utilizes Windows Security EventCode 4698, which indicates the creation of a scheduled task on a Windows system. The purpose of this query is to identify suspicious tasks that have been registered using either schtasks.exe or TaskService and involve executing a command from a user-writable file path.\
When this analytic is triggered, it provides information such as the first and last registration time of the task, the command to be executed, the task name, author, and whether it is set as hidden or not. It is worth noting that schtasks.exe is commonly located in C:\Windows\system32 and C:\Windows\syswow64, and it loads the taskschd.dll DLL when launched. If this DLL is loaded by another process, it suggests that a scheduled task may be registered within that process's context in memory.\
During the triage process, it is essential to identify the source of the scheduled task creation, whether it was initiated through schtasks.exe or TaskService. The analyst should review the task that was created, including the command to be executed. Additionally, any artifacts on disk related to the task should be captured and analyzed. It is also recommended to identify any parallel processes that occurred within the same timeframe to determine the source of the task creation.\
By conducting this triage process, security analysts can gain insights into potentiallymalicious or suspicious scheduled tasks, helping them identify the source and assess the impact of the task. This analytic is valuable for a Security Operations Center (SOC) as it can detect unauthorized or suspicious activity that could indicate an attacker's attempt to establish persistence or execute unauthorized commands on the system.
how_to_implement = To successfully implement this search, you need to be ingesting Windows Security Event Logs with 4698 EventCode enabled. The Windows TA is also required.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005", "T1053"], "nist": ["DE.CM"]}
known_false_positives = False positives are possible if legitimate applications are allowed to register tasks in public paths. Filter as needed based on paths that are used legitimately.
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic aims to identify suspicious tasks that have been registered and executed in Windows using EventID 200 (action run) and 201 (action completed) from the Windows Task Scheduler logs. This analytic helps detect evasive techniques used to register tasks on Windows systems. It is recommended to filter the results based on the ActionName field by specifying specific paths that are not commonly used in your environment.\
After implementing this analytic, it is important to review parallel events related to the scheduled tasks. EventID 106 will be generated when a new task is created, but it does not necessarily mean that the task has been executed. Analysts should capture any files on disk associated with the task and perform further analysis.\
To implement this analytic, Task Scheduler logs must be collected. This can be done by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] in the inputs.conf file and setting renderXml=false. It is worth noting that not translating the logs into XML may require specific extraction of items from the Message field.\
False positives are expected with this analytic, so it is important to filter the results based on the paths or specific keywords of interest in the ActionName field to reduce noise.\
Identifying and analyzing scheduled tasks that have been executed is crucial for a Security Operations Center (SOC) as it helps detect potentially malicious or unauthorized activities on Windows systems. By capturing and investigating the associated events, analysts can uncover signs of persistence mechanisms, unauthorized code execution, or suspicious behaviors. The impact of a true positive could range from unauthorized access to data exfiltration or the execution of malicious payloads.
how_to_implement = Task Scheduler logs are required to be collected. Enable logging with inputs.conf by adding a stanza for [WinEventLog://Microsoft-Windows-TaskScheduler/Operational] and renderXml=false. Note, not translating it in XML may require a proper extraction of specific items in the Message.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1053.005"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present. Filter based on ActionName paths or specify keywords of interest.
providing_technologies = null

[savedsearch://ESCU - Winhlp32 Spawning a Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies winhlp32.exe, found natively in `c:\windows\`, spawning a child process that loads a file out of appdata, programdata, or temp. Winhlp32.exe has a rocky past in that multiple vulnerabilities were found and added to MetaSploit. WinHlp32.exe is required to display 32-bit Help files that have the ".hlp" file name extension. This particular instance is related to a Remcos sample where dynwrapx.dll is added to the registry under inprocserver32, and later module loaded by winhlp32.exe to spawn wscript.exe and load a vbs or file from disk. During triage, review parallel processes to identify further suspicious behavior. Review module loads for unsuspecting unsigned modules. Capture any file modifications and analyze.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1055"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as winhlp32.exe is typically not used with the latest flavors of Windows OS. However, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WinRAR Spawning Shell Application - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = The following analytic detects the execution of Windows shell processes initiated by WinRAR, specifically looking for instances where WinRAR spawns processes like "cmd.exe", "powershell.exe", "certutil.exe", "mshta.exe", or "bitsadmin.exe". This behavior is worth identifying for a Security Operations Center (SOC) because it is indicative of a spoofing attack exploit, such as the one associated with WinRAR CVE-2023-38831. Cybercriminals exploited this vulnerability to craft ZIP archives with spoofed extensions, hiding the launch of malicious scripts within an archive. When a victim opened the specially crafted archive, it executed the malware, leading to unauthorized access to their broker accounts and enabling the cybercriminals to perform illicit financial transactions and withdraw funds. If a true positive is found, it suggests that an attacker has successfully exploited the vulnerability to execute malicious scripts, leading to unauthorized access, financial loss, and potentially the delivery of additional malicious payloads. The impact of the attack could be severe, involving financial loss, unauthorized access to sensitive accounts, and the potential for further malicious activity such as data theft or ransomware attacks.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1105"], "nist": ["DE.CM"]}
known_false_positives = Be aware of potential false positives - legitimate uses of WinRAR and the listed processes in your environment may cause benign activities to be flagged. Upon triage, review the destination, user, parent process, and process name involved in the flagged activity. Capture and inspect any relevant on-disk artifacts, and look for concurrent processes to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WinRM Spawning a Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious processes spawning from WinRM (wsmprovhost.exe). This analytic is related to potential exploitation of CVE-2021-31166. which is a kernel-mode device driver http.sys vulnerability. Current proof of concept code will blue-screen the operating system. However, http.sys used by many different Windows processes, including WinRM. In this case, identifying suspicious process create (child processes) from `wsmprovhost.exe` is what this analytic is identifying.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = Unknown. Add new processes or filter as needed. It is possible system management software may spawn processes from `wsmprovhost.exe`.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Winword Spawning Cmd - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies Microsoft Word spawning `cmd.exe`. Typically, this is not common behavior and not default with winword.exe. Winword.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). Cmd.exe spawning from winword.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line will indicate what is being executed. During triage, review parallel processes and identify any files that may have been written. It is possible that COM is utilized to trampoline the child process to `explorer.exe` or `wmiprvse.exe`.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, but if any are present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Winword Spawning PowerShell - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies Microsoft Word spawning PowerShell. Typically, this is not common behavior and not default with winword.exe. Winword.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). PowerShell spawning from winword.exe is common for a spearphishing attachment and is actively used. Albeit, the command executed will most likely be encoded and captured via another detection. During triage, review parallel processes and identify any files that may have been written.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited, but if any are present, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Winword Spawning Windows Script Host - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following detection identifies Microsoft Winword.exe spawning Windows Script Host - `cscript.exe` or `wscript.exe`. Typically, this is not common behavior and not default with Winword.exe. Winword.exe will generally be found in the following path `C:\Program Files\Microsoft Office\root\Office16` (version will vary). `cscript.exe` or `wscript.exe` default location is `c:\windows\system32\` or c:windows\syswow64\`. `cscript.exe` or `wscript.exe` spawning from Winword.exe is common for a spearphishing attachment and is actively used. Albeit, the command-line executed will most likely be obfuscated and captured via another detection. During triage, review parallel processes and identify any files that may have been written. Review the reputation of the remote destination and block accordingly.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566", "T1566.001"], "nist": ["DE.CM"]}
known_false_positives = There will be limited false positives and it will be different for every environment. Tune by child process or command-line as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WMI Permanent Event Subscription - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of permanent event subscriptions using Windows Management Instrumentation (WMI), which is used by attackers to achieve persistence in a compromised system. By creating a permanent event subscription, an attacker can run malicious scripts or binaries in response to specific system events that enables them to maintain access to the system undetected. The detection is made by using Sysmon Event ID 5 data to detect instances where the consumers of these events are not the expected "NTEventLogEventConsumer." The detection is important because it identifies unusual or unexpected subscription creation, which suggests that an attacker is attempting to achieve persistence within the environment and might be executing malicious scripts or binaries in response to specific system events. The impact of such an attack can be severe, potentially leading to data theft, ransomware, or other damaging outcomes. False positives might occur since False positives might occur since WMI event subscriptions can be used for legitimate purposes by system administrators. You must have a thorough understanding of WMI activity within the context of the monitored environment to effectively differentiate between legitimate and malicious activity.Next steps include investigating the associated scripts or binaries and identifying the source of the attack.
how_to_implement = To successfully implement this search, you must be ingesting the Windows WMI activity logs. This can be done by adding a stanza to inputs.conf on the system generating logs with a title of [WinEventLog://Microsoft-Windows-WMI-Activity/Operational].
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, administrators may use event subscriptions for legitimate purposes.
providing_technologies = null

[savedsearch://ESCU - WMI Permanent Event Subscription - Sysmon - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic looks for the creation of WMI permanent event subscriptions. The following analytic identifies the use of WMI Event Subscription to establish persistence or perform privilege escalation.  WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs. WMI subscription execution is proxied by the WMI Provider Host process (WmiPrvSe.exe) and thus may result in elevated SYSTEM privileges. This analytic is restricted by commonly added process execution and a path. If the volume is low enough, remove the values and flag on any new subscriptions.\
All event subscriptions have three components \
1. Filter - WQL Query for the events we want. EventID = 19 \
1. Consumer - An action to take upon triggering the filter. EventID = 20 \
1. Binding - Registers a filter to a consumer. EventID = 21 \
Monitor for the creation of new WMI EventFilter, EventConsumer, and FilterToConsumerBinding. It may be pertinent to review all 3 to identify the flow of execution. In addition, EventCode 4104 may assist with any other PowerShell script usage that registered the subscription.
how_to_implement = To successfully implement this search, you must be collecting Sysmon data using Sysmon version 6.1 or greater and have Sysmon configured to generate alerts for WMI activity (eventID= 19, 20, 21). In addition, you must have at least version 6.0.4 of the Sysmon TA installed to properly parse the fields.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1546.003", "T1546"], "nist": ["DE.CM"]}
known_false_positives = Although unlikely, administrators may use event subscriptions for legitimate purposes.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - WMI Recon Running Process Or Services - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies suspicious PowerShell script execution via EventCode 4104, where WMI is performing an event query looking for running processes or running services. This technique is commonly found in malware and APT events where the adversary will map all running security applications or services on the compromised machine. During triage, review parallel processes within the same timeframe. Review the full script block to identify other related artifacts.
how_to_implement = To successfully implement this analytic, you will need to enable PowerShell Script Block Logging on some or all endpoints. Additional setup here https://docs.splunk.com/Documentation/UBA/5.0.4.1/GetDataIn/AddPowerShell#Configure_module_logging_for_PowerShell.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Reconnaissance"], "mitre_attack": ["T1592"], "nist": ["DE.AE"]}
known_false_positives = Network administrator may used this command for checking purposes
providing_technologies = ["Microsoft Windows"]

[savedsearch://ESCU - WMI Temporary Event Subscription - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the creation of WMI temporary event subscriptions. WMI (Windows Management Instrumentation) is a management technology that allows administrators to perform various tasks on Windows-based systems. Temporary event subscriptions are created to monitor specific events or changes on a system that help to detect potential threats early and take proactive measures to protect the organization's systems and data. The detection is made by using the Splunk query `wmi` EventCode=5860 Temporary to search for events with EventCode 5860, which indicates the creation of a temporary WMI event subscription. To further refine the search results, the query uses regular expressions (rex) to extract the query used in the event subscription. Then, it filters known benign queries related to system processes such as 'wsmprovhost.exe' and 'AntiVirusProduct', 'FirewallProduct', 'AntiSpywareProduct', which helps to focus on potentially malicious or suspicious queries. The detection is important because it indicates malicious activity since attackers use WMI to run commands, gather information, or maintain persistence within a compromised system. False positives might occur since legitimate uses of WMI event subscriptions in the environment might trigger benign activities to be flagged. Therefore, an extensive triage is necessary to review the specific query and assess its intent. Additionally, capturing and inspecting relevant on-disk artifacts and analyzing concurrent processes can help to identify the source of the attack. Detecting the creation of these event subscriptions to identify potential threats early and take appropriate actions to mitigate the risks.
how_to_implement = To successfully implement this search, you must be ingesting the Windows WMI activity logs. This can be done by adding a stanza to inputs.conf on the system generating logs with a title of [WinEventLog://Microsoft-Windows-WMI-Activity/Operational].
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Some software may create WMI temporary event subscriptions for various purposes. The included search contains an exception for two of these that occur by default on Windows 10 systems. You may need to modify the search to create exceptions for other legitimate events.
providing_technologies = null

[savedsearch://ESCU - Wmic Group Discovery - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following hunting analytic identifies the use of `wmic.exe` enumerating local groups on the endpoint. \
Typically, by itself, is not malicious but may raise suspicion based on time of day, endpoint and username. \
During triage, review parallel processes and identify any further suspicious behavior.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1069", "T1069.001"], "nist": ["DE.AE"]}
known_false_positives = Administrators or power users may use this command for troubleshooting.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Wmic NonInteractive App Uninstallation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic indentifies WMIC command-line attempting to uninstall application non-interactively. This technique was seen in IcedID to uninstall AV products on the compromised host to evade detection. This Hunting query maybe a good indicator that some process tries to uninstall application using wmic which is not a common behavior. This approach may seen in some script or third part appication to uninstall their application but it is a good thing to check what it uninstall and why.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1562.001", "T1562"], "nist": ["DE.AE"]}
known_false_positives = Third party application may use this approach to uninstall applications.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WMIC XSL Execution via URL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `wmic.exe` loading a remote XSL (eXtensible Stylesheet Language) script. This originally was identified by Casey Smith, dubbed Squiblytwo, as an application control bypass. Many adversaries will utilize this technique to invoke JScript or VBScript within an XSL file. This technique can also execute local/remote scripts and, similar to its Regsvr32 "Squiblydoo" counterpart, leverages a trusted, built-in Windows tool. Adversaries may abuse any alias in Windows Management Instrumentation provided they utilize the /FORMAT switch. Upon identifying a suspicious execution, review for confirmed network connnection and script download.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1220"], "nist": ["DE.CM"]}
known_false_positives = False positives are limited as legitimate applications typically do not download files or xsl using WMIC. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Wmiprsve LOLBAS Execution Process Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `wmiprsve.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing Windows Management Instrumentation (WMI), the executed command is spawned as a child process of `wmiprvse.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of wmiprvse.exe that are part of the LOLBAS project can help defenders identify lateral movement activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1047"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may trigger this behavior, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Wscript Or Cscript Suspicious Child Process - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies a suspicious spawned process by WScript or CScript process. This technique was a common technique used by adversaries and malware to execute different LOLBIN, other scripts like PowerShell or spawn a suspended process to inject its code as a defense evasion. This TTP may detect some normal script that using several application tool that are in the list of the child process it detects but a good pivot and indicator that a script is may execute suspicious code.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1055", "T1543", "T1134.004", "T1134"], "nist": ["DE.CM"]}
known_false_positives = Administrators may create vbs or js script that use several tool as part of its execution. Filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Wsmprovhost LOLBAS Execution Process Spawn - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies `Wsmprovhost.exe` spawning a LOLBAS execution process. When adversaries execute code on remote endpoints abusing the Windows Remote Management (WinRm) protocol, the executed command is spawned as a child processs of `Wsmprovhost.exe`. The LOLBAS project documents Windows native binaries that can be abused by threat actors to perform tasks like executing malicious code. Looking for child processes of Wsmprovhost.exe that are part of the LOLBAS project can help defenders identify lateral movement activity.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021", "T1021.006"], "nist": ["DE.CM"]}
known_false_positives = Legitimate applications may trigger this behavior, filter as needed.
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - WSReset UAC Bypass - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious modification of registry related to UAC bypass. This technique is to modify the registry in this detection, create a registry value with the path of the payload and run WSreset.exe to bypass User account Control.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1548.002", "T1548"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - XMRIG Driver Loaded - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This analytic identifies XMRIG coinminer driver installation on the system. The XMRIG driver name by default is `WinRing0x64.sys`. This cpu miner is an open source project that is commonly abused by adversaries to infect and mine bitcoin.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the driver loaded and Signature from your endpoints. If you are using Sysmon, you must have at least version 6.0.4 of the Sysmon TA.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation", "Exploitation"], "mitre_attack": ["T1543.003", "T1543"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited.
providing_technologies = ["Microsoft Sysmon"]

[savedsearch://ESCU - XSL Script Execution With WMIC - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect a suspicious wmic.exe process or renamed wmic process to execute malicious xsl file. This technique was seen in FIN7 to execute its malicous jscript using the .xsl as the loader with the help of wmic.exe process. This TTP is really a good indicator for you to hunt further for FIN7 or other attacker that known to used this technique.
how_to_implement = The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the `Processes` node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1220"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Sysmon", "Microsoft Windows", "Carbon Black Response", "CrowdStrike Falcon", "Symantec Endpoint Protection"]

[savedsearch://ESCU - Detect ARP Poisoning - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = By enabling Dynamic ARP Inspection as a Layer 2 Security measure on the organization's network devices, we will be able to detect ARP Poisoning attacks in the Infrastructure.
how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with DHCP Snooping (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/security/configuration_guide/b_sec_152ex_2960-x_cg/b_sec_152ex_2960-x_cg_chapter_01101.html) and Dynamic ARP Inspection (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_2_e/security/configuration_guide/b_sec_1522e_2960x_cg/b_sec_1522e_2960x_cg_chapter_01111.html) and log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Actions on Objectives", "Exploitation"], "mitre_attack": ["T1200", "T1498", "T1557", "T1557.002"], "nist": ["DE.CM"]}
known_false_positives = This search might be prone to high false positives if DHCP Snooping or ARP inspection has been incorrectly configured, or if a device normally sends many ARP packets (unlikely).
providing_technologies = null

[savedsearch://ESCU - Detect DGA domains using pretrained model in DSDL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses a pre trained deep learning model to detect Domain Generation Algorithm (DGA) generated domains. The model is trained independently and is then made available for download. One of the prominent indicators of a domain being DGA generated is if the domain name consists of unusual character sequences or concatenated dictionary words. Adversaries often use clever techniques to obfuscate machine generated domain names as human generated. Predicting DGA generated domain names requires analysis and building a model based on carefully chosen features. The deep learning model we have developed uses the domain name to analyze patterns of character sequences along with carefully chosen custom features to predict if a domain is DGA generated. The model takes a domain name consisting of second-level and top-level domain names as input and outputs a dga_score. Higher the dga_score, the more likely the input domain is a DGA domain. The threshold for flagging a domain as DGA is set at 0.5.
how_to_implement = Steps to deploy DGA detection model into Splunk App DSDL.\ This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - https://splunkbase.splunk.com/app/4607/ and the Network Resolution datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. The detection uses a pre-trained deep learning model that needs to be deployed in DSDL app. Follow the steps for deployment here - https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU.\ * Download the artifacts .tar.gz file from the link  `https://seal.splunkresearch.com/pretrained_dga_model_dsdl.tar.gz`\
* Download the pretrained_dga_model_dsdl.ipynb Jupyter notebook from `https://github.com/splunk/security_content/notebooks`\
* Login to the Jupyter Lab for pretrained_dga_model_dsdl container. This container should be listed on Containers page for DSDL app.\
* Below steps need to be followed inside Jupyter lab \
* Upload the pretrained_dga_model_dsdl.tar.gz file into `app/model/data` path using the upload option in the jupyter notebook.\
*  Untar the artifact `pretrained_dga_model_dsdl.tar.gz` using `tar -xf app/model/data/pretrained_dga_model_dsdl.tar.gz -C app/model/data`\
* Upload `pretrained_dga_model_dsdl.pynb` into Jupyter lab notebooks folder using the upload option in Jupyter lab\
* Save the notebook using the save option in jupyter notebook.\
* Upload `pretrained_dga_model_dsdl.json` into `notebooks/data` folder.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1568.002"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if domain name is similar to dga generated domains.
providing_technologies = null

[savedsearch://ESCU - Detect DNS Data Exfiltration using pretrained model in DSDL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses a pre trained deep learning model to detect DNS data exfiltration. The model is trained on the data we collected and is inferred on live data. This detection detects low throughput DNS Tunneling (data exfiltration) using features computed from past events between the same src and domain. The search uses macros from URL ToolBox app to generate features used by the model. The model is a deep learning model that accepts DNS request as input along with a few custom features to generate a pred_is_exfiltration_proba score. The higher the pred_is_exfiltration_proba, the more likely the DNS request is data exfiltration. The threshold for flagging a request as DNS exfiltration is set at 0.5.
how_to_implement = Steps to deploy detect DNS data exfiltration model into Splunk App DSDL. This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - https://splunkbase.splunk.com/app/4607/ and the Network Resolution datamodel which can be found here - https://splunkbase.splunk.com/app/1621/. The detection uses a pre-trained deep learning model that needs to be deployed in DSDL app. Follow the steps for deployment here - `https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU`.\
* Download the `artifacts .tar.gz` file from the link - https://seal.splunkresearch.com/detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz Download the `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.ipynb` Jupyter notebook from https://github.com/splunk/security_content/notebooks\
* Login to the Jupyter Lab assigned for detect_dns_data_exfiltration_using_pretrained_model_in_dsdl container. This container should be listed on Containers page for DSDL app.\
* Below steps need to be followed inside Jupyter lab \
* Upload the detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz file into `app/model/data` path using the upload option in the jupyter notebook.\
* Untar the artifact detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.tar.gz using `tar -xf app/model/data/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz -C app/model/data`\
* Upload detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.pynb into Jupyter lab notebooks folder using the upload option in Jupyter lab \
* Save the notebook using the save option in jupyter notebook. \
* Upload `detect_dns_data_exfiltration_using_pretrained_model_in_dsdl.json` into `notebooks/data` folder.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if DNS data exfiltration request look very similar to benign DNS requests.
providing_technologies = null

[savedsearch://ESCU - Detect hosts connecting to dynamic domain providers - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Malicious actors often abuse legitimate Dynamic DNS services to host malicious payloads or interactive Command And Control nodes. Attackers will automate domain resolution changes by routing dynamic domains to countless IP addresses to circumvent firewall blocks, block lists as well as frustrate a network defenders analytic and investigative processes. This search will look for DNS queries made from within your infrastructure to suspicious dynamic domains.
how_to_implement = First, you'll need to ingest data from your DNS operations. This can be done by ingesting logs from your server or data, collected passively by Splunk Stream or a similar solution. Specifically, data that contains the domain that is being queried and the IP of the host originating the request must be populating the `Network_Resolution` data model. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating the local lookup periodically by adding new domains to the list of `dynamic_dns_providers_local.csv`.\
This search produces fields (query, answer, isDynDNS) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable event. To see the additional metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** DNS Query, **Field:** query\
1. \
1. **Label:** DNS Answer, **Field:** answer\
1. \
1. **Label:** IsDynamicDNS, **Field:** isDynDNS\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1189"], "nist": ["DE.CM"]}
known_false_positives = Some users and applications may leverage Dynamic DNS to reach out to some domains on the Internet since dynamic DNS by itself is not malicious, however this activity must be verified.
providing_technologies = null

[savedsearch://ESCU - Detect IPv6 Network Infrastructure Threats - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = By enabling IPv6 First Hop Security as a Layer 2 Security measure on the organization's network devices, we will be able to detect various attacks such as packet forging in the Infrastructure.
how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with one or more First Hop Security measures such as RA Guard, DHCP Guard and/or device tracking. See References for more information. The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Actions on Objectives", "Exploitation"], "mitre_attack": ["T1200", "T1498", "T1557", "T1557.002"], "nist": ["DE.CM"]}
known_false_positives = None currently known
providing_technologies = null

[savedsearch://ESCU - Detect Large Outbound ICMP Packets - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for outbound ICMP packets with a packet size larger than 1,000 bytes. Various threat actors have been known to use ICMP as a command and control channel for their attack infrastructure. Large ICMP packets from an endpoint to a remote host may be indicative of this activity.
how_to_implement = In order to run this search effectively, we highly recommend that you leverage the Assets and Identity framework. It is important that you have a good understanding of how your network segments are designed and that you are able to distinguish internal from external address space. Add a category named `internal` to the CIDRs that host the company's assets in the `assets_by_cidr.csv` lookup file, which is located in `$SPLUNK_HOME/etc/apps/SA-IdentityManagement/lookups/`. More information on updating this lookup can be found here: https://docs.splunk.com/Documentation/ES/5.0.0/Admin/Addassetandidentitydata. This search also requires you to be ingesting your network traffic and populating the Network_Traffic data model
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1095"], "nist": ["DE.CM"]}
known_false_positives = ICMP packets are used in a variety of ways to help troubleshoot networking issues and ensure the proper flow of traffic. As such, it is possible that a large ICMP packet could be perfectly legitimate. If large ICMP packets are associated with Command And Control traffic, there will typically be a large number of these packets observed over time. If the search is providing a large number of false positives, you can modify the macro `detect_large_outbound_icmp_packets_filter` to adjust the byte threshold or add specific IP addresses to an allow list.
providing_technologies = null

[savedsearch://ESCU - Detect Outbound LDAP Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Malicious actors often abuse misconfigured LDAP servers or applications that use the LDAP servers in organizations. Outbound LDAP traffic should not be allowed outbound through your perimeter firewall.  This search will help determine if you have any LDAP connections to IP addresses outside of private (RFC1918) address space.
how_to_implement = You must be ingesting Zeek DNS and Zeek Conn data into Splunk. Zeek data should also be getting ingested in JSON format and should be mapped to the Network Traffic datamodels that are in use for this search.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1059"], "nist": ["DE.AE"]}
known_false_positives = Unknown at this moment. Outbound LDAP traffic should not be allowed outbound through your perimeter firewall. Please check those servers to verify if the activity is legitimate.
providing_technologies = null

[savedsearch://ESCU - Detect Outbound SMB Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for outbound SMB connections made by hosts within your network to the Internet. SMB traffic is used for Windows file-sharing activity. One of the techniques often used by attackers involves retrieving the credential hash using an SMB request made to a compromised server controlled by the threat actor.
how_to_implement = In order to run this search effectively, we highly recommend that you leverage the Assets and Identity framework. It is important that you have good understanding of how your network segments are designed, and be able to distinguish internal from external address space. Add a category named `internal` to the CIDRs that host the companys assets in `assets_by_cidr.csv` lookup file, which is located in `$SPLUNK_HOME/etc/apps/SA-IdentityManagement/lookups/`. More information on updating this lookup can be found here: https://docs.splunk.com/Documentation/ES/5.0.0/Admin/Addassetandidentitydata. This search also requires you to be ingesting your network traffic and populating the Network_Traffic data model
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.002", "T1071"], "nist": ["DE.CM"]}
known_false_positives = It is likely that the outbound Server Message Block (SMB) traffic is legitimate, if the company's internal networks are not well-defined in the Assets and Identity Framework. Categorize the internal CIDR blocks as `internal` in the lookup file to avoid creating notable events for traffic destined to those CIDR blocks. Any other network connection that is going out to the Internet should be investigated and blocked. Best practices suggest preventing external communications of all SMB versions and related protocols at the network boundary.
providing_technologies = null

[savedsearch://ESCU - Detect Port Security Violation - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = By enabling Port Security on a Cisco switch you can restrict input to an interface by limiting and identifying MAC addresses of the workstations that are allowed to access the port. When you assign secure MAC addresses to a secure port, the port does not forward packets with source addresses outside the group of defined addresses. If you limit the number of secure MAC addresses to one and assign a single secure MAC address, the workstation attached to that port is assured the full bandwidth of the port. If a port is configured as a secure port and the maximum number of secure MAC addresses is reached, when the MAC address of a workstation attempting to access the port is different from any of the identified secure MAC addresses, a security violation occurs.
how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with Port Security and Error Disable for this to work (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/port_sec.html) and log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Actions on Objectives", "Exploitation"], "mitre_attack": ["T1200", "T1498", "T1557", "T1557.002"], "nist": ["DE.CM"]}
known_false_positives = This search might be prone to high false positives if you have malfunctioning devices connected to your ethernet ports or if end users periodically connect physical devices to the network.
providing_technologies = null

[savedsearch://ESCU - Detect Remote Access Software Usage DNS - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects when a known remote access software domains are contacted from within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = To implement this search, you must ingest logs that contain the DNS query and the source of the query. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the DNS logs. The logs must also be mapped to the `Network_Resolution` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment.
providing_technologies = null

[savedsearch://ESCU - Detect Remote Access Software Usage Traffic - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic detects when a known remote access software application traffic is detected from within the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = The following analytic was developed with Palo Alto traffic logs. Ensure that the logs are being ingested into Splunk and mapped to the Network_Traffic data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment.
providing_technologies = null

[savedsearch://ESCU - Detect Rogue DHCP Server - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = By enabling DHCP Snooping as a Layer 2 Security measure on the organization's network devices, we will be able to detect unauthorized DHCP servers handing out DHCP leases to devices on the network (Man in the Middle attack).
how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must be configured with DHCP Snooping enabled (see https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-0_2_EX/security/configuration_guide/b_sec_152ex_2960-x_cg/b_sec_152ex_2960-x_cg_chapter_01101.html) and log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Actions on Objectives", "Exploitation"], "mitre_attack": ["T1200", "T1498", "T1557"], "nist": ["DE.CM"]}
known_false_positives = This search might be prone to high false positives if DHCP Snooping has been incorrectly configured or in the unlikely event that the DHCP server has been moved to another network interface.
providing_technologies = null

[savedsearch://ESCU - Detect SNICat SNI Exfiltration - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = This search looks for commands that the SNICat tool uses in the TLS SNI field.
how_to_implement = You must be ingesting Zeek SSL data into Splunk. Zeek data should also be getting ingested in JSON format.  We are detecting when any of the predefined SNICat commands are found within the server_name (SNI) field. These commands are LIST, LS, SIZE, LD, CB, EX, ALIVE, EXIT, WHERE, and finito.  You can go further once this has been detected, and run other searches to decode the SNI data to prove or disprove if any data exfiltration has taken place.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1041"], "nist": ["DE.CM"]}
known_false_positives = Unknown
providing_technologies = ["Zeek"]

[savedsearch://ESCU - Detect Software Download To Network Device - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = Adversaries may abuse netbooting to load an unauthorized network device operating system from a Trivial File Transfer Protocol (TFTP) server. TFTP boot (netbooting) is commonly used by network administrators to load configuration-controlled network device images from a centralized management server. Netbooting is one option in the boot sequence and can be used to centralize, manage, and control device images.
how_to_implement = This search looks for Network Traffic events to TFTP, FTP or SSH/SCP ports from network devices. Make sure to tag any network devices as network, router or switch in order for this detection to work. If the TFTP traffic doesn't traverse a firewall nor packet inspection, these events will not be logged. This is typically an issue if the TFTP server is on the same subnet as the network device. There is also a chance of the network device loading software using a DHCP assigned IP address (netboot) which is not in the Asset inventory.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Installation"], "mitre_attack": ["T1542.005", "T1542"], "nist": ["DE.CM"]}
known_false_positives = This search will also report any legitimate attempts of software downloads to network devices as well as outbound SSH sessions from network devices.
providing_technologies = null

[savedsearch://ESCU - Detect suspicious DNS TXT records using pretrained model in DSDL - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic uses a pre trained deep learning model to detect suspicious DNS TXT records. The model is trained independently and is then made available for download. The DNS TXT records are categorized into commonly identified types like email, verification, http using regular expressions https://www.tide-project.nl/blog/wtmc2020/. The TXT records that do not match regular expressions for well known types are labeled as 1 for "unknown/suspicious" and otherwise 0 for "not suspicious". The deep learning model we have developed uses DNS TXT responses to analyze patterns of character sequences to predict if a DNS TXT is suspicious or not. The higher the pred_is_unknown_proba, the more likely the DNS TXT record is suspicious. The threshold for flagging a domain as suspicious is set at 0.5.
how_to_implement = Steps to deploy detect suspicious DNS TXT records model into Splunk App DSDL. This detection depends on the Splunk app for Data Science and Deep Learning which can be found here - `https://splunkbase.splunk.com/app/4607/` and the Network Resolution datamodel which can be found here - `https://splunkbase.splunk.com/app/1621/`. The detection uses a pre-trained deep learning model that needs to be deployed in DSDL app. Follow the steps for deployment here - `https://github.com/splunk/security_content/wiki/How-to-deploy-pre-trained-Deep-Learning-models-for-ESCU`.\
* Download the `artifacts .tar.gz` file from the link - `https://seal.splunkresearch.com/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz`.\
* Download the `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.ipynb` Jupyter notebook from `https://github.com/splunk/security_content/notebooks`.\
* Login to the Jupyter Lab assigned for  `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl` container. This container should be listed on Containers page for DSDL app.\
* Below steps need to be followed inside Jupyter lab.\
* Upload the `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz` file into `app/model/data` path using the upload option in the jupyter notebook.\
* Untar the artifact `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz` using `tar -xf app/model/data/detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.tar.gz -C app/model/data`.\
* Upload detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.ipynb` into Jupyter lab notebooks folder using the upload option in Jupyter lab.\
* Save the notebook using the save option in Jupyter notebook.\
* Upload `detect_suspicious_dns_txt_records_using_pretrained_model_in_dsdl.json` into `notebooks/data` folder.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1568.002"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if DNS TXT record contents are similar to benign DNS TXT record contents.
providing_technologies = null

[savedsearch://ESCU - Detect Traffic Mirroring - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = Adversaries may leverage traffic mirroring in order to automate data exfiltration over compromised network infrastructure. Traffic mirroring is a native feature for some network devices and used for network analysis and may be configured to duplicate traffic and forward to one or more destinations for analysis by a network analyzer or other monitoring device.
how_to_implement = This search uses a standard SPL query on logs from Cisco Network devices. The network devices must log with a severity level of minimum "5 - notification". The search also requires that the Cisco Networks Add-on for Splunk (https://splunkbase.splunk.com/app/1467) is used to parse the logs from the Cisco network devices and that the devices have been configured according to the documentation of the Cisco Networks Add-on. Also note that an attacker may disable logging from the device prior to enabling traffic mirroring.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Actions on Objectives"], "mitre_attack": ["T1200", "T1020", "T1498", "T1020.001"], "nist": ["DE.CM"]}
known_false_positives = This search will return false positives for any legitimate traffic captures by network administrators.
providing_technologies = null

[savedsearch://ESCU - Detect Unauthorized Assets by MAC address - Rule]
type = detection
asset_type = Infrastructure
confidence = medium
explanation = By populating the organization's assets within the assets_by_str.csv, we will be able to detect unauthorized devices that are trying to connect with the organization's network by inspecting DHCP request packets, which are issued by devices when they attempt to obtain an IP address from the DHCP server. The MAC address associated with the source of the DHCP request is checked against the list of known devices, and reports on those that are not found.
how_to_implement = This search uses the Network_Sessions data model shipped with Enterprise Security. It leverages the Assets and Identity framework to populate the assets_by_str.csv file located in SA-IdentityManagement, which will contain a list of known authorized organizational assets including their MAC addresses. Ensure that all inventoried systems have their MAC address populated.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = This search might be prone to high false positives. Please consider this when conducting analysis or investigations. Authorized devices may be detected as unauthorized. If this is the case, verify the MAC address of the system responsible for the false positive and add it to the Assets and Identity framework with the proper information.
providing_technologies = null

[savedsearch://ESCU - Detect Windows DNS SIGRed via Splunk Stream - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = Ensure that the following prerequisites are met: (i) Both Splunk Stream DNS and TCP data are ingested. (ii) The macros 'stream:dns' and 'stream:tcp' are replaced with the appropriate configurations that are specific to your Splunk environment. The following analytic detects SIGRed exploitation attempts. SIGRed is a critical wormable vulnerability found in Windows DNS servers, known as CVE-2020-1350, which allows remote code execution. The detection is made by using an experimental search that focuses on identifying specific indicators that might suggest the presence of the SIGRed exploit such as DNS SIG records, KEY records, and TCP payloads greater than 65KB. This detection is important because it detects and responds to potential SIGRed exploitation attempts and minimizes the risk of a successful attack and its impact on the organization's infrastructure and data. False positives might occur due to the experimental nature of this analytic. Next steps include reviewing and investigating each case thoroughly given the potential for unauthorized Windows DNS server access, data breaches, and service disruptions. Additionally, you must stay updated with Microsoft's guidance on the SIGRed vulnerability.
how_to_implement = You must be ingesting Splunk Stream DNS and Splunk Stream TCP. We are detecting SIG and KEY records via stream:dns and TCP payload over 65KB in size via stream:tcp.  Replace the macro definitions ('stream:dns' and 'stream:tcp') with configurations for your Splunk environment.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1203"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Detect Windows DNS SIGRed via Zeek - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects the presence of SIGRed, a critical DNS vulnerability, using Zeek DNS and Zeek Conn data. SIGRed vulnerability allows attackers to run remote code on Windows DNS servers. By detecting SIGRed early, you can prevent further damage and protect the organization's network infrastructure. The detection is made by identifying specific DNS query types (SIG and KEY) in the Zeek DNS data and checks for high data transfer in the Zeek Conn data. If multiple instances of these indicators are found within a flow, it suggests the presence of SIGRed. The detection is important because it indicates a potential compromise of Windows DNS servers that suggests that an attacker might have gained unauthorized access to the DNS server and can run arbitrary code. The impact of this attack can be severe, leading to data exfiltration, unauthorized access, or disruption of critical services. Next steps include investigating the affected flow and taking immediate action to mitigate the vulnerability. This can involve patching the affected DNS server, isolating the server from the network, or conducting a forensic analysis to determine the extent of the compromise.
how_to_implement = You must be ingesting Zeek DNS and Zeek Conn data into Splunk. Zeek data should also be getting ingested in JSON format.  We are detecting SIG and KEY records via bro:dns:json and TCP payload over 65KB in size via bro:conn:json.  The Network Resolution and Network Traffic datamodels are in use for this search.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Installation"], "mitre_attack": ["T1203"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Detect Zerologon via Zeek - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic detects attempts to exploit the Zerologon CVE-2020-1472 vulnerability through Zeek RPC. By detecting attempts to exploit the Zerologon vulnerability through Zeek RPC, SOC analysts can identify potential threats earlier and take appropriate action to mitigate the risks. This detection is made by a Splunk query that looks for specific Zeek RPC operations, including NetrServerPasswordSet2, NetrServerReqChallenge, and NetrServerAuthenticate3, which are aggregated by source and destination IP address and time. This detection is important because it suggests that an attacker is attempting to exploit the Zerologon vulnerability to gain unauthorized access to the domain controller. Zerologon vulnerability is a critical vulnerability that allows attackers to take over domain controllers without authentication, leading to a complete takeover of an organization's IT infrastructure. The impact of such an attack can be severe, potentially leading to data theft, ransomware, or other devastating outcomes. False positives might occur since legitimate Zeek RPC activity can trigger the analytic. Next steps include reviewing the identified source and destination IP addresses and the specific RPC operations used. Capture and inspect any relevant on-disk artifacts, and review concurrent processes to identify the attack source upon triage .
how_to_implement = You must be ingesting Zeek DCE-RPC data into Splunk. Zeek data should also be getting ingested in JSON format.  We are detecting when all three RPC operations (NetrServerReqChallenge, NetrServerAuthenticate3, NetrServerPasswordSet2) are splunk_security_essentials_app via bro:rpc:json.  These three operations are then correlated on the Zeek UID field.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = ["Zeek"]

[savedsearch://ESCU - DNS Query Length Outliers - MLTK - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search allows you to identify DNS requests that are unusually large for the record type being requested in your environment.
how_to_implement = To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, the Machine Learning Toolkit (MLTK) version 4.2 or greater must be installed on your search heads, along with any required dependencies. Finally, the support search "Baseline of DNS Query Length - MLTK" must be executed before this detection search, because it builds a machine-learning (ML) model over the historical data used by this search. It is important that this search is run in the same app context as the associated support search, so that the model created by the support search is available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\
This search produces fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\\n1. **Label:** DNS Query, **Field:** query\
1. \
1. **Label:** DNS Query Length, **Field:** query_length\
1. \
1. **Label:** Number of events, **Field:** count\
Detailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.004", "T1071"], "nist": ["DE.AE"]}
known_false_positives = If you are seeing more results than desired, you may consider reducing the value for threshold in the search. You should also periodically re-run the support search to re-build the ML model on the latest data.
providing_technologies = null

[savedsearch://ESCU - DNS Query Length With High Standard Deviation - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search allows you to identify DNS requests and compute the standard deviation on the length of the names being resolved, then filter on two times the standard deviation to show you those queries that are unusually large for your environment.
how_to_implement = To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]}
known_false_positives = It's possible there can be long domain names that are legitimate.
providing_technologies = null

[savedsearch://ESCU - Excessive DNS Failures - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search identifies DNS query failures by counting the number of DNS responses that do not indicate success, and trigger on more than 50 occurrences.
how_to_implement = To successfully implement this search you must ensure that DNS data is populating the Network_Resolution data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1071.004", "T1071"], "nist": ["DE.AE"]}
known_false_positives = It is possible legitimate traffic can trigger this rule. Please investigate as appropriate. The threshold for generating an event can also be customized to better suit your environment.
providing_technologies = null

[savedsearch://ESCU - F5 BIG-IP iControl REST Vulnerability CVE-2022-1388 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies a recent unauthenticated remote code execution vulnerablity against the F5 BIG-IP iControl REST API. The analytic identifies the URI path found in the POCs and the HTTP Method of POST. In addition, the request header will have the commands that may be executed in fields utilcmdargs and the auth field of X-F5-Auth-Token, which may have a random base64 encoded value.
how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present if the activity is blocked or was not successful. Filter known vulnerablity scanners. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - High Volume of Bytes Out to Url - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects high volume of bytes out (greater than 1GB) to a URL within 2 mins of time window. This may be indicative of an attacker attempting to exfiltrate data.  The search applies a fundamental threshold for detecting significant web uploads. This approach aims to identify potential data exfiltration activities by malware or malevolent insiders. View the alert for $dest$ to investigate further.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. Please adjust the threshold for the sum of bytes out as per your environment and user behavior.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1567"], "nist": ["DE.AE"]}
known_false_positives = This search may trigger false positives if there is a legitimate reason for a high volume of bytes out to a URL. We recommend to investigate these findings. Consider updating the filter macro to exclude the applications that are relevant to your environment.
providing_technologies = null

[savedsearch://ESCU - Hosts receiving high volume of network traffic from email server - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for an increase of data transfers from your email server to your clients. This could be indicative of a malicious actor collecting data using your email server.
how_to_implement = This search requires you to be ingesting your network traffic and populating the Network_Traffic data model.  Your email servers must be categorized as "email_server" for the search to work, as well. You may need to adjust the deviation_threshold and minimum_data_samples values based on the network traffic in your environment. The "deviation_threshold" field is a multiplying factor to control how much variation you're willing to tolerate. The "minimum_data_samples" field is the minimum number of connections of data samples required for the statistic to be valid.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1114.002", "T1114"], "nist": ["DE.AE"]}
known_false_positives = The false-positive rate will vary based on how you set the deviation_threshold and data_samples values. Our recommendation is to adjust these values based on your network traffic to and from your email servers.
providing_technologies = null

[savedsearch://ESCU - Large Volume of DNS ANY Queries - Rule]
type = detection
asset_type = DNS Servers
confidence = medium
explanation = The search is used to identify attempts to use your DNS Infrastructure for DDoS purposes via a DNS amplification attack leveraging ANY queries.
how_to_implement = To successfully implement this search you must ensure that DNS data is populating the Network_Resolution data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1498", "T1498.002"], "nist": ["DE.AE"]}
known_false_positives = Legitimate ANY requests may trigger this search, however it is unusual to see a large volume of them under typical circumstances. You may modify the threshold in the search to better suit your environment.
providing_technologies = null

[savedsearch://ESCU - Multiple Archive Files Http Post Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is designed to detect high frequency of archive files data exfiltration through HTTP POST method protocol. This are one of the common techniques used by APT or trojan spy after doing the data collection like screenshot, recording, sensitive data to the infected machines. The attacker may execute archiving command to the collected data, save it a temp folder with a hidden attribute then send it to its C2 through HTTP POST. Sometimes adversaries will rename the archive files or encode/encrypt to cover their tracks. This detection can detect a renamed archive files transfer to HTTP POST since it checks the request body header. Unfortunately this detection cannot support archive that was encrypted or encoded before doing the exfiltration.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled in stream http configuration.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.CM"]}
known_false_positives = Normal archive transfer via HTTP protocol may trip this detection.
providing_technologies = null

[savedsearch://ESCU - Ngrok Reverse Proxy on Network - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies the 4 most common Ngrok used domains based on DNS queries under the Network Resolution datamodel. It's possible these domains may be ran against the Web datamodel or ran with a direct query across network/proxy traffic. The sign of someone using Ngrok is not malicious, however, more recenctly it has become an adversary tool.
how_to_implement = The Network Resolution Datamodel will need to have data mapped to it regarding DNS queries. Modify query as needed to use another source.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1572", "T1090", "T1102"], "nist": ["DE.AE"]}
known_false_positives = False positives will be present based on organizations that allow the use of Ngrok. Filter or monitor as needed.
providing_technologies = null

[savedsearch://ESCU - Plain HTTP POST Exfiltrated Data - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search is to detect potential plain HTTP POST method data exfiltration. This network traffic is commonly used by trickbot, trojanspy, keylogger or APT adversary where arguments or commands are sent in plain text to the remote C2 server using HTTP POST method as part of data exfiltration.
how_to_implement = To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Prohibited Network Traffic Allowed - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for network traffic defined by port and transport layer protocol in the Enterprise Security lookup table "lookup_interesting_ports", that is marked as prohibited, and has an associated 'allow' action in the Network_Traffic data model. This could be indicative of a misconfigured network device.
how_to_implement = In order to properly run this search, Splunk needs to ingest data from firewalls or other network control devices that mediate the traffic allowed into an environment. This is necessary so that the search can identify an 'action' taken on the traffic of interest. The search requires the Network_Traffic data model be populated.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048"], "nist": ["DE.CM"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - Protocol or Port Mismatch - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for network traffic on common ports where a higher layer protocol does not match the port that is being used. For example, this search should identify cases where protocols other than HTTP are running on TCP port 80. This can be used by attackers to circumvent firewall restrictions, or as an attempt to hide malicious communications over ports and protocols that are typically allowed and not well inspected.
how_to_implement = Running this search properly requires a technology that can inspect network traffic and identify common protocols. Technologies such as Bro and Palo Alto Networks firewalls are two examples that will identify protocols via inspection, and not just assume a specific protocol based on the transport protocol and ports.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Actions on Objectives"], "mitre_attack": ["T1048.003", "T1048"], "nist": ["DE.AE"]}
known_false_positives = None identified
providing_technologies = null

[savedsearch://ESCU - Protocols passing authentication in cleartext - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic identifies cleartext protocols at risk of leaking sensitive information. Currently, this consists of legacy protocols such as telnet (port 23), POP3 (port 110), IMAP (port 143), and non-anonymous FTP (port 21) sessions. While some of these protocols may be used over SSL, they typically are found on different assigned ports in those instances.
how_to_implement = This search requires you to be ingesting your network traffic, and populating the Network_Traffic data model. For more accurate result it's better to limit destination to organization private and public IP range, like All_Traffic.dest IN(192.168.0.0/16,172.16.0.0/12,10.0.0.0/8, x.x.x.x/22)
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = Some networks may use kerberized FTP or telnet servers, however, this is rare.
providing_technologies = null

[savedsearch://ESCU - Remote Desktop Network Bruteforce - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for RDP application network traffic and filters any source/destination pair generating more than twice the standard deviation of the average traffic.
how_to_implement = You must ensure that your network traffic data is populating the Network_Traffic data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.CM"]}
known_false_positives = RDP gateways may have unusually high amounts of traffic from all other hosts' RDP applications in the network.
providing_technologies = null

[savedsearch://ESCU - Remote Desktop Network Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for network traffic on TCP/3389, the default port used by remote desktop. While remote desktop traffic is not uncommon on a network, it is usually associated with known hosts. This search will ignore common RDP sources and common RDP destinations so you can focus on the uncommon uses of remote desktop on your network.
how_to_implement = To successfully implement this search you need to identify systems that commonly originate remote desktop traffic and that commonly receive remote desktop traffic. You can use the included support search "Identify Systems Creating Remote Desktop Traffic" to identify systems that originate the traffic and the search "Identify Systems Receiving Remote Desktop Traffic" to identify systems that receive a lot of remote desktop traffic. After identifying these systems, you will need to add the "common_rdp_source" or "common_rdp_destination" category to that system depending on the usage, using the Enterprise Security Assets and Identities framework.  This can be done by adding an entry in the assets.csv file located in SA-IdentityManagement/lookups.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.001", "T1021"], "nist": ["DE.AE"]}
known_false_positives = Remote Desktop may be used legitimately by users on the network.
providing_technologies = null

[savedsearch://ESCU - SMB Traffic Spike - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic detects spikes in the number of Server Message Block (SMB) traffic connections. SMB is a network protocol used for sharing files, printers, and other resources between computers. This detection is made by a Splunk query that looks for SMB traffic connections on ports 139 and 445, as well as connections using the SMB application. The query calculates the average and standard deviation of the number of SMB connections over the past 70 minutes, and identifies any sources that exceed two standard deviations from the average. This helps to filter out false positives caused by normal fluctuations in SMB traffic. This detection is important because it identifies potential SMB-based attacks, such as ransomware or data theft, which often involve a large number of SMB connections. This  suggests that an attacker is attempting to exfiltrate data or spread malware within the network. Next steps include investigating the source of the traffic and determining if it is malicious. This can involve reviewing network logs, capturing and analyzing any relevant network packets, and correlating with other security events to identify the attack source and mitigate the risk.
how_to_implement = This search requires you to be ingesting your network traffic logs and populating the `Network_Traffic` data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.002", "T1021"], "nist": ["DE.AE"]}
known_false_positives = A file server may experience high-demand loads that could cause this analytic to trigger.
providing_technologies = null

[savedsearch://ESCU - SMB Traffic Spike - MLTK - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search uses the Machine Learning Toolkit (MLTK) to identify spikes in the number of Server Message Block (SMB) connections.
how_to_implement = To successfully implement this search, you will need to ensure that DNS data is populating the Network_Traffic data model. In addition, the latest version of Machine Learning Toolkit (MLTK) must be installed on your search heads, along with any required dependencies. Finally, the support search "Baseline of SMB Traffic - MLTK" must be executed before this detection search, because it builds a machine-learning (ML) model over the historical data used by this search. It is important that this search is run in the same app context as the associated support search, so that the model created by the support search is available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\
This search produces a field (Number of events,count) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. This field contributes additional context to the notable. To see the additional metadata, add the following field, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry): \
1. **Label:** Number of events, **Field:** count\
Detailed documentation on how to create a new field within Incident Review is found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1021.002", "T1021"], "nist": ["DE.AE"]}
known_false_positives = If you are seeing more results than desired, you may consider reducing the value of the threshold in the search. You should also periodically re-run the support search to re-build the ML model on the latest data. Please update the `smb_traffic_spike_mltk_filter` macro to filter out false positive results
providing_technologies = null

[savedsearch://ESCU - Splunk Identified SSL TLS Certificates - Rule]
type = detection
asset_type = Proxy
confidence = medium
explanation = The following analytic uses tags of SSL, TLS and certificate to identify the usage of the Splunk default certificates being utilized in the environment. Recommended guidance is to utilize valid TLS certificates which documentation may be found in Splunk Docs - https://docs.splunk.com/Documentation/Splunk/8.2.6/Security/AboutsecuringyourSplunkconfigurationwithSSL.
how_to_implement = Ingestion of SSL/TLS data is needed and to be tagged properly as ssl, tls or certificate. This data may come from a proxy, zeek, or Splunk Streams. Splunk SOAR customers can find a SOAR workbook that walks an analyst through the process of running these hunting searches in the references list of this detection. In order to use this workbook, a user will need to run a curl command to post the file to their SOAR instance such as "curl -u username:password https://soar.instance.name/rest/rest/workbook_template -d @splunk_psa_0622.json". A user should then create an empty container or case, attach the workbook, and begin working through the tasks.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1040"], "nist": ["DE.AE"]}
known_false_positives = False positives will not be present as it is meant to assist with identifying default certificates being utilized.
providing_technologies = null

[savedsearch://ESCU - SSL Certificates with Punycode - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic utilizes the Certificates Datamodel to look for punycode domains, starting with xn--, found in the SSL issuer email domain. The presence of punycode here does not equate to evil, therefore we need to decode the punycode to determine what it translates to. Remove the CyberChef recipe as needed and decode manually. Note that this is not the exact location of the malicious punycode to trip CVE-2022-3602, but a method to at least identify fuzzing occurring on these email paths. What does evil look like? it will start with
how_to_implement = Ensure data is properly being ingested into the Certificates datamodel. If decoding the of interest, the CyberChef app is needed https://splunkbase.splunk.com/app/5348. If decoding is not needed, remove the cyberchef lines.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1573"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if the organization works with international businesses. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - TOR Traffic - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = The following analytic looks for allowed network traffic to The Onion Router(TOR), a benign anonymity network which can be abused for a variety of nefarious purposes. Detecting Tor traffic is paramount for upholding network security and mitigating potential threats. Tor's capacity to provide users with anonymity has been exploited by cybercriminals for activities like hacking, data breaches, and illicit content dissemination. Additionally, organizations must monitor Tor usage within their networks to ensure compliance with policies and regulations, as it can bypass conventional monitoring and filtering measures. Lastly, the ability to identify Tor traffic empowers security teams to promptly investigate and address potential security incidents, fortifying the protection of sensitive data and preserving the integrity of the network environment.
how_to_implement = In order to properly run this search, Splunk needs to ingest data from Next Generation Firewalls like Palo Alto Networks Firewalls or other network control devices that mediate the traffic allowed into an environment. This is necessary so that the search can identify an 'action' taken on the traffic of interest. The search requires the Network_Traffic data model to be populated.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1090", "T1090.003"], "nist": ["DE.CM"]}
known_false_positives = None at this time
providing_technologies = null

[savedsearch://ESCU - Unusually Long Content-Type Length - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = This search looks for unusually long strings in the Content-Type http header that the client sends the server.
how_to_implement = This particular search leverages data extracted from Stream:HTTP. You must configure the http stream using the Splunk Stream App on your Splunk Stream deployment server to extract the cs_content_type field.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.AE"]}
known_false_positives = Very few legitimate Content-Type fields will have a length greater than 100 characters.
providing_technologies = null

[savedsearch://ESCU - Windows AD Replication Service Traffic - Rule]
type = detection
asset_type = endpoint
confidence = medium
explanation = This search looks for evidence of Active Directory replication traffic [MS-DRSR] from unexpected sources. This traffic is often seen exclusively between Domain Controllers for AD database replication. Any detections from non-domain controller source to a domain controller may indicate the usage of DCSync or DCShadow credential dumping techniques.
how_to_implement = To successfully implement this search, you need to be ingesting application aware firewall or proxy logs into the Network Datamodel. Categorize all known domain controller Assets servers with an appropriate category for filtering.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1003", "T1003.006", "T1207"], "nist": ["DE.CM"]}
known_false_positives = New domain controllers or certian scripts run by administrators.
providing_technologies = null

[savedsearch://ESCU - Windows AD Rogue Domain Controller Network Activity - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This detection is looking at zeek wiredata for specific replication RPC calls being performed from a device which is not a domain controller. If you would like to capture these RPC calls using Splunk Stream, please vote for my idea here https://ideas.splunk.com/ideas/APPSID-I-619 ;)
how_to_implement = Run zeek on domain controllers to capture the DCE RPC calls, ensure the domain controller categories are defined in Assets and Identities.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1207"], "nist": ["DE.CM"]}
known_false_positives = None.
providing_technologies = ["Zeek"]

[savedsearch://ESCU - Zeek x509 Certificate with Punycode - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic utilizes the Zeek x509 log. Modify the zeek_x509 macro with your index and sourcetype as needed. You will need to ensure the full x509 is logged as the potentially malicious punycode is nested under subject alternative names. In this particular analytic, it will identify punycode within the subject alternative name email and other fields. Note, that OtherFields is meant to be BOOL (true,false), therefore we may never see xn-- in that field. Upon identifying punycode, manually copy and paste, or add CyberChef recipe to query, and decode the punycode manually.
how_to_implement = The following analytic requires x509 certificate data to be logged entirely. In particular, for CVE-2022-3602, the punycode will be within the leaf certificate. The analytic may be modified to look for all xn--, or utilize a network IDS/monitoring tool like Zeek or Suricata to drill down into cert captured. Note for Suricata, the certificate is base64 encoded and will need to be decoded to capture the punycode (punycode will need to be decoded after).
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1573"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if the organization works with international businesses. Filter as needed.
providing_technologies = ["Zeek"]

[savedsearch://ESCU - Access to Vulnerable Ivanti Connect Secure Bookmark Endpoint - Rule]
type = detection
asset_type = VPN Appliance
confidence = medium
explanation = This analytic monitors access to the /api/v1/configuration/users/user-roles/user-role/rest-userrole1/web/web-bookmarks/bookmark endpoint, a key indicator for both CVE-2023-46805 and CVE-2024-21887 vulnerabilities. It detects potential vulnerabilities by looking for a 403 Forbidden response with an empty body on this endpoint. This detection method is used in both Nmap script and Project Discovery Nuclei, with the latter focusing on systems where XML mitigation for these vulnerabilities has not been applied.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = This analytic is limited to HTTP Status 403; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
providing_technologies = null

[savedsearch://ESCU - Adobe ColdFusion Access Control Bypass - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic detects potential exploitation attempts against Adobe ColdFusion vulnerabilities CVE-2023-29298 and CVE-2023-26360. These vulnerabilities pertain to an access control bypass and an arbitrary file read due to deserialization, respectively. By monitoring for requests to specific ColdFusion Administrator endpoints, especially those with an unexpected additional forward slash, the analytic identifies attempts to bypass access controls. Such behavior is crucial for a Security Operations Center (SOC) to identify, as exploitation can grant unauthorized access to ColdFusion administration endpoints, potentially leading to information leakage, brute force attacks, or further exploitation of other vulnerabilities. If a true positive is detected, it indicates a serious security breach where an attacker might have gained privileged access to the ColdFusion environment, potentially leading to data theft or other malicious activities. SOCs must be vigilant in monitoring for these patterns, ensuring timely detection and response to such threats, thus safeguarding the integrity and security of their ColdFusion deployments.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
providing_technologies = null

[savedsearch://ESCU - Adobe ColdFusion Unauthenticated Arbitrary File Read - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic detects potential exploitation of the critical Adobe ColdFusion vulnerability, CVE-2023-26360. This flaw, rooted in the deserialization of untrusted data, enables Unauthenticated Arbitrary File Read. Exploitation often targets specific ColdFusion paths, especially related to CKEditor's file manager. \
Our analytic pinpoints exploitation by monitoring web requests to the "/cf_scripts/scripts/ajax/ckeditor/*" path. This focus helps differentiate malicious activity from standard ColdFusion traffic. For SOCs, detecting such attempts is vital given the vulnerability's CVSS score of 9.8, signaling its severity. Successful exploitation can lead to unauthorized data access, further attacks, or severe operational disruptions. \
If a true positive arises, it indicates an active breach attempt, potentially causing data theft, operational disruption, or reputational damage. In essence, this analytic provides a targeted approach to identify attempts exploiting a high-risk ColdFusion vulnerability. While false positives may occur from legitimate accesses, any alerts should be treated as high-priority, warranting immediate investigation to ensure security.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = In the wild, we have observed three different types of attempts that could potentially trigger false positives if the HTTP status code is not in the query. Please check this github gist for the specific URIs : https://gist.github.com/patel-bhavin/d10830f3f375a2397233f6a4fe38d5c9 . These could be legitimate requests depending on the context of your organization. Therefore, it is recommended to modify the analytic as needed to suit your specific environment.
providing_technologies = null

[savedsearch://ESCU - Cisco IOS XE Implant Access - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic identifies potential exploitation of a previously unknown vulnerability in the Web User Interface (Web UI) feature of Cisco IOS XE software (CVE-2023-20198). Successful exploitation allows an attacker to create an account on the affected device with privilege level 15 access, granting them full control of the compromised device. The detection is based on the observation of suspicious account creation and subsequent actions, including the deployment of an implant consisting of a configuration file. The implant is saved under the file path //usr//binos//conf//nginx-conf//cisco_service.conf and is not persistent, meaning a device reboot will remove it, but the newly created local user accounts remain active even after system reboots. The new user accounts have level 15 privileges, meaning they have full administrator access to the device. This privileged access to the devices and subsequent creation of new users is tracked as CVE-2023-20198.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, restrict to Cisco IOS XE devices or perimeter appliances. Modify the analytic as needed based on hunting for successful exploitation of CVE-2023-20198.
providing_technologies = null

[savedsearch://ESCU - Citrix ADC and Gateway Unauthorized Data Disclosure - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic detects attempts to exploit the Citrix Bleed vulnerability, which can lead to the leaking of session tokens. The vulnerability, identified as CVE-2023-4966, pertains to sensitive information disclosure in NetScaler ADC and NetScaler Gateway when set up as various server configurations. The analytic specifically searches for HTTP requests with a 200 status code targeting the /oauth/idp/.well-known/openid-configuration URL endpoint. By parsing web traffic and filtering based on the aforementioned criteria along with specific user agent details, HTTP method, source and destination IPs, and the sourcetype, the analytic aims to identify potentially malicious requests that fit the profile of this exploit. \
This behavior is essential for a Security Operations Center (SOC) to identify because if successfully exploited, attackers can gain unauthorized access, leading to a potential breach or further malicious activities within the organization's network. As the Citrix Bleed vulnerability can disclose session tokens, a successful exploit can allow attackers to impersonate legitimate users, bypassing authentication mechanisms and accessing sensitive data or systems. \
If a true positive is confirmed, it implies that an attacker is actively exploiting the vulnerability within the organization's environment. This could lead to severe consequences, including unauthorized data access, further propagation within the network, and potential disruptions or exfiltration of critical information. \
Upon flagging such activity, it's crucial for analysts to swiftly validate the alert, assess the nature and extent of the exposure, and implement necessary measures to mitigate the threat. Reviewing the details such as user agent, source, and destination IP can help in understanding the context and intent of the attack. While it's imperative to patch vulnerable systems to prevent this exploitation, early detection through this analytic provides a valuable layer of defense, enabling timely response to thwart potential breaches.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. We recommend hunting in the environment first to understand the scope of the issue and then deploying this detection to monitor for future exploitation attempts. Limit or restrict to Citrix devices only if possible.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present based on organization use of Citrix ADC and Gateway. Filter, or restrict the analytic to Citrix devices only.
providing_technologies = null

[savedsearch://ESCU - Citrix ADC Exploitation CVE-2023-3519 - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = This analytic is designed to assist in hunting for potential exploitation attempts against Citrix ADC in relation to CVE-2023-3519. This vulnerability, identified within Citrix ADC and NetScaler Gateway, appears to be linked with SAML processing components, with an overflow issue allowing for possible memory corruption. Preliminary findings indicate that for the exploit to be viable, SAML has to be enabled. The analytic targets POST requests to certain web endpoints which have been associated with the exploitation process. \
Given the specific nature of the vulnerability, upon deploying this analytic it is recommended to filter and narrow the focus towards your ADC assets to reduce potential noise and improve the signal of the analytic. Please note that the exploitation of this vulnerability has been reported in the wild, therefore monitoring for potential signs of exploitation should be considered high priority. \
The search query provided examines web data for POST requests made to specific URLs associated with the exploitation of this vulnerability. It aggregates and presents data to highlight potential exploitation attempts, taking into account elements like user agent, HTTP method, URL length, source, and destination. \
Please be aware that this analytic is based on current understanding of the vulnerability, and adjustments may be required as more information becomes available.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present based on organization use of SAML utilities. Filter, or restrict the analytic to Citrix devices only.
providing_technologies = null

[savedsearch://ESCU - Citrix ShareFile Exploitation CVE-2023-24489 - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic detects a potentially malicious file upload attempt to Documentum, an enterprise content management platform, via specific suspicious URLs and the HTTP POST method. This detection occurs through pattern recognition within the datamodel=Web, focusing on URL patterns that follow "/documentum/upload.aspx?parentid=", "/documentum/upload.aspx?filename=", "/documentum/upload.aspx?uploadId=*", combined with the HTTP POST method, indicative of a file upload attempt. \
This behavior is significant for a Security Operations Center (SOC) to identify, as it can signify a potential attack vector. Malicious actors might use this method to upload a harmful script or other exploitable content to Documentum, thereby establishing a foothold in the environment, spreading malware, or enabling further exploitation. \
The impact of this behavior, if a true positive, can be quite significant. An attacker could compromise the Documentum application, manipulate or steal sensitive content, and potentially gain unauthorized access to other system resources. An intrusion of this nature could disrupt business operations, result in data breaches, and even damage the organization's reputation. \
However, it's important to note that false positives may occur. For example, legitimate but uncommon file uploads might match these URL patterns. It's crucial to verify any alerts generated by this analytic to ensure accurate threat detection. This analytic provides critical insights into potential attack attempts and assists in maintaining the integrity and security of enterprise content management systems like Documentum.
how_to_implement = Dependent upon the placement of the ShareFile application, ensure the latest Technology Add-On is eneabled. This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. The ShareFile application is IIS based, therefore ingesting IIS logs and reviewing for the same pattern would identify this activity, successful or not.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present, filtering may be needed. Also, restricting to known web servers running IIS or ShareFile will change this from Hunting to TTP.
providing_technologies = null

[savedsearch://ESCU - Confluence CVE-2023-22515 Trigger Vulnerability - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, targeting the /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=false* and /server-info.action?bootstrapStatusProvider.applicationConfig.setupComplete=0& URLs. By analyzing web logs within the Splunk 'Web' Data Model, it filters for successful accesses (HTTP status 200) to these vulnerable endpoints. Such behavior is crucial for a SOC to monitor, as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. A true positive implies a possible unauthorized access or account creation with escalated privileges. Key details captured include user-agent, HTTP methods, URL length, and source and destination IPs. These insights aid SOCs in swiftly detecting and responding to threats, ensuring vulnerabilities are mitigated before substantial compromise.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel. Tested with Suricata and nginx:plus:kv.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to Confluence servers.
providing_technologies = null

[savedsearch://ESCU - Confluence Data Center and Server Privilege Escalation - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic identifies potential exploitation attempts on a known vulnerability in Atlassian Confluence, targeting the /setup/*.action* URL pattern. By analyzing web logs within the Splunk 'Web' Data Model, it filters for successful accesses (HTTP status 200) to these vulnerable endpoints. Such behavior is crucial for a SOC to monitor, as it suggests attackers might be exploiting a privilege escalation flaw in Confluence. A true positive implies a possible unauthorized access or account creation with escalated privileges. Key details captured include user-agent, HTTP methods, URL length, and source and destination IPs. These insights aid SOCs in swiftly detecting and responding to threats, ensuring vulnerabilities are mitigated before substantial compromise.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to confluence servers.
providing_technologies = null

[savedsearch://ESCU - Confluence Pre-Auth RCE via OGNL Injection CVE-2023-22527 - Rule]
type = detection
asset_type = Web Application
confidence = medium
explanation = This analytic identifies a critical template injection vulnerability (CVE-2023-22527) in outdated versions of Confluence Data Center and Server, which allows an unauthenticated attacker to execute arbitrary code remotely. The vulnerability is exploited by injecting OGNL (Object-Graph Navigation Language) expressions into the application, as evidenced by POST requests to the "/template/aui/text-inline.vm" endpoint with specific content types and payloads. The search looks for POST requests with HTTP status codes 200 or 202, which may indicate successful exploitation attempts. Immediate patching to the latest version of Confluence is strongly recommended, as there are no known workarounds. This detection is crucial for identifying and responding to potential RCE attacks, ensuring that affected Confluence instances are secured against this critical threat.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to confluence servers.
providing_technologies = null

[savedsearch://ESCU - Confluence Unauthenticated Remote Code Execution CVE-2022-26134 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic assists with identifying CVE-2022-26134 based exploitation utilizing the Web datamodel to cover network and CIM compliant web logs. The parameters were captured from live scanning and the POC provided by Rapid7. This analytic is written against multiple proof of concept codes released and seen in the wild (scanning). During triage, review any endpoint based logs for further activity including writing a jsp file to disk and commands/processes spawning running as root from the Confluence process.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache or Splunk for Nginx. In addition, network based logs or event data like PAN Threat.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505", "T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = Tune based on assets if possible, or restrict to known Confluence servers. Remove the ${ for a more broad query. To identify more exec, remove everything up to the last parameter (Runtime().exec) for a broad query.
providing_technologies = null

[savedsearch://ESCU - ConnectWise ScreenConnect Authentication Bypass - Rule]
type = detection
asset_type = Web
confidence = medium
explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows an attacker to bypass authentication using an alternate path or channel. The vulnerability, identified as critical with a CVSS score of 10, enables unauthorized users to access the SetupWizard.aspx page on already-configured ScreenConnect instances, potentially leading to the creation of administrative users and remote code execution. The search query provided looks for web requests to the SetupWizard.aspx page that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers.
how_to_implement = To implement this analytic, ensure proper logging is occurring with IIS, Apache, or a Proxy server and that these logs are being ingested into Splunk. The analytic was written against Suricata. The proper TA will need to be enabled and should be mapped to CIM and the Web datamodel. Ingestion of the data source is required to utilize this detection. In addition, if it is not mapped to the datamodel, modify the query for your application logs to look for requests the same URI and investigate further.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected, as the detection is based on the presence of web requests to the SetupWizard.aspx page, which is not a common page to be accessed by legitimate users. Note that the analytic is limited to HTTP POST and a status of 200 to reduce false positives. Modify the query as needed to reduce false positives or hunt for additional indicators of compromise.
providing_technologies = null

[savedsearch://ESCU - Detect attackers scanning for vulnerable JBoss servers - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = This search looks for specific GET or HEAD requests to web servers that are indicative of reconnaissance attempts to identify vulnerable JBoss servers. JexBoss is described as the exploit tool of choice for this malicious activity.
how_to_implement = You must be ingesting data from the web server or network traffic that contains web specific information, and populating the Web data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation", "Delivery", "Installation"], "mitre_attack": ["T1082", "T1133"], "nist": ["DE.CM"]}
known_false_positives = It's possible for legitimate HTTP requests to be made to URLs containing the suspicious paths.
providing_technologies = null

[savedsearch://ESCU - Detect F5 TMUI RCE CVE-2020-5902 - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = This search detects remote code exploit attempts on F5 BIG-IP, BIG-IQ, and Traffix SDC devices
how_to_implement = To consistently detect exploit attempts on F5 devices using the vulnerabilities contained within CVE-2020-5902 it is recommended to ingest logs via syslog.  As many BIG-IP devices will have SSL enabled on their management interfaces, detections via wire data may not pick anything up unless you are decrypting SSL traffic in order to inspect it.  I am using a regex string from a Cloudflare mitigation technique to try and always catch the offending string (..;), along with the other exploit of using (hsqldb;).
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = unknown
providing_technologies = null

[savedsearch://ESCU - Detect malicious requests to exploit JBoss servers - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = This search is used to detect malicious HTTP requests crafted to exploit jmx-console in JBoss servers. The malicious requests have a long URL length, as the payload is embedded in the URL.
how_to_implement = You must ingest data from the web server or capture network data that contains web specific information with solutions such as Bro or Splunk Stream, and populating the Web data model
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = No known false positives for this detection.
providing_technologies = null

[savedsearch://ESCU - Detect Remote Access Software Usage URL - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic detects when a known remote access software is executed with the environment. Adversaries use these utilities to retain remote access capabilities to the environment. Utilities in the lookup include AnyDesk, GoToMyPC, LogMeIn, TeamViewer and much more. Review the lookup for the entire list and add any others.
how_to_implement = The detection is based on data that originates from network logs. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the network logs. The logs must also be mapped to the `Web` data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Command and Control"], "mitre_attack": ["T1219"], "nist": ["DE.AE"]}
known_false_positives = It is possible that legitimate remote access software is used within the environment. Ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment.
providing_technologies = null

[savedsearch://ESCU - Exploit Public Facing Application via Apache Commons Text - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies activity related to Text4Shell, or the critical vulnerability CVE-2022-42889 in Apache Commons Text Library. Apache Commons Text versions 1.5 through 1.9 are affected, but it has been patched in version 1.10. The analytic may need to be tuned for your environment before enabling as a TTP, or direct Notable. Apache Commons Text is a Java library described as a library focused on algorithms working on strings. We can see it as a general-purpose text manipulation toolkit. This vulnerability affects the StringSubstitutor interpolator class, which is included in the Commons Text library. A default interpolator allows for string lookups that can lead to Remote Code Execution. This is due to a logic flaw that makes the script, dns, and url lookup keys interpolated by default, as opposed to what it should be, according to the documentation of the StringLookupFactory class. Those keys allow an attacker to execute arbitrary code via lookups.
how_to_implement = To implement, one must be collecting network traffic that is normalized in CIM and able to be queried via the Web datamodel. Or, take the chunks out needed and tie to a specific network source type to hunt in. Tune as needed, or remove the other_lookups statement.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505.003", "T1505", "T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = False positives are present when the values are set to 1 for utf and lookup. It's possible to raise this to TTP (direct notable) if removal of other_lookups occur and Score is raised to 2 (down from 4).
providing_technologies = null

[savedsearch://ESCU - Exploit Public-Facing Fortinet FortiNAC CVE-2022-39952 - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic identifies a recent CVE-2022-39952 released publicly where the URI configWizard/keyUpload.jsp recieves a POST with the payload.zip, from there the POC script will schedule a cron to run the payload and contact the remote C2.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present. Modify the query as needed to POST, or add additional filtering (based on log source).
providing_technologies = null

[savedsearch://ESCU - F5 TMUI Authentication Bypass - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = The following analytic is designed to detect attempts to exploit the CVE-2023-46747 vulnerability, a critical authentication bypass flaw in F5 BIG-IP that can lead to unauthenticated remote code execution (RCE). This vulnerability specifically affects the BIG-IP Configuration utility (TMUI) and has been assigned a high severity CVSSv3 score of 9.8. The analytic identifies this behavior by monitoring for a specific URI path - "*/mgmt/tm/auth/user/*", with the PATCH method and 200 status. Additional URI's will occur around the same time include "*/mgmt/shared/authn/login*" and "*/tmui/login.jsp*", which are associated with the exploitation of this vulnerability. This behavior is significant for a Security Operations Center (SOC) as it indicates an attempt to bypass authentication mechanisms, potentially leading to unauthorized access and control over the system. If a true positive is identified, it suggests that an attacker is attempting to exploit a known vulnerability to gain unauthorized access and execute arbitrary code, which could lead to data theft, system disruption, or further malicious activities within the network.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relevant for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 10"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited to as this is strict to active exploitation. Reduce noise by filtering to F5 devices with TMUI enabled or filter data as needed.
providing_technologies = null

[savedsearch://ESCU - Fortinet Appliance Auth bypass - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = CVE-2022-40684 is a Fortinet appliance auth bypass that is actively being exploited and a POC is released publicy. The POC adds a SSH key to the appliance. Note that the exploit can be used with any HTTP method (GET, POST, PUT, DELETE, etc). The REST API request failing is not an indication that an attacker was unsuccessful. Horizon3 was able to modify the admin SSH keys though a REST API request that reportedly failed. The collection /api/v2/ endpoints can be used to configure the system and modify the administrator user. Any logs found that meet the above conditions and also have a URL containing /api/v2/ should be cause for concern. Further investigation of any matching log entries can reveal any damage an attack has done. Additionally, an attacker may perform the following actions to further compromise a system Modify the admin SSH key to enable the attacker to login to the compromised system. \
Add new local users. \
Update networking configurations to reroute traffic. \
Download the system configuration. \
Initiate packet captures to capture other sensitive system information. Reference Horizon3.ai
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache. Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = GET requests will be noisy and need to be filtered out or removed from the query based on volume. Restrict analytic to known publically facing Fortigates, or run analytic as a Hunt until properly tuned. It is also possible the user agent may be filtered on Report Runner or Node.js only for the exploit, however, it is unknown at this if other user agents may be used.
providing_technologies = null

[savedsearch://ESCU - Hunting for Log4Shell - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following hunting query assists with quickly assessing CVE-2021-44228, or Log4Shell, activity mapped to the Web Datamodel. This is a combination query attempting to identify, score and dashboard. Because the Log4Shell vulnerability requires the string to be in the logs, this will work to identify the activity anywhere in the HTTP headers using _raw. Modify the first line to use the same pattern matching against other log sources. Scoring is based on a simple rubric of 0-5. 5 being the best match, and less than 5 meant to identify additional patterns that will equate to a higher total score. \
The first jndi match identifies the standard pattern of `{jndi:` \
jndi_fastmatch is meant to identify any jndi in the logs. The score is set low and is meant to be the "base" score used later. \
jndi_proto is a protocol match that identifies `jndi` and one of `ldap, ldaps, rmi, dns, nis, iiop, corba, nds, http, https.` \
all_match is a very well written regex by https://gist.github.com/Schvenn that identifies nearly all patterns of this attack behavior. \
env works to identify environment variables in the header, meant to capture `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `env`. \
uri_detect is string match looking for the common uri paths currently being scanned/abused in the wild. \
keywords matches on enumerated values that, like `$ctx:loginId`, that may be found in the header used by the adversary. \
lookup matching is meant to catch some basic obfuscation that has been identified using upper, lower and date. \
Scoring will then occur based on any findings. The base score is meant to be 2 , created by jndi_fastmatch. Everything else is meant to increase that score. \
Finally, a simple table is created to show the scoring and the _raw field. Sort based on score or columns of interest.
how_to_implement = Out of the box, the Web datamodel is required to be pre-filled. However, tested was performed against raw httpd access logs. Change the first line to any dataset to pass the regex's against.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = It is highly possible you will find false positives, however, the base score is set to 2 for _any_ jndi found in raw logs. tune and change as needed, include any filtering.
providing_technologies = null

[savedsearch://ESCU - Ivanti Connect Secure Command Injection Attempts - Rule]
type = detection
asset_type = VPN Appliance
confidence = medium
explanation = This analytic is designed to identify the exploit phase of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a POST request is made to the /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection URI. This request exploits the command injection vulnerability to execute arbitrary commands. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
providing_technologies = null

[savedsearch://ESCU - Ivanti Connect Secure SSRF in SAML Component - Rule]
type = detection
asset_type = VPN Appliance
confidence = medium
explanation = The following analytic is designed to identify POST request activities targeting specific endpoints known to be vulnerable to the SSRF issue (CVE-2024-21893) in Ivanti's products. It aggregates data from the Web data model, focusing on endpoints /dana-ws/saml20.ws, /dana-ws/saml.ws, /dana-ws/samlecp.ws, and /dana-na/auth/saml-logout.cgi. The query filters for POST requests that received a HTTP 200 OK response, indicating successful request execution.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the HTTP Status is removed, as most failed attempts result in a 301. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
providing_technologies = null

[savedsearch://ESCU - Ivanti Connect Secure System Information Access via Auth Bypass - Rule]
type = detection
asset_type = VPN Appliance
confidence = medium
explanation = This analytic is designed to identify the "check phase" of the CVE-2023-46805 and CVE-2024-21887 vulnerabilities. During this phase, a GET request is made to the /api/v1/totp/user-backup-code/../../system/system-information URI. This request exploits the authentication bypass vulnerability to gain access to system information. A successful request, indicated by a 200 OK response, suggests that the system is vulnerable.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.AE"]}
known_false_positives = This analytic is limited to HTTP Status 200; adjust as necessary. False positives may occur if the URI path is IP-restricted or externally blocked. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
providing_technologies = null

[savedsearch://ESCU - Ivanti EPMM Remote Unauthenticated API Access CVE-2023-35078 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The given analytic is designed to detect the exploitation of CVE-2023-35078, a vulnerability in Ivanti Endpoint Manager Mobile (EPMM) affecting versions up to 11.4. Specifically, the query searches web logs for HTTP requests to the potentially vulnerable endpoint "/mifs/aad/api/v2/authorized/users?*" with a successful status code of 200. This analytic is instrumental in detecting unauthorized remote access to restricted functionalities or resources within the application, a behavior worth identifying for a Security Operations Center (SOC). By monitoring specific patterns and successful access indicators, it reveals an active attempt to exploit the vulnerability, potentially leading to data theft, unauthorized modifications, or further system compromise. If successfully executed, the impact can be severe, necessitating immediate action.
how_to_implement = To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = The Proof of Concept exploit script indicates that status=200 is required for successful exploitation of the vulnerability. False positives may be present if status=200 is removed from the search.  If it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts.  Analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability.
providing_technologies = null

[savedsearch://ESCU - Ivanti EPMM Remote Unauthenticated API Access CVE-2023-35082 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic detects potential unauthorized access attempts exploiting CVE-2023-35082 within Ivantis software products. Initially assessed to affect only MobileIron Core versions up to 11.2, further insights revealed its influence extending to Ivanti Endpoint Manager Mobile (EPMM) versions 11.10, 11.9, 11.8, and MobileIron Core 11.7 and below. The vulnerability facilitates unauthorized API access via the specific URI path /mifs/asfV3/api/v2/. The analytic identifies this behavior by monitoring web access logs for this URI pattern coupled with a HTTP 200 response code, signifying successful unauthorized access. \ Such behavior is imperative for a Security Operations Center (SOC) to recognize, as it highlights potential security breaches which, if not addressed, could lead to unauthorized data access, system modifications, or further exploitation. In the event of a true positive, the implications are severe: an attacker might have gained unbridled access to sensitive organizational data or could modify systems maliciously. Be vigilant of potential false positives; benign activities might occasionally match the pattern. During triage, closely scrutinize the source of the access request and its subsequent actions. This analytic aids analysts in early threat detection, allowing for proactive risk mitigation.
how_to_implement = To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = Similar to CVE-2023-35078, the path for exploitation indicates that status=200 is required for successful exploitation of the vulnerability. False positives may be present if status=200 is removed from the search.  If it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts.  Analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability.
providing_technologies = null

[savedsearch://ESCU - Ivanti Sentry Authentication Bypass - Rule]
type = detection
asset_type = Network
confidence = medium
explanation = This analytic is designed to detect unauthenticated access to the System Manager Portal in Ivanti Sentry, formerly known as MobileIron Sentry. The vulnerability, designated as CVE-2023-38035, affects all supported versions 9.18, 9.17, and 9.16, as well as older versions. The analytic works by monitoring for changes in the configuration of Sentry and the underlying operating system. Such changes could indicate an attacker attempting to execute OS commands as root. This behavior is of significant concern for a Security Operations Center (SOC) as it presents a substantial security risk, particularly if port 8443, the default port for the System Manager Portal, is exposed to the internet. If the analytic returns a true positive, it suggests that an attacker has gained unauthorized access to the Sentry system, potentially leading to a significant system compromise and data breach. It is important to note that while the issue has a high CVSS score, the risk of exploitation is low for customers who do not expose port 8443 to the internet. The search specifically looks for HTTP requests to certain endpoints ("/mics/services/configservice/*", "/mics/services/*","/mics/services/MICSLogService*") and HTTP status code of 200. Unusual or unexpected patterns in these parameters could indicate an attack.
how_to_implement = To implement this analytic, a network product similar to Suricata or Palo Alto needs to be mapped to the Web datamodel. Modify accordingly to work with your products.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = It is important to note that false positives may occur if the search criteria are expanded beyond the HTTP status code 200. In other words, if the search includes other HTTP status codes, the likelihood of encountering false positives increases. This is due to the fact that HTTP status codes other than 200 may not necessarily indicate a successful exploitation attempt.
providing_technologies = null

[savedsearch://ESCU - Jenkins Arbitrary File Read CVE-2024-23897 - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analtyic identifies a Jenkins Arbitrary File Read CVE-2024-23897 exploitation. This attack allows an attacker to read arbitrary files on the Jenkins server. This can be used to obtain sensitive information such as credentials, private keys, and other sensitive information.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Suricata, Splunk for Apache, Splunk for Nginx, or Splunk for Palo Alto. If unable to utilize the Web datamodel, modify query to your data source.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives should be limited as this detection is based on a specific URL path and HTTP status code. Adjust the search as necessary to fit the environment.
providing_technologies = null

[savedsearch://ESCU - JetBrains TeamCity Authentication Bypass CVE-2024-27198 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The CVE-2024-27198 vulnerability presents a critical security risk for JetBrains TeamCity on-premises servers, allowing attackers to bypass authentication mechanisms and gain unauthorized access. This vulnerability can be exploited in several ways, each leading to the attacker gaining full control over the TeamCity server, including all associated projects, builds, agents, and artifacts. One method of exploitation involves creating a new administrator user. An attacker, without needing to authenticate, can send a specially crafted POST request to the `/app/rest/users` REST API endpoint. This request includes the desired username, password, email, and roles for the new user, effectively granting them administrative privileges upon successful execution. Alternatively, an attacker can generate a new administrator access token by targeting the `/app/rest/users/id:1/tokens` endpoint with a POST request. This method also does not require prior authentication and results in the creation of a token that grants administrative access. Both exploitation methods underscore the severity of the CVE-2024-27198 vulnerability and highlight the importance of securing TeamCity servers against such authentication bypass threats. The manipulation of URI paths `/app/rest/users` and `/app/rest/users/id:1/tokens` through malicious requests enables attackers to gain unauthorized access and control, emphasizing the need for immediate remediation measures.
how_to_implement = The detection relies on the Web datamodel and a CIM compliant log source, that may include Nginx, TeamCity logs, or other web server logs.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected, as this detection is based on the presence of specific URI paths and HTTP methods that are indicative of the CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based on organization log sources.
providing_technologies = null

[savedsearch://ESCU - JetBrains TeamCity Authentication Bypass Suricata CVE-2024-27198 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The CVE-2024-27198 vulnerability presents a critical security risk for JetBrains TeamCity on-premises servers, allowing attackers to bypass authentication mechanisms and gain unauthorized access. This vulnerability can be exploited in several ways, each leading to the attacker gaining full control over the TeamCity server, including all associated projects, builds, agents, and artifacts. One method of exploitation involves creating a new administrator user. An attacker, without needing to authenticate, can send a specially crafted POST request to the `/app/rest/users` REST API endpoint. This request includes the desired username, password, email, and roles for the new user, effectively granting them administrative privileges upon successful execution.Alternatively, an attacker can generate a new administrator access token by targeting the `/app/rest/users/id:1/tokens` endpoint with a POST request. This method also does not require prior authentication and results in the creation of a token that grants administrative access. Both exploitation methods underscore the severity of the CVE-2024-27198 vulnerability and highlight the importance of securing TeamCity servers against such authentication bypass threats. The manipulation of URI paths `/app/rest/users` and `/app/rest/users/id:1/tokens` through malicious requests enables attackers to gain unauthorized access and control, emphasizing the need for immediate remediation measures.
how_to_implement = The following detection relies on the Suricata TA and ensuring it is properly configured to monitor HTTP traffic. Modify the query for your environment and log sources as needed.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected, as this detection is based on the presence of specific URI paths and HTTP methods that are indicative of the CVE-2024-27198 vulnerability exploitation. Monitor, filter and tune as needed based on organization log sources.
providing_technologies = null

[savedsearch://ESCU - JetBrains TeamCity Limited Auth Bypass Suricata CVE-2024-27199 - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = CVE-2024-27199 reveals a critical vulnerability in JetBrains TeamCity web server, allowing unauthenticated attackers to bypass authentication for a limited set of endpoints. This vulnerability exploits path traversal issues, enabling attackers to access and potentially modify system settings or disclose sensitive server information without proper authentication. Identified vulnerable paths include /res/, /update/, and /.well-known/acme-challenge/, among others. Attackers can manipulate these paths to reach restricted JSP pages and servlet endpoints, such as /app/https/settings/uploadCertificate, which could allow for the uploading of malicious HTTPS certificates or modification of server settings. This detection aims to identify potential exploitation attempts by monitoring for unusual access patterns to these endpoints, which could indicate an authentication bypass attempt in progress.
how_to_implement = The following detection relies on the Suricata TA and ensuring it is properly configured to monitor HTTP traffic. Modify the query for your environment and log sources as needed.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected, however, monitor, filter, and tune as needed based on organization log sources. The analytic is restricted to 200 and GET requests to specific URI paths, which should limit false positives.
providing_technologies = null

[savedsearch://ESCU - JetBrains TeamCity RCE Attempt - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic is designed to detect attempts to exploit the CVE-2023-42793 vulnerability in TeamCity On-Premises. It focuses on identifying suspicious POST requests to /app/rest/users/id:1/tokens/RPC2, which is the initial point of exploitation. This could indicate an unauthenticated attacker trying to gain administrative access through Remote Code Execution (RCE).
how_to_implement = The following analytic requires the Web datamodel. Ensure data source is mapped correctly or modify and tune for your data source.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = If TeamCity is not in use, this analytic will not return results. Monitor and tune for your environment.
providing_technologies = null

[savedsearch://ESCU - Juniper Networks Remote Code Execution Exploit Detection - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic detects the exploitation of a remote code execution vulnerability in Juniper Networks devices. The vulnerability involves multiple steps, including uploading a malicious PHP file and an INI file to the target server, and then executing the PHP code by manipulating the PHP configuration via the uploaded INI file. The analytic specifically looks for requests to /webauth_operation.php?PHPRC=*, which are used to upload the files and execute the code, respectively. This behavior is worth identifying for a SOC because it indicates that an attacker is attempting to exploit the vulnerability to gain unauthorized access to the device and execute arbitrary code. If a true positive is found, it suggests that an attacker has successfully exploited the vulnerability and may have gained control over the device, leading to data theft, network compromise, or other damaging outcomes. Upon triage, review the request parameters and the response to determine if the exploitation was successful. Capture and inspect any relevant network traffic and server logs to identify the attack source. This approach helps analysts detect potential threats earlier and mitigate the risks.
how_to_implement = To implement this search, ensure that the Web data model is populated. The search is activated when the Web data model is accelerated. Network products, such as Suricata or Palo Alto, need to be mapped to the Web data model. Adjust the mapping as necessary to suit your specific products.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Command and Control", "Installation"], "mitre_attack": ["T1190", "T1105", "T1059"], "nist": ["DE.CM"]}
known_false_positives = Be aware of potential false positives - legitimate uses of the /webauth_operation.php endpoint may cause benign activities to be flagged.The URL in the analytic is specific to a successful attempt to exploit the vulnerability. Review contents of the HTTP body to determine if the request is malicious. If the request is benign, add the URL to the whitelist or continue to monitor.
providing_technologies = null

[savedsearch://ESCU - Log4Shell JNDI Payload Injection Attempt - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = CVE-2021-44228 Log4Shell payloads can be injected via various methods, but on of the most common vectors injection is via Web calls. Many of the vulnerable java web applications that are using log4j have a web component to them are specially targets of this injection, specifically projects like Apache Struts, Flink, Druid, and Solr. The exploit is triggered by a LDAP lookup function in the log4j package, its invocation is similar to `${jndi:ldap://PAYLOAD_INJECTED}`, when executed against vulnerable web applications the invocation can be seen in various part of web logs. Specifically it has been successfully exploited via headers like X-Forwarded-For, User-Agent, Referer, and X-Api-Version. In this detection we first limit the scope of our search to the Web Datamodel and use the `| from datamodel` function to benefit from schema accelerated searching capabilities, mainly because the second part of the detection is pretty heavy, it runs a regex across all _raw events that looks for `${jndi:ldap://` pattern across all potential web fields available to the raw data, like http headers for example. If you see results for this detection, it means that there was a attempt at a injection, which could be a reconnaissance activity or a valid expliotation attempt, but this does not exactly mean that the host was indeed successfully exploited.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache or Splunk for Nginx.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = If there is a vulnerablility scannner looking for log4shells this will trigger, otherwise likely to have low false positives.
providing_technologies = null

[savedsearch://ESCU - Log4Shell JNDI Payload Injection with Outbound Connection - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = CVE-2021-44228 Log4Shell payloads can be injected via various methods, but on of the most common vectors injection is via Web calls. Many of the vulnerable java web applications that are using log4j have a web component to them are specially targets of this injection, specifically projects like Apache Struts, Flink, Druid, and Solr. The exploit is triggered by a LDAP lookup function in the log4j package, its invocation is similar to `${jndi:ldap://PAYLOAD_INJECTED}`, when executed against vulnerable web applications the invocation can be seen in various part of web logs. Specifically it has been successfully exploited via headers like X-Forwarded-For, User-Agent, Referer, and X-Api-Version. In this detection we match the invocation function with a network connection to a malicious ip address.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Apache or Splunk for Nginx.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = If there is a vulnerablility scannner looking for log4shells this will trigger, otherwise likely to have low false positives.
providing_technologies = null

[savedsearch://ESCU - Microsoft SharePoint Server Elevation of Privilege - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic detects potential exploitation attempts against Microsoft SharePoint Server vulnerability CVE-2023-29357. This vulnerability pertains to an elevation of privilege due to improper handling of authentication tokens. By monitoring for suspicious activities related to SharePoint Server, the analytic identifies attempts to exploit this vulnerability. If a true positive is detected, it indicates a serious security breach where an attacker might have gained privileged access to the SharePoint environment, potentially leading to data theft or other malicious activities.
how_to_implement = This detection requires the Web datamodel to be populated from a supported Technology Add-On like Splunk for Microsoft SharePoint.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Exploitation"], "mitre_attack": ["T1068"], "nist": ["DE.CM"]}
known_false_positives = False positives may occur if there are legitimate activities that mimic the exploitation pattern. It's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
providing_technologies = null

[savedsearch://ESCU - Monitor Web Traffic For Brand Abuse - Rule]
type = detection
asset_type = Endpoint
confidence = medium
explanation = This search looks for Web requests to faux domains similar to the one that you want to have monitored for abuse.
how_to_implement = You need to ingest data from your web traffic. This can be accomplished by indexing data from a web proxy, or using a network traffic analysis tool, such as Bro or Splunk Stream. You also need to have run the search "ESCU - DNSTwist Domain Names", which creates the permutations of the domain that will be checked for.
annotations = {"cis20": ["CIS 13"], "nist": ["DE.CM"]}
known_false_positives = None at this time
providing_technologies = null

[savedsearch://ESCU - Nginx ConnectWise ScreenConnect Authentication Bypass - Rule]
type = detection
asset_type = Web
confidence = medium
explanation = This analytic detects attempts to exploit the ConnectWise ScreenConnect CVE-2024-1709 vulnerability, which allows an attacker to bypass authentication using an alternate path or channel. The vulnerability, identified as critical with a CVSS score of 10, enables unauthorized users to access the SetupWizard.aspx page on already-configured ScreenConnect instances, potentially leading to the creation of administrative users and remote code execution. The search query provided looks for web requests to the SetupWizard.aspx page that could indicate exploitation attempts. This detection is crucial for identifying and responding to active exploitation of this vulnerability in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issue, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers.
how_to_implement = To implement this analytic, ensure proper logging is occurring with Nginx, access.log and error.log, and that these logs are being ingested into Splunk. STRT utilizes this nginx.conf https://gist.github.com/MHaggis/26f59108b04da8f1d870c9cc3a3c8eec to properly log as much data with Nginx.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives are not expected, as the detection is based on the presence of web requests to the SetupWizard.aspx page, which is not a common page to be accessed by legitimate users. Note that the analytic is limited to HTTP POST and a status of 200 to reduce false positives. Modify the query as needed to reduce false positives or hunt for additional indicators of compromise.
providing_technologies = null

[savedsearch://ESCU - PaperCut NG Remote Web Access Attempt - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic is designed to detect potential exploitation attempts on publicly accessible PaperCut NG servers. It identifies connections from public IP addresses to the server and specifically monitors for URI paths commonly found in proof-of-concept (POC) scripts for exploiting PaperCut NG vulnerabilities. These URI paths have been observed in both Metasploit modules and standalone scripts used for attacking PaperCut NG servers. When a public IP address is detected accessing one or more of these suspicious URI paths, an alert may be generated to notify the security team of the potential threat. The team can then investigate the source IP address, the targeted PaperCut NG server, and any other relevant information to determine the nature of the activity and take appropriate actions to mitigate the risk.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present, filter as needed.
providing_technologies = null

[savedsearch://ESCU - ProxyShell ProxyNotShell Behavior Detected - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following correlation will identify activity related to Windows Exchange being actively exploited by adversaries related to ProxyShell or ProxyNotShell. In addition, the analytic correlates post-exploitation Cobalt Strike analytic story. Common post-exploitation behavior has been seen in the wild includes adversaries running nltest, Cobalt Strike, Mimikatz and adding a new user. The correlation specifically looks for 5 distinct analyticstories to trigger. Modify or tune as needed for your organization. 5 analytics is an arbitrary number but was chosen to reduce the amount of noise but also require the 2 analytic stories or a ProxyShell and CobaltStrike to fire. Adversaries will exploit the vulnerable Exchange server, abuse SSRF, drop a web shell, utilize the PowerShell Exchange modules and begin post-exploitation.
how_to_implement = To implement this correlation, you will need to enable ProxyShell, ProxyNotShell and Cobalt Strike analytic stories (the anaytics themselves) and ensure proper data is being collected for Web and Endpoint datamodels. Run the correlation rule seperately to validate it is not triggering too much or generating incorrectly. Validate by running ProxyShell POC code and Cobalt Strike behavior.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = False positives will be limited, however tune or modify the query as needed.
providing_technologies = null

[savedsearch://ESCU - Spring4Shell Payload URL Request - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic is static indicators related to CVE-2022-22963, Spring4Shell. The 3 indicators provide an amount of fidelity that source IP is attemping to exploit a web shell on the destination. The filename and cmd are arbitrary in this exploitation. Java will write a JSP to disk and a process will spawn from Java based on the cmd passed. This is indicative of typical web shell activity.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505.003", "T1505", "T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = The jsp file names are static names used in current proof of concept code. =
providing_technologies = null

[savedsearch://ESCU - SQL Injection with Long URLs - Rule]
type = detection
asset_type = Database Server
confidence = medium
explanation = The following analytic detects long URLs that contain multiple SQL commands. A proactive approach helps to detect and respond to potential threats earlier, mitigating the risks associated with SQL injection attacks. This detection is made by a Splunk query that searches for web traffic data where the destination category is a web server and the URL length is greater than 1024 characters or the HTTP user agent length is greater than 200 characters. This detection is important because it suggests that an attacker is attempting to exploit a web application through SQL injection. SQL injection is a common technique used by attackers to exploit vulnerabilities in web applications and gain unauthorized access to databases. Attackers can insert malicious SQL commands into a URL to manipulate the application's database and retrieve sensitive information or modify data. The impact of a successful SQL injection attack can be severe, potentially leading to data breaches, unauthorized access, and even complete compromise of the affected system. False positives might occur since the legitimate use of web applications or specific URLs in your environment can trigger the detection. Therefore, you must review and validate any alerts generated by this analytic before taking any action. Next steps include reviewing the source and destination of the web traffic, as well as the specific URL and HTTP user agent. Additionally, capture and analyze any relevant on-disk artifacts and review concurrent processes to determine the source of the attack.
how_to_implement = To successfully implement this search, you need to be monitoring network communications to your web servers or ingesting your HTTP logs and populating the Web data model. You must also identify your web servers in the Enterprise Security assets table.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = It's possible that legitimate traffic will have long URLs or long user agent strings and that common SQL commands may be found within the URL. Please investigate as appropriate.
providing_technologies = null

[savedsearch://ESCU - Supernova Webshell - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic detects the presence of the Supernova webshell, which was used in the SUNBURST attack. This webshell can be used by attackers to gain unauthorized access to a compromised system and run arbitrary code. This detection is made by a Splunk query that searches for specific patterns in web URLs, including "*logoimagehandler.ashx*codes*", "*logoimagehandler.ashx*clazz*", "*logoimagehandler.ashx*method*", and "*logoimagehandler.ashx*args*". These patterns are commonly used by the Supernova webshell to communicate with its command and control server. This detection is important because it indicates a potential compromise and unauthorized access to the system to run arbitrary code, which can lead to data theft, ransomware, or other damaging outcomes. False positives might occur since the patterns used by the webshell can also be present in legitimate web traffic. In such cases, tune the search to the specific environment and monitor it closely for any suspicious activity. Next steps include reviewing the web URLs and inspecting any relevant on-disk artifacts. Additionally, review concurrent processes and network connections to identify the source of the attack.
how_to_implement = To successfully implement this search, you need to be monitoring web traffic to your Solarwinds Orion. The logs should be ingested into splunk and populating/mapped to the Web data model.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505.003", "T1133"], "nist": ["DE.CM"]}
known_false_positives = There might be false positives associted with this detection since items like args as a web argument is pretty generic.
providing_technologies = null

[savedsearch://ESCU - VMWare Aria Operations Exploit Attempt - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic is designed to detect potential exploitation attempts against VMWare vRealize Network Insight that align with the characteristics of CVE-2023-20887. This specific vulnerability is a critical security flaw that, if exploited, could allow an attacker to execute arbitrary code on the affected system.\
The analytic operates by monitoring web traffic, specifically HTTP POST requests, directed towards a specific URL endpoint ("/saas./resttosaasservlet"). This endpoint is known to be vulnerable and is a common target for attackers exploiting this vulnerability.\
The behavior this analytic detects is the sending of HTTP POST requests to the vulnerable endpoint. This is a significant indicator of an attempted exploit as it is the primary method used to trigger the vulnerability. The analytic detects this behavior by analyzing web traffic data and identifying HTTP POST requests directed at the vulnerable endpoint.\
Identifying this behavior is crucial for a Security Operations Center (SOC) as it can indicate an active attempt to exploit a known vulnerability within the network. If the identified behavior is a true positive, it suggests an attacker is attempting to exploit the CVE-2023-20887 vulnerability in VMWare vRealize Network Insight. The impact of such an attack could be severe, potentially allowing the attacker to execute arbitrary code on the affected system, leading to unauthorized access, data theft, or further propagation within the network.
how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. Restrict to specific dest assets to reduce false positives.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation", "Exploitation"], "mitre_attack": ["T1133", "T1190", "T1210", "T1068"], "nist": ["DE.CM"]}
known_false_positives = False positives will be present based on gateways in use, modify the status field as needed.
providing_technologies = null

[savedsearch://ESCU - VMware Server Side Template Injection Hunt - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following hunting analytic identifies the server side template injection related to CVE-2022-22954, however is a variation found within the same endpoint of the URL scheme.
how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if the activity is blocked or was not successful. Filter known vulnerablity scanners. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - VMware Workspace ONE Freemarker Server-side Template Injection - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies the server side template injection related to CVE-2022-22954. Based on the scanning activity across the internet and proof of concept code available the template injection occurs at catalog-portal/ui/oauth/verify?error=&deviceudid=. Upon triage, review parallel processes and VMware logs. Following the deviceudid= may be a command to be executed. Capture any file creates and review modified files on disk.
how_to_implement = To successfully implement this search, you need to be ingesting web or proxy logs, or ensure it is being filled by a proxy like device, into the Web Datamodel. For additional filtering, allow list private IP space or restrict by known good.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.AE"]}
known_false_positives = False positives may be present if the activity is blocked or was not successful. Filter known vulnerablity scanners. Filter as needed.
providing_technologies = null

[savedsearch://ESCU - Web JSP Request via URL - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies the common URL requests used by a recent CVE - CVE-2022-22965, or Spring4Shell, to access a webshell on the remote webserver. The filename and cmd are arbitrary in this exploitation. Java will write a JSP to disk and a process will spawn from Java based on the cmd passed. This is indicative of typical web shell activity.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Installation", "Delivery"], "mitre_attack": ["T1505.003", "T1505", "T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to servers.
providing_technologies = null

[savedsearch://ESCU - Web Remote ShellServlet Access - Rule]
type = detection
asset_type = web server
confidence = medium
explanation = This analytic identifies attempts to access the Remote ShellServlet on a web server, which is utilized to execute commands. Such activity is commonly linked with web shells and other forms of malicious behavior. It was specifically detected on a Confluence server in relation to CVE-2023-22518 and CVE-2023-22515. Activities preceding access to the shell servlet include the addition of a plugin to Confluence. Additionally, it is advisable to monitor for ShellServlet?act=3, ShellServlet, or obfuscated variations such as Sh3llServlet1.
how_to_implement = This analytic necessitates the collection of web data, which can be achieved through Splunk Stream or by utilizing the Splunk Add-on for Apache Web Server. No additional configuration is required for this analytic.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may occur depending on the web server's configuration. If the web server is intentionally configured to utilize the Remote ShellServlet, then the detections by this analytic would not be considered true positives.
providing_technologies = null

[savedsearch://ESCU - Web Spring4Shell HTTP Request Class Module - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies the payload related to Spring4Shell, CVE-2022-22965. This analytic uses Splunk Stream HTTP to view the http request body, form data. STRT reviewed all the current proof of concept code and determined the commonality with the payloads being passed used the same fields "class.module.classLoader.resources.context.parent.pipeline.first".
how_to_implement = To successfully implement this search, you need to be ingesting logs with the stream HTTP logs or network logs that catch network traffic. Make sure that the http-request-body, payload, or request field is enabled.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may occur and filtering may be required. Restrict analytic to asset type.
providing_technologies = null

[savedsearch://ESCU - Web Spring Cloud Function FunctionRouter - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic identifies activity related to the web application Spring Cloud Function that was recently idenfied as vulnerable. This is CVE-2022-22963. Multiple proof of concept code was released. The URI that is hit includes `functionrouter`. The specifics of the exploit include a status of 500. In this query we did not include it, but for filtering you can add Web.status=500. The exploit data itself (based on all the POCs) is located in the form_data field. This field will include all class.modules being called.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic that include fields relavent for traffic into the `Web` datamodel.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives may be present with legitimate applications. Attempt to filter by dest IP or use Asset groups to restrict to servers.
providing_technologies = null

[savedsearch://ESCU - Windows Exchange Autodiscover SSRF Abuse - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic utilizes the Web datamodel and identifies the ProxyShell or ProxyNotShell abuse. This vulnerability is a Server Side Request Forgery (SSRF) vulnerability, which is a web vulnerability that allows an adversary to exploit vulnerable functionality to access server side or local network services by affectively traversing the external firewall using vulnerable web functionality. This analytic looks for the URI path and query of autodiscover, powershell and mapi along with a POST occurring. It will tally a simple score and show the output of the events that match. This analytic may be added to by simply creating a new eval statement and modifying the hardcode digit for Score.
how_to_implement = To successfully implement this search you need to be ingesting information on Web traffic, Exchange OR IIS logs, mapped to `Web` datamodel in the `Web` node. In addition, confirm the latest CIM App 4.20 or higher is installed.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery", "Installation"], "mitre_attack": ["T1190", "T1133"], "nist": ["DE.CM"]}
known_false_positives = False positives are limited.
providing_technologies = null

[savedsearch://ESCU - WordPress Bricks Builder plugin RCE - Rule]
type = detection
asset_type = Web
confidence = medium
explanation = The following analytic identifies potential exploitation of the WordPress Bricks Builder plugin RCE vulnerability. The search is focused on the URL path "/wp-json/bricks/v1/render_element" with a status code of 200 and a POST method. It has been addressed by the theme developers in version 1.9.6.1 released on February 13, 2024. The vulnerability is tracked as CVE-2024-25600. The POC exploit is simple enough and will spawn commands on the target server. The exploit is actively being used in the wild.
how_to_implement = The search is based on data in the Web datamodel and was modeled from NGINX logs. Ensure that the Web datamodel is accelerated and that the data source for the Web datamodel is properly configured. If using other web sources, modify they query, or review the data, as needed.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = False positives may be possible, however we restricted it to HTTP Status 200 and POST requests, based on the POC. Upon investigation review the POST body for the actual payload - or command - being executed.
providing_technologies = null

[savedsearch://ESCU - WS FTP Remote Code Execution - Rule]
type = detection
asset_type = Web server
confidence = medium
explanation = The following analytic is designed to detect a Remote Code Execution (RCE) vulnerability (CVE-2023-40044) in WS_FTP, a managed file transfer software by Progress. The search specifically looks for HTTP requests to the "/AHT/AhtApiService.asmx/AuthUser" URL with a status of 200, which could indicate an exploitation attempt.
how_to_implement = The following analytic requires the Web datamodel. Ensure data source is mapped correctly or modify and tune for your data source.
annotations = {"cis20": ["CIS 13"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1190"], "nist": ["DE.CM"]}
known_false_positives = If WS_FTP Server is not in use, this analytic will not return results. Monitor and tune for your environment. Note the MetaSploit module is focused on only hitting /AHT/ and not the full /AHT/AhtApiService.asmx/AuthUser URL.
providing_technologies = null

[savedsearch://ESCU - Zscaler Adware Activities Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The following analytic is designed to detect potential adware activity which is blocked by Zscaler. Utilizing Splunk search functionality, it filters web proxy logs for blocked actions associated with adware threats. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible adware intrusions.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Behavior Analysis Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is built to identify threats blocked by the Zscaler proxy based on behavior analysis. It filters web proxy logs for entries where actions are blocked and threat names and classes are specified. The search further refines the results to include only those with reasons related to "block". It then aggregates the count, providing a clear view of the threat landscape as handled by the behavior analysis proxy.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscalar configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler CryptoMiner Downloaded Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is crafted to detect potential download of cryptomining software within a network that is blocked by Zscaler. Utilizing Splunk search functionality, it sifts through web proxy logs for blocked actions associated with cryptominer threats. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible cryptominer downloads. This detection, categorized as an anomaly, aids in early identification and mitigation of cryptomining activities, ensuring network integrity and resource availability.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Employment Search Web Activity - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is designed to identify destinations within a network deemed as potential Empolyment Searches. Utilizing Splunk's search functionality, it processes web proxy logs, focusing on entries marked as 'Job/Employment Search'. Key data points such as device owner, user, URL category, destination URL and IP, and action taken are analyzed to enumerate the employment risk destinations. This anomaly-type detection aids in monitoring and managing risks, promoting a secure environment from insider threats.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Exploit Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is aimed at detecting potential exploit attempts that involve command and script interpreters blocked by Zscaler. By querying web proxy logs, it isolates incidents where actions have been either blocked with references to exploits. The search compiles statistics by user, threat name, URL, hostname, file class, and filename, giving a detailed view of any exploit-related activity. Marked as a tactic, technique, and procedure (TTP), this analytic is essential for identifying and mitigating exploit attempts.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.CM"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Legal Liability Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is aimed at identifying the most significant legal liability threats blocked by zcaler web proxy. It leverages web proxy logs to list the  destinations, device owners, users, URL categories, and actions that are associated with Legal Liability, by utilizing stats on unique fields, it ensures a precise focus on unique legal liability threats, thereby providing valuable insights for organizations to enforce legal compliance and risk management.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Malware Activity Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic targets the detection of potential malware activities within a network that are blocked by Zscaler. By filtering web proxy logs for blocked actions associated with malware, where a threat category is specified, the analytic aggregates occurrences by user, URL, and threat category. This approach ensures a focused identification of malware activities, making it an effective tool for ongoing network security monitoring and anomaly detection.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscalar configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Phishing Activity Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is devised to detect likely phishing attempts within a network blocked by Zscaler. By leveraging Splunk search functionality, it evaluates web proxy logs for blocked actions correlated with phishing threats, specifically those tagged as HTML.Phish. Critical data points such as the user, threat name, URL, and hostname are analyzed to accentuate possible phishing activities. This anomaly-type detection serves as an early warning system, facilitating prompt investigation and mitigation of phishing threats, thereby bolstering network security.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscalar configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Potentially Abused File Download - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is engineered to detect potential rarely abused malicious filetypes downloaded within a network. They are usually used to spread malwares. Utilizing Splunk search functionality, it examines web proxy logs for blocked actions related to potential threats. Essential data points like the deviceowner, user, urlcategory, url, dest, and filename taken are analyzed to highlight possible malicious endeavors. This detection, marked as an anomaly, aids in early identification and mitigation of malicious download activities, ensuring a safer network environment.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Privacy Risk Destinations Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is designed to identify blocked destinations within a network deemed as privacy risks by Zscaler. Utilizing Splunk search functionality, it processes web proxy logs, focusing on entries marked as Privacy Risk. Key data points such as device owner, user, URL category, destination URL and IP, and action taken are analyzed to enumerate the privacy risk destinations. This anomaly-type detection aids in monitoring and managing privacy risks, promoting a secure network environment.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Scam Destinations Threat Blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is engineered to detect potential scam activities within a network by Zscaler. Utilizing Splunk search functionality, it examines web proxy logs for blocked actions related to scam threats. Essential data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to highlight possible scam endeavors. This detection, marked as an anomaly, aids in early identification and mitigation of scam activities, ensuring a safer network environment.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

[savedsearch://ESCU - Zscaler Virus Download threat blocked - Rule]
type = detection
asset_type = Web Server
confidence = medium
explanation = The analytic is formulated to detect blocked virus download activities within a network by Zscaler. Employing Splunk's search functionality, it reviews web proxy logs for blocked actions indicative of virus threats downloads. Key data points like the device owner, user, URL category, destination URL and IP, and action taken are analyzed to pinpoint possible virus downloads. As an anomaly-type detection, this analytic facilitates early detection and remediation of virus download attempts, contributing to enhanced network security.
how_to_implement = You must install the latest version of Zscaler Add-on from Splunkbase. You must be ingesting Zscaler events into your Splunk environment through an ingester. This analytic was written to be used with the "zscalernss-web" sourcetype leveraging the Zscaler proxy data. This enables the integration with Splunk Enterprise Security. Security teams are encouraged to adjust the detection parameters, ensuring the detection is tailored to their specific environment.
annotations = {"cis20": ["CIS 10"], "kill_chain_phases": ["Delivery"], "mitre_attack": ["T1566"], "nist": ["DE.AE"]}
known_false_positives = False positives are limited to Zscaler configuration.
providing_technologies = null

### END DETECTIONS ###

### STORIES ###

[analytic_story://3CX Supply Chain Attack]
category = Adversary Tactics
last_updated = 2023-03-30
version = 1
references = ["https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/", "https://www.cisa.gov/news-events/alerts/2023/03/30/supply-chain-attack-against-3cxdesktopapp", "https://www.reddit.com/r/crowdstrike/comments/125r3uu/20230329_situational_awareness_crowdstrike/", "https://www.3cx.com/community/threads/crowdstrike-endpoint-security-detection-re-3cx-desktop-app.119934/page-2#post-558898", "https://www.3cx.com/community/threads/3cx-desktopapp-security-alert.119951/", "https://www.elastic.co/security-labs/elastic-users-protected-from-suddenicon-supply-chain-attack", "https://www.volexity.com/blog/2023/03/30/3cx-supply-chain-compromise-leads-to-iconic-incident/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - 3CX Supply Chain Attack Network Indicators - Rule", "ESCU - Hunting 3CXDesktopApp Software - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Windows Vulnerable 3CX Software - Rule"]
description = On March 29, 2023, CrowdStrike Falcon OverWatch observed unexpected malicious activity emanating from a legitimate, signed binary, 3CXDesktopApp,  a softphone application from 3CX. The malicious activity includes beaconing to actor controlled infrastructure, deployment of second stage payloads, and, in a small number of cases, hands on keyboard activity. (CrowdStrike)
narrative = On March 22, 2023, cybersecurity firm SentinelOne observed a surge in behavioral detections of trojanized 3CXDesktopApp installers, a popular PABX voice and video conferencing software. The multi-stage attack chain, which automatically quarantines trojanized installers, involves downloading ICO files with base64 data from GitHub and eventually leads to a 3rd stage infostealer DLL that is still under analysis. While the Mac installer remains unconfirmed as trojanized, ongoing investigations are also examining other potentially compromised applications, such as Chrome extensions. The threat actor behind the supply chain compromise, which started in February 2022, has used a code signing certificate to sign the trojanized binaries, but connections to existing threat clusters remain unclear. SentinelOne updated their IOCs on March 30th, 2023, with contributions from the research community and continues to monitor the situation for further developments. 3CX identified the vulnerability in the recent versions 18.12.407 and 18.12.416 for the desktop app. A new certificate for the app will also be produced.

[analytic_story://IcedID]
category = Malware
last_updated = 2021-07-29
version = 1
references = ["https://threatpost.com/icedid-banking-trojan-surges-emotet/165314/", "https://app.any.run/tasks/48414a33-3d66-4a46-afe5-c2003bb55ccf/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Account Discovery With Net App - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - CHCP Command Execution - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Create Remote Thread In Shell Application - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Disable Defender AntiVirus Registry - Rule", "ESCU - Disable Defender BlockAtFirstSeen Feature - Rule", "ESCU - Disable Defender Enhanced Notification - Rule", "ESCU - Disable Defender MpEngine Registry - Rule", "ESCU - Disable Defender Spynet Reporting - Rule", "ESCU - Disable Defender Submit Samples Consent Feature - Rule", "ESCU - Disable Schedule Task - Rule", "ESCU - Disabling Defender Services - Rule", "ESCU - Drop IcedID License dat - Rule", "ESCU - Eventvwr UAC Bypass - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - FodHelper UAC Bypass - Rule", "ESCU - IcedID Exfiltrated Archived File Creation - Rule", "ESCU - Mshta spawning Rundll32 OR Regsvr32 Process - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Connection Discovery With Arp - Rule", "ESCU - Network Share Discovery Via Dir Command - Rule", "ESCU - NLTest Domain Trust Discovery - Rule", "ESCU - Office Application Spawn Regsvr32 process - Rule", "ESCU - Office Application Spawn rundll32 process - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawning MSHTA - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - Powershell Processing Stream Of Data - Rule", "ESCU - Powershell Using memory As Backing Store - Rule", "ESCU - Process Creating LNK file in Suspicious Location - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule", "ESCU - Remote System Discovery with Net - Rule", "ESCU - Remote WMI Command Attempt - Rule", "ESCU - Rundll32 Create Remote Thread To A Process - Rule", "ESCU - Rundll32 CreateRemoteThread In Browser - Rule", "ESCU - Rundll32 DNSQuery - Rule", "ESCU - Rundll32 Process Creating Exe Dll Files - Rule", "ESCU - RunDLL Loading DLL By Ordinal - Rule", "ESCU - Schedule Task with Rundll32 Command Trigger - Rule", "ESCU - Sqlite Module In Temp Folder - Rule", "ESCU - Suspicious Copy on System32 - Rule", "ESCU - Suspicious IcedID Rundll32 Cmdline - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Regsvr32 Register Suspicious Path - Rule", "ESCU - Suspicious Rundll32 dllregisterserver - Rule", "ESCU - Suspicious Rundll32 PluginInit - Rule", "ESCU - Windows AdFind Exe - Rule", "ESCU - Windows Curl Download to Suspicious Path - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule", "ESCU - Windows WMI Process Call Create - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule", "ESCU - Wmic NonInteractive App Uninstallation - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the IcedID banking trojan, including looking for file writes associated with its payload, process injection, shellcode execution and data collection.
narrative = IcedId banking trojan campaigns targeting banks and other vertical sectors.This malware is known in Microsoft Windows OS targetting browser such as firefox and chrom to steal banking information. It is also known to its unique payload downloaded in C2 where it can be a .png file that hides the core shellcode bot using steganography technique or gzip dat file that contains "license.dat" which is the actual core icedid bot.

[analytic_story://Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring]
category = Cloud Security
last_updated = 2024-01-08
version = 1
references = ["https://kubernetes.io/docs/concepts/security/", "https://splunkbase.splunk.com/app/5247"]
maintainers = [{"company": "Patrick Bareiss, Splunk", "email": "-", "name": "Matthew Moore"}]
spec_version = 3
searches = ["ESCU - Kubernetes Anomalous Inbound Network Activity from Process - Rule", "ESCU - Kubernetes Anomalous Inbound Outbound Network IO - Rule", "ESCU - Kubernetes Anomalous Inbound to Outbound Network IO Ratio - Rule", "ESCU - Kubernetes Anomalous Outbound Network Activity from Process - Rule", "ESCU - Kubernetes Anomalous Traffic on Network Edge - Rule", "ESCU - Kubernetes newly seen TCP edge - Rule", "ESCU - Kubernetes newly seen UDP edge - Rule", "ESCU - Kubernetes Previously Unseen Container Image Name - Rule", "ESCU - Kubernetes Previously Unseen Process - Rule", "ESCU - Kubernetes Process Running From New Path - Rule", "ESCU - Kubernetes Process with Anomalous Resource Utilisation - Rule", "ESCU - Kubernetes Process with Resource Ratio Anomalies - Rule", "ESCU - Kubernetes Shell Running on Worker Node - Rule", "ESCU - Kubernetes Shell Running on Worker Node with CPU Activity - Rule"]
description = Kubernetes, a complex container orchestration system, is susceptible to a variety of security threats. This story delves into the different strategies and methods adversaries employ to exploit Kubernetes environments. These include attacks on the control plane, exploitation of misconfigurations, and breaches of containerized applications. Observability data, such as metrics, play a crucial role in identifying abnormal and potentially malicious behavior within these environments.
narrative = Kubernetes, a complex container orchestration system, is a prime target for adversaries due to its widespread use and inherent complexity. This story focuses on the abnormal behavior within Kubernetes environments that can be indicative of security threats. Key areas of concern include the control plane, worker nodes, and network communication, all of which can be exploited by attackers. Observability data, such as metrics, play a crucial role in identifying these abnormal behaviors. These behaviors could be a result of attacks on the control plane, exploitation of misconfigurations, or breaches of containerized applications. For instance, attackers may attempt to exploit vulnerabilities in the Kubernetes API, misconfigured containers, or insecure network policies. The control plane, which manages cluster operations, is a prime target and its compromise can give attackers control over the entire cluster. Worker nodes, which run the containerized applications, can also be targeted to disrupt services or to gain access to sensitive data.

[analytic_story://AcidRain]
category = Malware
last_updated = 2022-04-12
version = 1
references = ["https://www.sentinelone.com/labs/acidrain-a-modem-wiper-rains-down-on-europe/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Linux Account Manipulation Of SSH Config and Keys - Rule", "ESCU - Linux Deletion Of Cron Jobs - Rule", "ESCU - Linux Deletion Of Init Daemon Script - Rule", "ESCU - Linux Deletion Of Services - Rule", "ESCU - Linux Deletion of SSL Certificate - Rule", "ESCU - Linux High Frequency Of File Deletion In Etc Folder - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the acidrain malware including deleting of files and etc. AcidRain is an ELF MIPS malware specifically designed to wipe modems and routers. The complete list of targeted devices is unknown at this time, but WatchGuard FireBox has specifically been listed as a target. This malware is capable of wiping and deleting non-standard linux files and overwriting storage device files that might related to router, ssd card and many more.
narrative = Adversaries may use this technique to maximize the impact on the target organization in operations where network wide availability interruption is the goal.

[analytic_story://Active Directory Discovery]
category = Adversary Tactics
last_updated = 2021-08-20
version = 1
references = ["https://attack.mitre.org/tactics/TA0007/", "https://adsecurity.org/?p=2535", "https://attack.mitre.org/techniques/T1087/001/", "https://attack.mitre.org/techniques/T1087/002/", "https://attack.mitre.org/techniques/T1087/003/", "https://attack.mitre.org/techniques/T1482/", "https://attack.mitre.org/techniques/T1201/", "https://attack.mitre.org/techniques/T1069/001/", "https://attack.mitre.org/techniques/T1069/002/", "https://attack.mitre.org/techniques/T1018/", "https://attack.mitre.org/techniques/T1049/", "https://attack.mitre.org/techniques/T1033/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - AdsiSearcher Account Discovery - Rule", "ESCU - Domain Account Discovery with Dsquery - Rule", "ESCU - Domain Account Discovery With Net App - Rule", "ESCU - Domain Account Discovery with Wmic - Rule", "ESCU - Domain Controller Discovery with Nltest - Rule", "ESCU - Domain Controller Discovery with Wmic - Rule", "ESCU - Domain Group Discovery with Adsisearcher - Rule", "ESCU - Domain Group Discovery With Dsquery - Rule", "ESCU - Domain Group Discovery With Net - Rule", "ESCU - Domain Group Discovery With Wmic - Rule", "ESCU - DSQuery Domain Discovery - Rule", "ESCU - Elevated Group Discovery With Net - Rule", "ESCU - Elevated Group Discovery with PowerView - Rule", "ESCU - Elevated Group Discovery With Wmic - Rule", "ESCU - Get ADDefaultDomainPasswordPolicy with Powershell - Rule", "ESCU - Get ADDefaultDomainPasswordPolicy with Powershell Script Block - Rule", "ESCU - Get ADUser with PowerShell - Rule", "ESCU - Get ADUser with PowerShell Script Block - Rule", "ESCU - Get ADUserResultantPasswordPolicy with Powershell - Rule", "ESCU - Get ADUserResultantPasswordPolicy with Powershell Script Block - Rule", "ESCU - Get DomainPolicy with Powershell - Rule", "ESCU - Get DomainPolicy with Powershell Script Block - Rule", "ESCU - Get-DomainTrust with PowerShell - Rule", "ESCU - Get-DomainTrust with PowerShell Script Block - Rule", "ESCU - Get DomainUser with PowerShell - Rule", "ESCU - Get DomainUser with PowerShell Script Block - Rule", "ESCU - Get-ForestTrust with PowerShell - Rule", "ESCU - Get-ForestTrust with PowerShell Script Block - Rule", "ESCU - Get WMIObject Group Discovery - Rule", "ESCU - Get WMIObject Group Discovery with Script Block Logging - Rule", "ESCU - GetAdComputer with PowerShell - Rule", "ESCU - GetAdComputer with PowerShell Script Block - Rule", "ESCU - GetAdGroup with PowerShell - Rule", "ESCU - GetAdGroup with PowerShell Script Block - Rule", "ESCU - GetCurrent User with PowerShell - Rule", "ESCU - GetCurrent User with PowerShell Script Block - Rule", "ESCU - GetDomainComputer with PowerShell - Rule", "ESCU - GetDomainComputer with PowerShell Script Block - Rule", "ESCU - GetDomainController with PowerShell - Rule", "ESCU - GetDomainController with PowerShell Script Block - Rule", "ESCU - GetDomainGroup with PowerShell - Rule", "ESCU - GetDomainGroup with PowerShell Script Block - Rule", "ESCU - GetLocalUser with PowerShell - Rule", "ESCU - GetLocalUser with PowerShell Script Block - Rule", "ESCU - GetNetTcpconnection with PowerShell - Rule", "ESCU - GetNetTcpconnection with PowerShell Script Block - Rule", "ESCU - GetWmiObject Ds Computer with PowerShell - Rule", "ESCU - GetWmiObject Ds Computer with PowerShell Script Block - Rule", "ESCU - GetWmiObject Ds Group with PowerShell - Rule", "ESCU - GetWmiObject Ds Group with PowerShell Script Block - Rule", "ESCU - GetWmiObject DS User with PowerShell - Rule", "ESCU - GetWmiObject DS User with PowerShell Script Block - Rule", "ESCU - GetWmiObject User Account with PowerShell - Rule", "ESCU - GetWmiObject User Account with PowerShell Script Block - Rule", "ESCU - Local Account Discovery with Net - Rule", "ESCU - Local Account Discovery With Wmic - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Connection Discovery With Arp - Rule", "ESCU - Network Connection Discovery With Net - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Network Discovery Using Route Windows App - Rule", "ESCU - NLTest Domain Trust Discovery - Rule", "ESCU - Password Policy Discovery with Net - Rule", "ESCU - PowerShell Get LocalGroup Discovery - Rule", "ESCU - Powershell Get LocalGroup Discovery with Script Block Logging - Rule", "ESCU - Remote System Discovery with Adsisearcher - Rule", "ESCU - Remote System Discovery with Dsquery - Rule", "ESCU - Remote System Discovery with Net - Rule", "ESCU - Remote System Discovery with Wmic - Rule", "ESCU - ServicePrincipalNames Discovery with PowerShell - Rule", "ESCU - ServicePrincipalNames Discovery with SetSPN - Rule", "ESCU - System User Discovery With Query - Rule", "ESCU - System User Discovery With Whoami - Rule", "ESCU - User Discovery With Env Vars PowerShell - Rule", "ESCU - User Discovery With Env Vars PowerShell Script Block - Rule", "ESCU - Windows AD Abnormal Object Access Activity - Rule", "ESCU - Windows AD Privileged Object Access Activity - Rule", "ESCU - Windows File Share Discovery With Powerview - Rule", "ESCU - Windows Find Domain Organizational Units with GetDomainOU - Rule", "ESCU - Windows Find Interesting ACL with FindInterestingDomainAcl - Rule", "ESCU - Windows Forest Discovery with GetForestDomain - Rule", "ESCU - Windows Get Local Admin with FindLocalAdminAccess - Rule", "ESCU - Windows Hidden Schedule Task Settings - Rule", "ESCU - Windows Lateral Tool Transfer RemCom - Rule", "ESCU - Windows Linked Policies In ADSI Discovery - Rule", "ESCU - Windows PowerView AD Access Control List Enumeration - Rule", "ESCU - Windows Root Domain linked policies Discovery - Rule", "ESCU - Windows Service Create RemComSvc - Rule", "ESCU - Windows Suspect Process With Authentication Traffic - Rule", "ESCU - Wmic Group Discovery - Rule"]
description = Monitor for activities and techniques associated with Discovery and Reconnaissance within with Active Directory environments.
narrative = Discovery consists of techniques an adversay uses to gain knowledge about an internal environment or network. These techniques provide adversaries with situational awareness and allows them to have the necessary information before deciding how to act or who/what to target next.\
Once an attacker obtains an initial foothold in an Active Directory environment, she is forced to engage in Discovery techniques in the initial phases of a breach to better understand and navigate the target network. Some examples include but are not limited to enumerating domain users, domain admins, computers, domain controllers, network shares, group policy objects, domain trusts, etc.

[analytic_story://Active Directory Kerberos Attacks]
category = Adversary Tactics
last_updated = 2022-02-02
version = 1
references = ["https://en.wikipedia.org/wiki/Kerberos_(protocol)", "https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/2a32282e-dd48-4ad9-a542-609804b02cc9", "https://m0chan.github.io/2019/07/31/How-To-Attack-Kerberos-101.html", "https://stealthbits.com/blog/cracking-active-directory-passwords-with-as-rep-roasting/", "https://attack.mitre.org/techniques/T1558/003/", "https://attack.mitre.org/techniques/T1550/003/", "https://attack.mitre.org/techniques/T1558/004/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Disabled Kerberos Pre-Authentication Discovery With Get-ADUser - Rule", "ESCU - Disabled Kerberos Pre-Authentication Discovery With PowerView - Rule", "ESCU - Kerberoasting spn request with RC4 encryption - Rule", "ESCU - Kerberos Pre-Authentication Flag Disabled in UserAccountControl - Rule", "ESCU - Kerberos Pre-Authentication Flag Disabled with PowerShell - Rule", "ESCU - Kerberos Service Ticket Request Using RC4 Encryption - Rule", "ESCU - Kerberos TGT Request Using RC4 Encryption - Rule", "ESCU - Kerberos User Enumeration - Rule", "ESCU - Mimikatz PassTheTicket CommandLine Parameters - Rule", "ESCU - PetitPotam Suspicious Kerberos TGT Request - Rule", "ESCU - Rubeus Command Line Parameters - Rule", "ESCU - Rubeus Kerberos Ticket Exports Through Winlogon Access - Rule", "ESCU - ServicePrincipalNames Discovery with PowerShell - Rule", "ESCU - ServicePrincipalNames Discovery with SetSPN - Rule", "ESCU - Suspicious Kerberos Service Ticket Request - Rule", "ESCU - Suspicious Ticket Granting Ticket Request - Rule", "ESCU - Unknown Process Using The Kerberos Protocol - Rule", "ESCU - Unusual Number of Computer Service Tickets Requested - Rule", "ESCU - Unusual Number of Kerberos Service Tickets Requested - Rule", "ESCU - Windows Computer Account Created by Computer Account - Rule", "ESCU - Windows Computer Account Requesting Kerberos Ticket - Rule", "ESCU - Windows Computer Account With SPN - Rule", "ESCU - Windows Domain Admin Impersonation Indicator - Rule", "ESCU - Windows Get-AdComputer Unconstrained Delegation Discovery - Rule", "ESCU - Windows Kerberos Local Successful Logon - Rule", "ESCU - Windows Multiple Disabled Users Failed To Authenticate Wth Kerberos - Rule", "ESCU - Windows Multiple Invalid Users Fail To Authenticate Using Kerberos - Rule", "ESCU - Windows Multiple Users Failed To Authenticate Using Kerberos - Rule", "ESCU - Windows PowerView Constrained Delegation Discovery - Rule", "ESCU - Windows PowerView Kerberos Service Ticket Request - Rule", "ESCU - Windows PowerView SPN Discovery - Rule", "ESCU - Windows PowerView Unconstrained Delegation Discovery - Rule", "ESCU - Windows Unusual Count Of Disabled Users Failed Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Invalid Users Fail To Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Users Failed To Auth Using Kerberos - Rule"]
description = Monitor for activities and techniques associated with Kerberos based attacks within with Active Directory environments.
narrative = Kerberos, initially named after Cerberus, the three-headed dog in Greek mythology, is a network authentication protocol that allows computers and users to prove their identity through a trusted third-party. This trusted third-party issues Kerberos tickets using symmetric encryption to allow users access to services and network resources based on their privilege level. Kerberos is the default authentication protocol used on Windows Active Directory networks since the introduction of Windows Server 2003. With Kerberos being the backbone of Windows authentication, it is commonly abused by adversaries across the different phases of a breach including initial access, privilege escalation, defense evasion, credential access, lateral movement, etc.\ This Analytic Story groups detection use cases in which the Kerberos protocol is abused. Defenders can leverage these analytics to detect and hunt for adversaries engaging in Kerberos based attacks.

[analytic_story://Active Directory Lateral Movement]
category = Adversary Tactics
last_updated = 2021-12-09
version = 3
references = ["https://www.fireeye.com/blog/executive-perspective/2015/08/malware_lateral_move.html", "http://www.irongeek.com/i.php?page=videos/derbycon7/t405-hunting-lateral-movement-for-fun-and-profit-mauricio-velazco"]
maintainers = [{"company": "Mauricio Velazco Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Detect Activity Related to Pass the Hash Attacks - Rule", "ESCU - Active Directory Lateral Movement Identified - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Interactive Session on Remote Endpoint with PowerShell - Rule", "ESCU - Mmc LOLBAS Execution Process Spawn - Rule", "ESCU - Possible Lateral Movement PowerShell Spawn - Rule", "ESCU - PowerShell Invoke CIMMethod CIMSession - Rule", "ESCU - PowerShell Start or Stop Service - Rule", "ESCU - Randomly Generated Scheduled Task Name - Rule", "ESCU - Randomly Generated Windows Service Name - Rule", "ESCU - Remote Desktop Process Running On System - Rule", "ESCU - Remote Process Instantiation via DCOM and PowerShell - Rule", "ESCU - Remote Process Instantiation via DCOM and PowerShell Script Block - Rule", "ESCU - Remote Process Instantiation via WinRM and PowerShell - Rule", "ESCU - Remote Process Instantiation via WinRM and PowerShell Script Block - Rule", "ESCU - Remote Process Instantiation via WinRM and Winrs - Rule", "ESCU - Remote Process Instantiation via WMI - Rule", "ESCU - Remote Process Instantiation via WMI and PowerShell - Rule", "ESCU - Remote Process Instantiation via WMI and PowerShell Script Block - Rule", "ESCU - Scheduled Task Creation on Remote Endpoint using At - Rule", "ESCU - Scheduled Task Initiation on Remote Endpoint - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Services LOLBAS Execution Process Spawn - Rule", "ESCU - Short Lived Scheduled Task - Rule", "ESCU - Short Lived Windows Accounts - Rule", "ESCU - Svchost LOLBAS Execution Process Spawn - Rule", "ESCU - Unusual Number of Computer Service Tickets Requested - Rule", "ESCU - Unusual Number of Remote Endpoint Authentication Events - Rule", "ESCU - Windows Administrative Shares Accessed On Multiple Hosts - Rule", "ESCU - Windows Enable Win32 ScheduledJob via Registry - Rule", "ESCU - Windows Large Number of Computer Service Tickets Requested - Rule", "ESCU - Windows Local Administrator Credential Stuffing - Rule", "ESCU - Windows PowerShell Get CIMInstance Remote Computer - Rule", "ESCU - Windows PowerShell WMI Win32 ScheduledJob - Rule", "ESCU - Windows Rapid Authentication On Multiple Hosts - Rule", "ESCU - Windows RDP Connection Successful - Rule", "ESCU - Windows Remote Create Service - Rule", "ESCU - Windows Service Create with Tscon - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Created Within Public Path - Rule", "ESCU - Windows Service Creation on Remote Endpoint - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Windows Service Initiation on Remote Endpoint - Rule", "ESCU - Windows Special Privileged Logon On Multiple Hosts - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - Wmiprsve LOLBAS Execution Process Spawn - Rule", "ESCU - Wsmprovhost LOLBAS Execution Process Spawn - Rule", "ESCU - Remote Desktop Network Traffic - Rule", "ESCU - Investigate Successful Remote Desktop Authentications - Response Task"]
description = Detect and investigate tactics, techniques, and procedures around how attackers move laterally within an Active Directory environment. Since lateral movement is often a necessary step in a breach, it is important for cyber defenders to deploy detection coverage.
narrative = Once attackers gain a foothold within an enterprise, they will seek to expand their accesses and leverage techniques that facilitate lateral movement. Attackers will often spend quite a bit of time and effort moving laterally. Because lateral movement renders an attacker the most vulnerable to detection, it's an excellent focus for detection and investigation.\
Indications of lateral movement in an Active Directory network can include the abuse of system utilities (such as `psexec.exe`), unauthorized use of remote desktop services, `file/admin$` shares, WMI, PowerShell, Service Control Manager, the DCOM protocol, WinRM or the abuse of scheduled tasks. Organizations must be extra vigilant in detecting lateral movement techniques and look for suspicious activity in and around high-value strategic network assets, such as Active Directory, which are often considered the primary target or "crown jewels" to a persistent threat actor.\
An adversary can use lateral movement for multiple purposes, including remote execution of tools, pivoting to additional systems, obtaining access to specific information or files, access to additional credentials, exfiltrating data, or delivering a secondary effect. Adversaries may use legitimate credentials alongside inherent network and operating-system functionality to remotely connect to other systems and remain under the radar of network defenders.\
If there is evidence of lateral movement, it is imperative for analysts to collect evidence of the associated offending hosts. For example, an attacker might leverage host A to gain access to host B. From there, the attacker may try to move laterally to host C. In this example, the analyst should gather as much information as possible from all three hosts. \
 It is also important to collect authentication logs for each host, to ensure that the offending accounts are well-documented. Analysts should account for all processes to ensure that the attackers did not install unauthorized software.

[analytic_story://Active Directory Password Spraying]
category = Adversary Tactics
last_updated = 2021-04-07
version = 2
references = ["https://attack.mitre.org/techniques/T1110/003/", "https://www.microsoft.com/security/blog/2020/04/23/protecting-organization-password-spray-attacks/", "https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn452415(v=ws.11)"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Detect Excessive Account Lockouts From Endpoint - Rule", "ESCU - Detect Excessive User Account Lockouts - Rule", "ESCU - Windows Create Local Account - Rule", "ESCU - Windows Multiple Disabled Users Failed To Authenticate Wth Kerberos - Rule", "ESCU - Windows Multiple Invalid Users Fail To Authenticate Using Kerberos - Rule", "ESCU - Windows Multiple Invalid Users Failed To Authenticate Using NTLM - Rule", "ESCU - Windows Multiple Users Fail To Authenticate Wth ExplicitCredentials - Rule", "ESCU - Windows Multiple Users Failed To Authenticate From Host Using NTLM - Rule", "ESCU - Windows Multiple Users Failed To Authenticate From Process - Rule", "ESCU - Windows Multiple Users Failed To Authenticate Using Kerberos - Rule", "ESCU - Windows Multiple Users Remotely Failed To Authenticate From Host - Rule", "ESCU - Windows Unusual Count Of Disabled Users Failed Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Invalid Users Fail To Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Invalid Users Failed To Auth Using NTLM - Rule", "ESCU - Windows Unusual Count Of Users Fail To Auth Wth ExplicitCredentials - Rule", "ESCU - Windows Unusual Count Of Users Failed To Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Users Failed To Authenticate From Process - Rule", "ESCU - Windows Unusual Count Of Users Failed To Authenticate Using NTLM - Rule", "ESCU - Windows Unusual Count Of Users Remotely Failed To Auth From Host - Rule"]
description = Monitor for activities and techniques associated with Password Spraying attacks within Active Directory environments.
narrative = In a password spraying attack, adversaries leverage one or a small list of commonly used / popular passwords against a large volume of usernames to acquire valid account credentials. Unlike a Brute Force attack that targets a specific user or small group of users with a large number of passwords, password spraying follows the opposite aproach and increases the chances of obtaining valid credentials while avoiding account lockouts. This allows adversaries to remain undetected if the target organization does not have the proper monitoring and detection controls in place.\
Password Spraying can be leveraged by adversaries across different stages in an attack. It can be used to obtain an iniial access to an environment but can also be used to escalate privileges when access has been already achieved. In some scenarios, this technique capitalizes on a security policy most organizations implement, password rotation. As enterprise users change their passwords, it is possible some pick predictable, seasonal passwords such as `$CompanyNameWinter`, `Summer2021`, etc.\
Specifically, this Analytic Story is focused on detecting possible Password Spraying attacks against Active Directory environments leveraging Windows Event Logs in the `Account Logon` and `Logon/Logoff` Advanced Audit Policy categories. It presents 16 detection analytics which can aid defenders in identifying instances where one source user, source host or source process attempts to authenticate against a target or targets using a high or statiscally unsual, number of unique users. A user, host or process attempting to authenticate with multiple users is not common behavior for legitimate systems and should be monitored by security teams. Possible false positive scenarios include but are not limited to vulnerability scanners, remote administration tools, multi-user systems and missconfigured systems. These should be easily spotted when first implementing the detection and addded to an allow list or lookup table. The presented detections can also be used in Threat Hunting exercises.

[analytic_story://Active Directory Privilege Escalation]
category = Adversary Tactics
last_updated = 2023-03-20
version = 1
references = ["https://attack.mitre.org/tactics/TA0004/", "https://adsecurity.org/?p=3658", "https://adsecurity.org/?p=2362"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Active Directory Privilege Escalation Identified - Rule", "ESCU - Kerberos Service Ticket Request Using RC4 Encryption - Rule", "ESCU - Rubeus Command Line Parameters - Rule", "ESCU - ServicePrincipalNames Discovery with PowerShell - Rule", "ESCU - ServicePrincipalNames Discovery with SetSPN - Rule", "ESCU - Suspicious Computer Account Name Change - Rule", "ESCU - Suspicious Kerberos Service Ticket Request - Rule", "ESCU - Suspicious Ticket Granting Ticket Request - Rule", "ESCU - Unusual Number of Computer Service Tickets Requested - Rule", "ESCU - Unusual Number of Remote Endpoint Authentication Events - Rule", "ESCU - Windows Administrative Shares Accessed On Multiple Hosts - Rule", "ESCU - Windows Admon Default Group Policy Object Modified - Rule", "ESCU - Windows Admon Group Policy Object Created - Rule", "ESCU - Windows Default Group Policy Object Modified - Rule", "ESCU - Windows Default Group Policy Object Modified with GPME - Rule", "ESCU - Windows DnsAdmins New Member Added - Rule", "ESCU - Windows Domain Admin Impersonation Indicator - Rule", "ESCU - Windows File Share Discovery With Powerview - Rule", "ESCU - Windows Findstr GPP Discovery - Rule", "ESCU - Windows Group Policy Object Created - Rule", "ESCU - Windows Large Number of Computer Service Tickets Requested - Rule", "ESCU - Windows Local Administrator Credential Stuffing - Rule", "ESCU - Windows PowerSploit GPP Discovery - Rule", "ESCU - Windows PowerView AD Access Control List Enumeration - Rule", "ESCU - Windows Rapid Authentication On Multiple Hosts - Rule", "ESCU - Windows Special Privileged Logon On Multiple Hosts - Rule"]
description = Monitor for activities and techniques associated with Privilege Escalation attacks within Active Directory environments.
narrative = Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives. Common approaches are to take advantage of system weaknesses, misconfigurations, and vulnerabilities.\
Active Directory is a central component of most enterprise networks, providing authentication and authorization services for users, computers, and other resources. It stores sensitive information such as passwords, user accounts, and security policies, and is therefore a high-value target for attackers. Privilege escalation attacks in Active Directory typically involve exploiting vulnerabilities or misconfigurations across the network to gain elevated privileges, such as Domain Administrator access. Once an attacker has escalated their privileges and taken full control of a domain, they can easily move laterally throughout the network, access sensitive data, and carry out further attacks. Security teams should monitor for privilege escalation attacks in Active Directory to identify a breach before attackers achieve operational success.\
The following analytic story groups detection opportunities that seek to identify an adversary attempting to escalate privileges in an Active Directory network.

[analytic_story://Adobe ColdFusion Arbitrary Code Execution CVE-2023-29298 CVE-2023-26360]
category = Adversary Tactics
last_updated = 2023-08-23
version = 1
references = ["https://helpx.adobe.com/security/products/coldfusion/apsb23-25.html", "https://twitter.com/stephenfewer/status/1678881017526886400?s=20", "https://www.rapid7.com/blog/post/2023/07/11/cve-2023-29298-adobe-coldfusion-access-control-bypass", "https://www.bleepingcomputer.com/news/security/cisa-warns-of-adobe-coldfusion-bug-exploited-as-a-zero-day/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Adobe ColdFusion Access Control Bypass - Rule", "ESCU - Adobe ColdFusion Unauthenticated Arbitrary File Read - Rule"]
description = In July 2023, a significant vulnerability, CVE-2023-29298, affecting Adobe ColdFusion was uncovered by Rapid7, shedding light on an access control bypass mechanism. This vulnerability allows attackers to access sensitive ColdFusion Administrator endpoints by exploiting a flaw in the URL path validation. Disturbingly, this flaw can be chained with another critical vulnerability, CVE-2023-26360, which has been actively exploited. The latter enables unauthorized arbitrary code execution and file reading. Adobe has promptly addressed these vulnerabilities, but the intricacies and potential ramifications of their combination underscore the importance of immediate action by organizations. With active exploitation in the wild and the ability to bypass established security measures, the situation is alarming. Organizations are urged to apply the updates provided by Adobe immediately, considering the active threat landscape and the severe implications of these chained vulnerabilities.
narrative = Adobe ColdFusion, a prominent application server, has been thrust into the cybersecurity spotlight due to two intertwined vulnerabilities. The first, CVE-2023-29298, identified by Rapid7 in July 2023, pertains to an access control bypass in ColdFusion's security mechanisms. This flaw allows attackers to access protected ColdFusion Administrator endpoints simply by manipulating the URL path, specifically by inserting an additional forward slash.\ Compounding the threat is the revelation that CVE-2023-29298 can be chained with CVE-2023-26360, another severe ColdFusion vulnerability. This latter vulnerability, which has seen active exploitation, permits unauthorized attackers to execute arbitrary code or read arbitrary files on the affected system. In practice, an attacker could exploit the access control bypass to access sensitive ColdFusion endpoints and subsequently exploit the arbitrary code execution vulnerability, broadening their control and access over the targeted system. \ The consequences of these vulnerabilities are manifold. Attackers can potentially login to the ColdFusion Administrator with known credentials, bruteforce their way in, leak sensitive information, or exploit other vulnerabilities in the exposed CFM and CFC files. This combination of vulnerabilities significantly heightens the risk profile for organizations using the affected versions of Adobe ColdFusion. \ Addressing the urgency, Adobe released fixes for these vulnerabilities in July 2023, urging organizations to update to ColdFusion 2023 GA build, ColdFusion 2021 Update 7, and ColdFusion 2018 Update 17. However, Rapid7's disclosure highlights a potential incomplete fix, suggesting that organizations should remain vigilant and proactive in their security measures. \
In conclusion, the discovery of these vulnerabilities and their potential to be exploited in tandem presents a significant security challenge. Organizations using Adobe ColdFusion must prioritize the application of security updates, monitor their systems closely for signs of intrusion, and remain updated on any further developments related to these vulnerabilities.

[analytic_story://AgentTesla]
category = Malware
last_updated = 2022-04-12
version = 1
references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.agent_tesla", "https://cert.gov.ua/article/861292", "https://www.cisa.gov/uscert/ncas/alerts/aa22-216a", "https://www.joesandbox.com/analysis/702680/0/html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Add or Set Windows Defender Exclusion - Rule", "ESCU - Detect HTML Help Spawn Child Process - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Excessive Usage Of Taskkill - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Office Application Drop Executable - Rule", "ESCU - Office Application Spawn rundll32 process - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Office Product Spawning CertUtil - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Driver Loaded Path - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Driver Load Non-Standard Path - Rule", "ESCU - Windows Drivers Loaded by Signature - Rule", "ESCU - Windows File Transfer Protocol In Non-Common Process Path - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Mail Protocol In Non-Common Process Path - Rule", "ESCU - Windows Multi hop Proxy TOR Website Query - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the AgentTesla malware including .chm application child process, ftp/smtp connection, persistence and many more. AgentTesla is one of the advanced remote access trojans (RAT) that are capable of stealing sensitive information from the infected or targeted host machine. It can collect various types of data, including browser profile information, keystrokes, capture screenshots and vpn credentials. AgentTesla has been active malware since 2014 and often delivered as a malicious attachment in phishing emails.It is also the top malware in 2021 based on the CISA report.
narrative = Adversaries or threat actor may use this malware to maximize the impact of infection on the target organization in operations where network wide availability interruption is the goal.

[analytic_story://Amadey]
category = Malware
last_updated = 2023-06-16
version = 1
references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.amadey", "https://darktrace.com/blog/amadey-info-stealer-exploiting-n-day-vulnerabilities"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Detect Outlook exe writing a zip file - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Process Creating LNK file in Suspicious Location - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Process Executed From Container File - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Files and Dirs Access Rights Modification Via Icacls - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Powershell RemoteSigned File - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = This analytic story contains searches that aims to detect activities related to Amadey, a type of malware that primarily operates as a banking Trojan. It is designed to steal sensitive information such as login credentials, credit card details, and other financial data from infected systems. The malware typically targets Windows-based computers.
narrative = Amadey is one of the active trojans that are capable of stealing sensitive information via its from the infected or targeted host machine. It can collect various types of data, including browser profile information, clipboard data, capture screenshots and system information. Adversaries or threat actors may use this malware to maximize the impact of infection on the target organization in operations where data collection and exfiltration is the goal. The primary function is to steal information and further distribute malware. It aims to extract a variety of information from infected devices and attempts to evade the detection of security measures by reducing the volume of data exfiltration compared to that seen in other malicious instances.

[analytic_story://Apache Struts Vulnerability]
category = Vulnerability
last_updated = 2018-12-06
version = 1
references = ["https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Suspicious Java Classes - Rule", "ESCU - Web Servers Executing Suspicious Processes - Rule", "ESCU - Unusually Long Content-Type Length - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Investigate Suspicious Strings in HTTP Header - Response Task", "ESCU - Investigate Web POSTs From src - Response Task"]
description = Detect and investigate activities--such as unusually long `Content-Type` length, suspicious java classes and web servers executing suspicious processes--consistent with attempts to exploit Apache Struts vulnerabilities.
narrative = In March of 2017, a remote code-execution vulnerability in the Jakarta Multipart parser in Apache Struts, a widely used open-source framework for creating Java web applications, was disclosed and assigned to CVE-2017-5638. About two months later, hackers exploited the flaw to carry out the world's <a href=https://www.usatoday.com/story/tech/2017/09/07/nations-biggest-hacks-and-data-breaches-millions/644311001/> 5th largest data breach</a>. The target, credit giant Equifax, <a href=https://money.cnn.com/2017/09/16/technology/equifax-breach-security-hole/index.html>told investigators</a> that it had become aware of the vulnerability two months before the attack. \
The exploit involved manipulating the `Content-Type HTTP` header to execute commands embedded in the header.\
This Analytic Story contains two different searches that help to identify activity that may be related to this issue. The first search looks for characteristics of the `Content-Type` header consistent with attempts to exploit the vulnerability. This should be a relatively pertinent indicator, as the `Content-Type` header is generally consistent and does not have a large degree of variation.\
The second search looks for the execution of various commands typically entered on the command shell when an attacker first lands on a system. These commands are not generally executed on web servers during the course of day-to-day operation, but they may be used when the system is undergoing maintenance or troubleshooting.\
First, it is helpful is to understand how often the notable event is generated, as well as the commonalities in some of these events. This may help determine whether this is a common occurrence that is of a lesser concern or a rare event that may require more extensive investigation. It can also help to understand whether the issue is restricted to a single user or system or is broader in scope.\
When looking at the target of the behavior illustrated by the event, you should note the sensitivity of the user and or/system to help determine the potential impact. It is also helpful to see what other events involving the target have occurred in the recent past. This can help tie different events together and give further situational awareness regarding the target.\
Various types of information for external systems should be reviewed and (potentially) collected if the incident is, indeed, judged to be malicious. Information like this can be useful in generating your own threat intelligence to create alerts in the future.\
Looking at the country, responsible party, and fully qualified domain names associated with the external IP address--as well as the registration information associated with those domain names, if they are frequently visited by others--can help you answer the question of "who," in regard to the external system. Answering that can help qualify the event and may serve useful for tracking. In addition, there are various sources that can provide some reputation information on the IP address or domain name, which can assist in determining if the event is malicious in nature. Finally, determining whether or not there are other events associated with the IP address may help connect some dots or show other events that should be brought into scope.\
Gathering various data elements on the system of interest can sometimes help quickly determine that something suspicious may be happening. Some of these items include determining who else may have recently logged into the system, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.\
hen a specific service or application is targeted, it is often helpful to know the associated version to help determine whether or not it is vulnerable to a specific exploit.\
hen it is suspected there is an attack targeting a web server, it is helpful to look at some of the behavior of the web service to see if there is evidence that the service has been compromised. Some indications of this might be network connections to external resources, the web service spawning child processes that are not associated with typical behavior, and whether the service wrote any files that might be malicious in nature.\
In the event that a suspicious file is found, we can review more information about it to help determine if it is, in fact, malicious. Identifying the file type, any processes that have the file open, what processes created and/or modified the file, and the number of systems that may have this file can help to determine if the file is malicious. Also, determining the file hash and checking it against reputation sources, such as VirusTotal, can sometimes quickly help determine whether it is malicious in nature.\
Often, a simple inspection of a suspect process name and path can tell you if the system has been compromised. For example, if `svchost.exe` is found running from a location other than `C:\Windows\System32`, it is likely something malicious designed to hide in plain sight when simply reviewing process names. Similarly, if the process itself seems legitimate, but the parent process is running from the temporary browser cache, there may be activity initiated via a compromised website the user visited.\
It can also be very helpful to examine various behaviors of the process of interest or the parent of the process that is of interest. For example, if it turns out that the process of interest is malicious, it would be good to see if the parent to that process spawned other processes that might also be worth further scrutiny. If a process is suspect, reviewing the network connections made around the time of the event and/or if the process spawned any child processes could be helpful in determining whether it is malicious or executing a malicious script.

[analytic_story://APT29 Diplomatic Deceptions with WINELOADER]
category = Adversary Tactics
last_updated = 2024-03-26
version = 1
references = ["https://www.mandiant.com/resources/blog/apt29-wineloader-german-political-parties", "https://www.zscaler.com/blogs/security-research/european-diplomats-targeted-spikedwine-wineloader"]
maintainers = [{"company": "splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - CertUtil With Decode Argument - Rule", "ESCU - Windows MSHTA Writing to World Writable Path - Rule", "ESCU - Windows SqlWriter SQLDumper DLL Sideload - Rule", "ESCU - Windows Unsigned MS DLL Side-Loading - Rule"]
description = APT29, a sophisticated threat actor linked to the Russian SVR, has expanded its cyber espionage activities to target European diplomats and German political parties. Utilizing a novel backdoor variant, WINELOADER, these campaigns leverage diplomatic-themed lures to initiate infection chains, demonstrating APT29's evolving tactics and interest in geopolitical intelligence. The operations, marked by their low volume and high precision, underscore the broad threat APT29 poses to Western political and diplomatic entities.
narrative = APT29, also known as Cozy Bear, has historically focused on espionage activities aligned with Russian intelligence interests. In recent campaigns, APT29 has notably shifted its operational focus, targeting not only its traditional diplomatic missions but also expanding into the political domain, specifically German political parties. These campaigns have been characterized by the deployment of WINELOADER, a sophisticated backdoor that facilitates the exfiltration of sensitive information. The use of themed lures, such as invitations from the Ambassador of India and CDU-themed documents, highlights APT29's strategic use of social engineering to compromise targets. The operations against European diplomats and German political entities reveal APT29's adaptive tactics and its persistent effort to gather intelligence that could influence Russia's geopolitical strategy. The precision of these attacks, coupled with the use of compromised websites for command and control, underscores the evolving threat landscape and the need for heightened cybersecurity vigilance among potential targets.

[analytic_story://Asset Tracking]
category = Best Practices
last_updated = 2017-09-13
version = 1
references = ["https://www.cisecurity.org/controls/inventory-of-authorized-and-unauthorized-devices/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect Unauthorized Assets by MAC address - Rule", "ESCU - Get First Occurrence and Last Occurrence of a MAC Address - Response Task", "ESCU - Get Notable History - Response Task"]
description = Keep a careful inventory of every asset on your network to make it easier to detect rogue devices. Unauthorized/unmanaged devices could be an indication of malicious behavior that should be investigated further.
narrative = This Analytic Story is designed to help you develop a better understanding of what authorized and unauthorized devices are part of your enterprise. This story can help you better categorize and classify assets, providing critical business context and awareness of their assets during an incident. Information derived from this Analytic Story can be used to better inform and support other analytic stories. For successful detection, you will need to leverage the Assets and Identity Framework from Enterprise Security to populate your known assets.

[analytic_story://AsyncRAT]
category = Malware
last_updated = 2023-01-24
version = 1
references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.asyncrat", "https://www.netskope.com/blog/asyncrat-using-fully-undetected-downloader"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Execution of File with Multiple Extensions - Rule", "ESCU - Loading Of Dynwrapx Module - Rule", "ESCU - Malicious PowerShell Process - Execution Policy Bypass - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule", "ESCU - Powershell Processing Stream Of Data - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule", "ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Copy on System32 - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Vbscript Execution Using Wscript App - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Powershell Cryptography Namespace - Rule", "ESCU - Windows Scheduled Task with Highest Privileges - Rule", "ESCU - Windows Spearphishing Attachment Connect To None MS Office Domain - Rule", "ESCU - Windows Spearphishing Attachment Onenote Spawn Mshta - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the AsyncRAT malware including mshta application child process, bat loader execution, persistence and many more. AsyncRAT is an open source remote administration tool released last 2019. It's designed to remotely control computers via an encrypted connection, with view screen, keylogger, chat communication, persistence, defense evasion (e.g. Windows defender), DOS attack and many more.
narrative = although this project contains legal disclaimer, Adversaries or threat actors are popularly used in some attacks. This malware recently came across a Fully undetected batch script loader that downloads and loads the AsyncRAT from its C2 server. The batch script is obfuscated and will load a powershell loader that will decode and decrypt (AES256) the actual AsyncRAT malware.

[analytic_story://Atlassian Confluence Server and Data Center CVE-2022-26134]
category = Adversary Tactics
last_updated = 2022-06-03
version = 1
references = ["https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html", "https://www.splunk.com/en_us/blog/security/atlassian-confluence-vulnerability-cve-2022-26134.html", "https://www.rapid7.com/blog/post/2022/06/02/active-exploitation-of-confluence-cve-2022-26134/", "https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Java Writing JSP File - Rule", "ESCU - Confluence Unauthenticated Remote Code Execution CVE-2022-26134 - Rule"]
description = On June 2, security researchers at Volexity published a blog outlining the discovery of an unauthenticated remote code execution zero day vulnerability (CVE-2022-26134) being actively exploited in Atlassian Confluence Server and Data Center instances in the wild. Atlassian released a fix within 24 hours of the blog''s release.
narrative = Atlassian describes the vulnerability as an Object-Graph Navigation Language (OGNL) injection allowing an unauthenticated user to execute arbitrary code on a Confluence Server or Data Server instance. Volexity did not release proof-of-concept (POC) exploit code, but researchers there have observed coordinated, widespread exploitation. Volexity first discovered the vulnerability over the weekend on two Internet-facing web servers running Confluence Server software. The investigation was due to suspicious activity on the hosts, including JSP webshells that were written to disk.

[analytic_story://AwfulShred]
category = Malware
last_updated = 2023-01-24
version = 1
references = ["https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/overview-of-the-cyber-weapons-used-in-the-ukraine-russia-war/", "https://cert.gov.ua/article/3718487"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Linux Data Destruction Command - Rule", "ESCU - Linux Deleting Critical Directory Using RM Command - Rule", "ESCU - Linux Deletion Of Services - Rule", "ESCU - Linux Disable Services - Rule", "ESCU - Linux Hardware Addition SwapOff - Rule", "ESCU - Linux Impair Defenses Process Kill - Rule", "ESCU - Linux Indicator Removal Clear Cache - Rule", "ESCU - Linux Indicator Removal Service File Deletion - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Shred Overwrite Command - Rule", "ESCU - Linux Stop Services - Rule", "ESCU - Linux System Reboot Via System Request Key - Rule", "ESCU - Linux Unix Shell Enable All SysRq Functions - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the AwfulShred malware including wiping files, process kill, system reboot via system request, shred,  and service stops.
narrative = AwfulShred is a malicious linux shell script designed to corrupt or wipe the linux targeted system. It uses shred command to overwrite files and to increase data damage. This obfuscated malicious script can also disable and corrupts apache, HTTP and SSH services, deactivate swap files, clear bash history and finally reboot the system.

[analytic_story://AWS Cross Account Activity]
category = Cloud Security
last_updated = 2018-06-04
version = 1
references = ["https://aws.amazon.com/blogs/security/aws-cloudtrail-now-tracks-cross-account-activity-to-its-origin/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - aws detect attach to role policy - Rule", "ESCU - aws detect permanent key creation - Rule", "ESCU - aws detect role creation - Rule", "ESCU - aws detect sts assume role abuse - Rule", "ESCU - aws detect sts get session token abuse - Rule", "ESCU - AWS Investigate User Activities By AccessKeyId - Response Task", "ESCU - Get Notable History - Response Task"]
description = Track when a user assumes an IAM role in another AWS account to obtain cross-account access to services and resources in that account. Accessing new roles could be an indication of malicious activity.
narrative = Amazon Web Services (AWS) admins manage access to AWS resources and services across the enterprise using AWS's Identity and Access Management (IAM) functionality. IAM provides the ability to create and manage AWS users, groups, and roles-each with their own unique set of privileges and defined access to specific resources (such as EC2 instances, the AWS Management Console, API, or the command-line interface). Unlike conventional (human) users, IAM roles are assumable by anyone in the organization. They provide users with dynamically created temporary security credentials that expire within a set time period.\
Herein lies the rub. In between the time between when the temporary credentials are issued and when they expire is a period of opportunity, where a user could leverage the temporary credentials to wreak havoc-spin up or remove instances, create new users, elevate privileges, and other malicious activities-throughout the environment.\
This Analytic Story includes searches that will help you monitor your AWS CloudTrail logs for evidence of suspicious cross-account activity.  For example, while accessing multiple AWS accounts and roles may be perfectly valid behavior, it may be suspicious when an account requests privileges of an account it has not accessed in the past. After identifying suspicious activities, you can use the provided investigative searches to help you probe more deeply.

[analytic_story://AWS Defense Evasion]
category = Cloud Security
last_updated = 2022-07-15
version = 1
references = ["https://attack.mitre.org/tactics/TA0005/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Gowthamaraj Rajendran"}]
spec_version = 3
searches = ["ESCU - ASL AWS Defense Evasion Delete Cloudtrail - Rule", "ESCU - ASL AWS Defense Evasion Delete CloudWatch Log Group - Rule", "ESCU - ASL AWS Defense Evasion Impair Security Services - Rule", "ESCU - AWS Defense Evasion Delete Cloudtrail - Rule", "ESCU - AWS Defense Evasion Delete CloudWatch Log Group - Rule", "ESCU - AWS Defense Evasion Impair Security Services - Rule", "ESCU - AWS Defense Evasion PutBucketLifecycle - Rule", "ESCU - AWS Defense Evasion Stop Logging Cloudtrail - Rule", "ESCU - AWS Defense Evasion Update Cloudtrail - Rule"]
description = Identify activity and techniques associated with the Evasion of Defenses within AWS, such as Disabling CloudTrail, Deleting CloudTrail and many others.
narrative = Adversaries employ a variety of techniques in order to avoid detection and operate without barriers. This often involves modifying the configuration of security monitoring tools to get around them or explicitly disabling them to prevent them from running. This Analytic Story includes analytics that identify activity consistent with adversaries attempting to disable various security mechanisms on AWS. Such activity may involve deleting the CloudTrail logs , as this is where all the AWS logs get stored or explicitly changing the retention policy of S3 buckets. Other times, adversaries attempt deletion of a specified AWS CloudWatch log group.

[analytic_story://AWS IAM Privilege Escalation]
category = Cloud Security
last_updated = 2021-03-08
version = 1
references = ["https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/", "https://www.cyberark.com/resources/threat-research-blog/the-cloud-shadow-admin-threat-10-permissions-to-protect", "https://labs.bishopfox.com/tech-blog/privilege-escalation-in-aws"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - ASL AWS CreateAccessKey - Rule", "ESCU - ASL AWS IAM Delete Policy - Rule", "ESCU - ASL AWS Password Policy Changes - Rule", "ESCU - AWS Create Policy Version to allow all resources - Rule", "ESCU - AWS CreateAccessKey - Rule", "ESCU - AWS CreateLoginProfile - Rule", "ESCU - AWS IAM Assume Role Policy Brute Force - Rule", "ESCU - AWS IAM Delete Policy - Rule", "ESCU - AWS IAM Failure Group Deletion - Rule", "ESCU - AWS IAM Successful Group Deletion - Rule", "ESCU - AWS Password Policy Changes - Rule", "ESCU - AWS SetDefaultPolicyVersion - Rule", "ESCU - AWS UpdateLoginProfile - Rule"]
description = This analytic story contains detections that query your AWS Cloudtrail for activities related to privilege escalation.
narrative = Amazon Web Services provides a neat feature called Identity and Access Management (IAM) that enables organizations to manage various AWS services and resources in a secure way. All IAM users have roles, groups and policies associated with them which governs and sets permissions to allow a user to access specific restrictions.\
However, if these IAM policies are misconfigured and have specific combinations of weak permissions; it can allow attackers to escalate their privileges and further compromise the organization. Rhino Security Labs have published comprehensive blogs detailing various AWS Escalation methods. By using this as an inspiration, Splunks research team wants to highlight how these attack vectors look in AWS Cloudtrail logs and provide you with detection queries to uncover these potentially malicious events via this Analytic Story. 

[analytic_story://AWS Identity and Access Management Account Takeover]
category = Cloud Security
last_updated = 2022-08-19
version = 2
references = ["https://attack.mitre.org/tactics/TA0006/"]
maintainers = [{"company": "Bhavin Patel,  Splunk", "email": "-", "name": "Gowthamaraj Rajendran"}]
spec_version = 3
searches = ["ESCU - ASL AWS Concurrent Sessions From Different Ips - Rule", "ESCU - ASL AWS Multi-Factor Authentication Disabled - Rule", "ESCU - ASL AWS New MFA Method Registered For User - Rule", "ESCU - AWS Concurrent Sessions From Different Ips - Rule", "ESCU - AWS Console Login Failed During MFA Challenge - Rule", "ESCU - AWS Credential Access Failed Login - Rule", "ESCU - AWS Credential Access GetPasswordData - Rule", "ESCU - AWS Credential Access RDS Password reset - Rule", "ESCU - AWS High Number Of Failed Authentications For User - Rule", "ESCU - AWS High Number Of Failed Authentications From Ip - Rule", "ESCU - AWS Multi-Factor Authentication Disabled - Rule", "ESCU - AWS Multiple Failed MFA Requests For User - Rule", "ESCU - AWS Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - AWS New MFA Method Registered For User - Rule", "ESCU - AWS Successful Single-Factor Authentication - Rule", "ESCU - AWS Unusual Number of Failed Authentications From Ip - Rule", "ESCU - Detect AWS Console Login by New User - Rule", "ESCU - Detect AWS Console Login by User from New City - Rule", "ESCU - Detect AWS Console Login by User from New Country - Rule", "ESCU - Detect AWS Console Login by User from New Region - Rule"]
description = Identify activity and techniques associated with accessing credential files from AWS resources, monitor unusual authentication related activities to the AWS Console and other services such as RDS.
narrative = Amazon Web Services provides a web service known as Identity and Access Management(IAM) for controlling and securly managing various AWS resources. This is basically the foundation of how users in AWS interact with various resources/services in cloud and vice versa. Account Takeover (ATO) is an attack whereby cybercriminals gain unauthorized access to online accounts by using different techniques like brute force, social engineering, phishing & spear phishing, credential stuffing, etc. Adversaries employ a variety of techniques to steal AWS Cloud credentials like account names, passwords and keys and takeover legitmate user accounts. Usage of legitimate keys will assist the attackers to gain access to other sensitive system and they can also mimic legitimate behaviour making them harder to be detected. Such activity may involve multiple failed login to the console, new console logins and password reset activities.

[analytic_story://AWS Network ACL Activity]
category = Cloud Security
last_updated = 2018-05-21
version = 2
references = ["https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html", "https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - AWS Network Access Control List Created with All Open Ports - Rule", "ESCU - AWS Network Access Control List Deleted - Rule", "ESCU - Detect Spike in blocked Outbound Traffic from your AWS - Rule", "ESCU - Detect Spike in Network ACL Activity - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - AWS Network ACL Details from ID - Response Task", "ESCU - AWS Network Interface details via resourceId - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Monitor your AWS network infrastructure for bad configurations and malicious activity. Investigative searches help you probe deeper, when the facts warrant it.
narrative = AWS CloudTrail is an AWS service that helps you enable governance, compliance, and operational/risk auditing of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. It is crucial for a company to monitor events and actions taken in the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs to ensure that your servers are not vulnerable to attacks. This analytic story contains detection searches that leverage CloudTrail logs from AWS to check for bad configurations and malicious activity in your AWS network access controls.

[analytic_story://AWS Security Hub Alerts]
category = Cloud Security
last_updated = 2020-08-04
version = 1
references = ["https://aws.amazon.com/security-hub/features/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect Spike in AWS Security Hub Alerts for EC2 Instance - Rule", "ESCU - Detect Spike in AWS Security Hub Alerts for User - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get EC2 Launch Details - Response Task"]
description = This story is focused around detecting Security Hub alerts generated from AWS
narrative = AWS Security Hub collects and consolidates findings from AWS security services enabled in your environment, such as intrusion detection findings from Amazon GuardDuty, vulnerability scans from Amazon Inspector, S3 bucket policy findings from Amazon Macie, publicly accessible and cross-account resources from IAM Access Analyzer, and resources lacking WAF coverage from AWS Firewall Manager.

[analytic_story://AWS User Monitoring]
category = Cloud Security
last_updated = 2018-03-12
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf", "https://redlock.io/blog/cryptojacking-tesla"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - ASL AWS Excessive Security Scanning - Rule", "ESCU - AWS Excessive Security Scanning - Rule", "ESCU - Detect API activity from users without MFA - Rule", "ESCU - Detect AWS API Activities From Unapproved Accounts - Rule", "ESCU - Detect new API calls from user roles - Rule", "ESCU - Detect Spike in AWS API Activity - Rule", "ESCU - Detect Spike in Security Group Activity - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Investigate AWS User Activities by user field - Response Task"]
description = Detect and investigate dormant user accounts for your AWS environment that have become active again. Because inactive and ad-hoc accounts are common attack targets, it's critical to enable governance within your environment.
narrative = It seems obvious that it is critical to monitor and control the users who have access to your cloud infrastructure. Nevertheless, it's all too common for enterprises to lose track of ad-hoc accounts, leaving their servers vulnerable to attack. In fact, this was the very oversight that led to Tesla's cryptojacking attack in February, 2018.\
In addition to compromising the security of your data, when bad actors leverage your compute resources, it can incur monumental costs, since you will be billed for any new EC2 instances and increased bandwidth usage. \
Fortunately, you can leverage Amazon Web Services (AWS) CloudTrail--a tool that helps you enable governance, compliance, and risk auditing of your AWS account--to give you increased visibility into your user and resource activity by recording AWS Management Console actions and API calls. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred.\
The detection searches in this Analytic Story are designed to help you uncover AWS API activities from users not listed in the identity table, as well as similar activities from disabled accounts.

[analytic_story://Azorult]
category = Malware
last_updated = 2022-06-09
version = 1
references = ["https://success.trendmicro.com/dcx/s/solution/000146108-azorult-malware-information?language=en_US\u0026sfdcIFrameOrigin=null", "https://app.any.run/tasks/a6f2ffe2-e6e2-4396-ae2e-04ea0143f2d8/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - Allow Operation with Consent Admin - Rule", "ESCU - Attempt To Stop Security Service - Rule", "ESCU - CHCP Command Execution - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Create local admin accounts using net exe - Rule", "ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule", "ESCU - Disable Defender BlockAtFirstSeen Feature - Rule", "ESCU - Disable Defender Enhanced Notification - Rule", "ESCU - Disable Defender Spynet Reporting - Rule", "ESCU - Disable Defender Submit Samples Consent Feature - Rule", "ESCU - Disable Show Hidden Files - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Excessive Attempt To Disable Services - Rule", "ESCU - Excessive Usage Of Cacls App - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Excessive Usage Of SC Service Utility - Rule", "ESCU - Excessive Usage Of Taskkill - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - Hide User Account From Sign-In Screen - Rule", "ESCU - Hiding Files And Directories With Attrib exe - Rule", "ESCU - Icacls Deny Command - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Connection Discovery With Net - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Office Product Spawning MSHTA - Rule", "ESCU - Processes launching netsh - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Windows Application Layer Protocol RMS Radmin Tool Namedpipe - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows Defender Exclusion Registry Entry - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows Gather Victim Network Info Through Ip Check Web Services - Rule", "ESCU - Windows Impair Defense Add Xml Applocker Rules - Rule", "ESCU - Windows Impair Defense Deny Security Software With Applocker - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Modify Registry Disable Toast Notifications - Rule", "ESCU - Windows Modify Registry Disable Win Defender Raw Write Notif - Rule", "ESCU - Windows Modify Registry Disable Windows Security Center Notif - Rule", "ESCU - Windows Modify Registry Disabling WER Settings - Rule", "ESCU - Windows Modify Registry DisAllow Windows App - Rule", "ESCU - Windows Modify Registry Regedit Silent Reg Import - Rule", "ESCU - Windows Modify Registry Suppress Win Defender Notif - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule", "ESCU - Windows Powershell Import Applocker Policy - Rule", "ESCU - Windows Remote Access Software RMS Registry - Rule", "ESCU - Windows Remote Service Rdpwinst Tool Execution - Rule", "ESCU - Windows Remote Services Allow Rdp In Firewall - Rule", "ESCU - Windows Remote Services Allow Remote Assistance - Rule", "ESCU - Windows Remote Services Rdp Enable - Rule", "ESCU - Windows Service Stop By Deletion - Rule", "ESCU - Windows Valid Account With Never Expires Password - Rule", "ESCU - Wmic NonInteractive App Uninstallation - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Azorult malware including firewall modification, icacl execution, spawning more process, botnet c2 communication, defense evasion and etc. The AZORULT malware was first discovered in 2016 to be an information stealer that steals browsing history, cookies, ID/passwords, cryptocurrency information and more. It can also be a downloader of other malware. A variant of this malware was able to create a new, hidden administrator account on the machine to set a registry key to establish a Remote Desktop Protocol (RDP) connection. Exploit kits such as Fallout Exploit Kit (EK) and phishing mails with social engineering technique are one of the major infection vectors of the AZORult malware. The current malspam and phishing emails use fake product order requests, invoice documents and payment information requests. This Trojan-Spyware connects to Command And Control (C&C) servers of attacker to send and receive information.
narrative = Adversaries may use this technique to maximize the impact on the target organization in operations where network wide availability interruption is the goal.

[analytic_story://Azure Active Directory Account Takeover]
category = Adversary Tactics
last_updated = 2022-07-14
version = 2
references = ["https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis", "https://azure.microsoft.com/en-us/services/active-directory/#overview", "https://attack.mitre.org/techniques/T1586/", "https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-compare-azure-ad-to-ad", "https://www.imperva.com/learn/application-security/account-takeover-ato/", "https://www.varonis.com/blog/azure-active-directory", "https://www.barracuda.com/glossary/account-takeover"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Azure Active Directory High Risk Sign-in - Rule", "ESCU - Azure AD Authentication Failed During MFA Challenge - Rule", "ESCU - Azure AD Block User Consent For Risky Apps Disabled - Rule", "ESCU - Azure AD Concurrent Sessions From Different Ips - Rule", "ESCU - Azure AD Device Code Authentication - Rule", "ESCU - Azure AD High Number Of Failed Authentications For User - Rule", "ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule", "ESCU - Azure AD Multi-Factor Authentication Disabled - Rule", "ESCU - Azure AD Multi-Source Failed Authentications Spike - Rule", "ESCU - Azure AD Multiple AppIDs and UserAgents Authentication Spike - Rule", "ESCU - Azure AD Multiple Denied MFA Requests For User - Rule", "ESCU - Azure AD Multiple Failed MFA Requests For User - Rule", "ESCU - Azure AD Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - Azure AD New MFA Method Registered For User - Rule", "ESCU - Azure AD OAuth Application Consent Granted By User - Rule", "ESCU - Azure AD Service Principal Authentication - Rule", "ESCU - Azure AD Successful Authentication From Different Ips - Rule", "ESCU - Azure AD Successful PowerShell Authentication - Rule", "ESCU - Azure AD Successful Single-Factor Authentication - Rule", "ESCU - Azure AD Unusual Number of Failed Authentications From Ip - Rule", "ESCU - Azure AD User Consent Blocked for Risky Application - Rule", "ESCU - Azure AD User Consent Denied for OAuth Application - Rule"]
description = Monitor for activities and techniques associated with Account Takeover attacks against Azure Active Directory tenants.
narrative = Azure Active Directory (Azure AD) is Microsofts enterprise cloud-based identity and access management (IAM) service. Azure AD is the backbone of most of Azure services like Office 365. It can sync with on-premise Active Directory environments and provide authentication to other cloud-based systems via the OAuth protocol. According to Microsoft, Azure AD manages more than 1.2 billion identities and processes over 8 billion authentications per day. Account Takeover (ATO) is an attack whereby cybercriminals gain unauthorized access to online accounts by using different techniques like brute force, social engineering, phishing & spear phishing, credential stuffing, etc. By posing as the real user, cyber-criminals can change account details, send out phishing emails, steal financial information or sensitive data, or use any stolen information to access further accounts within the organization. This analytic storic groups detections that can help security operations teams identify the potential compromise of Azure Active Directory accounts.

[analytic_story://Azure Active Directory Persistence]
category = Cloud Security
last_updated = 2022-08-17
version = 1
references = ["https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis", "https://azure.microsoft.com/en-us/services/active-directory/#overview", "https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-compare-azure-ad-to-ad", "https://attack.mitre.org/tactics/TA0003/", "https://microsoft.github.io/Azure-Threat-Research-Matrix/Persistence/Persistence/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Azure AD External Guest User Invited - Rule", "ESCU - Azure AD FullAccessAsApp Permission Assigned - Rule", "ESCU - Azure AD Global Administrator Role Assigned - Rule", "ESCU - Azure AD Multiple Service Principals Created by SP - Rule", "ESCU - Azure AD Multiple Service Principals Created by User - Rule", "ESCU - Azure AD New Custom Domain Added - Rule", "ESCU - Azure AD New Federated Domain Added - Rule", "ESCU - Azure AD New MFA Method Registered - Rule", "ESCU - Azure AD PIM Role Assigned - Rule", "ESCU - Azure AD PIM Role Assignment Activated - Rule", "ESCU - Azure AD Privileged Graph API Permission Assigned - Rule", "ESCU - Azure AD Privileged Role Assigned - Rule", "ESCU - Azure AD Service Principal Created - Rule", "ESCU - Azure AD Service Principal New Client Credentials - Rule", "ESCU - Azure AD Service Principal Owner Added - Rule", "ESCU - Azure AD Tenant Wide Admin Consent Granted - Rule", "ESCU - Azure AD User Enabled And Password Reset - Rule", "ESCU - Azure AD User ImmutableId Attribute Updated - Rule", "ESCU - Azure Automation Account Created - Rule", "ESCU - Azure Automation Runbook Created - Rule", "ESCU - Azure Runbook Webhook Created - Rule", "ESCU - Windows Multiple Account Passwords Changed - Rule", "ESCU - Windows Multiple Accounts Deleted - Rule", "ESCU - Windows Multiple Accounts Disabled - Rule"]
description = Monitor for activities and techniques associated with the execution of Persistence techniques against Azure Active Directory tenants.
narrative = Azure Active Directory (Azure AD) is Microsofts enterprise cloud-based identity and access management (IAM) service. Azure AD is the backbone of most of Azure services like Office 365. It can sync with on-premise Active Directory environments and provide authentication to other cloud-based systems via the OAuth protocol. According to Microsoft, Azure AD manages more than 1.2 billion identities and processes over 8 billion authentications per day.\ Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. This analytic storic groups detections that can help security operations teams identify the potential execution of Persistence techniques targeting Azure Active Directory tenants. 

[analytic_story://Azure Active Directory Privilege Escalation]
category = Adversary Tactics
last_updated = 2023-04-24
version = 1
references = ["https://attack.mitre.org/tactics/TA0003/", "https://cloudbrothers.info/en/azure-attack-paths/", "https://microsoft.github.io/Azure-Threat-Research-Matrix/PrivilegeEscalation/PrivEsc/", "https://posts.specterops.io/azure-privilege-escalation-via-service-principal-abuse-210ae2be2a5"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Azure AD Admin Consent Bypassed by Service Principal - Rule", "ESCU - Azure AD Application Administrator Role Assigned - Rule", "ESCU - Azure AD Global Administrator Role Assigned - Rule", "ESCU - Azure AD PIM Role Assigned - Rule", "ESCU - Azure AD PIM Role Assignment Activated - Rule", "ESCU - Azure AD Privileged Authentication Administrator Role Assigned - Rule", "ESCU - Azure AD Privileged Role Assigned to Service Principal - Rule", "ESCU - Azure AD Service Principal New Client Credentials - Rule", "ESCU - Azure AD Service Principal Owner Added - Rule"]
description = Monitor for activities and techniques associated with Privilege Escalation attacks within Azure Active Directory tenants.
narrative = Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives. Common approaches are to take advantage of system weaknesses, misconfigurations or vulnerabilities.\
Azure Active Directory (Azure AD) is Microsofts enterprise cloud-based identity and access management (IAM) service. Azure AD is the backbone of most of Azure services like Office 365 and Microsoft Teams. It can sync with on-premise Active Directory environments and provide authentication to other cloud-based systems via the OAuth protocol. According to Microsoft, Azure AD manages more than 1.2 billion identities and processes over 8 billion authentications per day.\
Privilege escalation attacks in Azure AD typically involve abusing  misconfigurations to gain elevated privileges, such as Global Administrator access. Once an attacker has escalated their privileges and taken full control of a tenant, they may abuse every service that leverages Azure AD including moving laterally to Azure virtual machines to access sensitive data and carry out further attacks. Security teams should monitor for privilege escalation attacks in Azure Active Directory to identify breaches before attackers achieve operational success.\
The following analytic story groups detection opportunities that seek to identify an adversary attempting to escalate privileges in Azure AD tenants.

[analytic_story://Baron Samedit CVE-2021-3156]
category = Adversary Tactics
last_updated = 2021-01-27
version = 1
references = ["https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Shannon Davis"}]
spec_version = 3
searches = ["ESCU - Detect Baron Samedit CVE-2021-3156 - Rule", "ESCU - Detect Baron Samedit CVE-2021-3156 Segfault - Rule", "ESCU - Detect Baron Samedit CVE-2021-3156 via OSQuery - Rule"]
description = Uncover activity consistent with CVE-2021-3156. Discovered by the Qualys Research Team, this vulnerability has been found to affect sudo across multiple Linux distributions (Ubuntu 20.04 and prior, Debian 10 and prior, Fedora 33 and prior). As this vulnerability was committed to code in July 2011, there will be many distributions affected. Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host.
narrative = A non-privledged user is able to execute the sudoedit command to trigger a buffer overflow. After the successful buffer overflow, they are then able to gain root privileges on the affected host. The conditions needed to be run are a trailing "\" along with shell and edit flags. Monitoring the /var/log directory on Linux hosts using the Splunk Universal Forwarder will allow you to pick up this behavior when using the provided detection.

[analytic_story://BishopFox Sliver Adversary Emulation Framework]
category = Adversary Tactics
last_updated = 2023-01-24
version = 1
references = ["https://www.cybereason.com/blog/sliver-c2-leveraged-by-many-threat-actors", "https://www.ncsc.gov.uk/files/Advisory%20Further%20TTPs%20associated%20with%20SVR%20cyber%20actors.pdf", "https://www.proofpoint.com/uk/blog/security-briefs/ta551-uses-sliver-red-team-tool-new-activity", "https://www.cybereason.com/blog/threat-analysis-report-bumblebee-loader-the-high-road-to-enterprise-domain-control", "https://github.com/sliverarmory/armory", "https://github.com/BishopFox/sliver"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Notepad with no Command Line Arguments - Rule", "ESCU - Windows Process Injection into Notepad - Rule", "ESCU - Windows Service Create SliverC2 - Rule"]
description = The following analytic story providers visibility into the latest adversary TTPs in regard to the use of Sliver. Sliver has gained more traction with adversaries as it is often seen as an alternative to Cobalt Strike. It is designed to be scalable and can be used by organizations of all sizes to perform security testing. Sliver is highly modular and contains an Extension package manager (armory) allowing easy install (automatic compilation) of various 3rd party tools such as BOFs and .NET tooling like Ghostpack (Rubeus, Seatbelt, SharpUp, Certify, and so forth) (CyberReason,2023).
narrative = Sliver is an open source cross-platform adversary emulation/red team framework produced by BishopFox.

[analytic_story://BITS Jobs]
category = Adversary Tactics
last_updated = 2021-03-26
version = 1
references = ["https://attack.mitre.org/techniques/T1197/", "https://docs.microsoft.com/en-us/windows/win32/bits/bitsadmin-tool"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - BITS Job Persistence - Rule", "ESCU - BITSAdmin Download File - Rule", "ESCU - PowerShell Start-BitsTransfer - Rule"]
description = Adversaries may abuse BITS jobs to persistently execute or clean up after malicious payloads.
narrative = Windows Background Intelligent Transfer Service (BITS) is a low-bandwidth, asynchronous file transfer mechanism exposed through Component Object Model (COM). BITS is commonly used by updaters, messengers, and other applications preferred to operate in the background (using available idle bandwidth) without interrupting other networked applications. File transfer tasks are implemented as BITS jobs, which contain a queue of one or more file operations. The interface to create and manage BITS jobs is accessible through PowerShell and the BITSAdmin tool. Adversaries may abuse BITS to download, execute, and even clean up after running malicious code. BITS tasks are self-contained in the BITS job database, without new files or registry modifications, and often permitted by host firewalls. BITS enabled execution may also enable persistence by creating long-standing jobs (the default maximum lifetime is 90 days and extendable) or invoking an arbitrary program when a job completes or errors (including after system reboots).

[analytic_story://BlackByte Ransomware]
category = Malware
last_updated = 2023-07-10
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2023/07/06/the-five-day-job-a-blackbyte-ransomware-intrusion-case-study/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Allow File And Printing Sharing In Firewall - Rule", "ESCU - Allow Network Discovery In Firewall - Rule", "ESCU - Anomalous usage of 7zip - Rule", "ESCU - CMD Echo Pipe - Escalation - Rule", "ESCU - Cobalt Strike Named Pipes - Rule", "ESCU - Detect Exchange Web Shell - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Regsvr32 Application Control Bypass - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Disabling Firewall with Netsh - Rule", "ESCU - DLLHost with no Command Line Arguments with Network - Rule", "ESCU - Excessive File Deletion In WinDefender Folder - Rule", "ESCU - Excessive Service Stop Attempt - Rule", "ESCU - Exchange PowerShell Abuse via SSRF - Rule", "ESCU - Exchange PowerShell Module Usage - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - GPUpdate with no Command Line Arguments with Network - Rule", "ESCU - High Process Termination Frequency - Rule", "ESCU - MS Exchange Mailbox Replication service writing Active Server Pages - Rule", "ESCU - Ping Sleep Batch Command - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Resize ShadowStorage volume - Rule", "ESCU - Rundll32 with no Command Line Arguments with Network - Rule", "ESCU - SearchProtocolHost with no Command Line with Network - Rule", "ESCU - Services Escalate Exe - Rule", "ESCU - Suspicious DLLHost no Command Line Arguments - Rule", "ESCU - Suspicious Driver Loaded Path - Rule", "ESCU - Suspicious GPUpdate no Command Line Arguments - Rule", "ESCU - Suspicious microsoft workflow compiler rename - Rule", "ESCU - Suspicious msbuild path - Rule", "ESCU - Suspicious MSBuild Rename - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Rundll32 no Command Line Arguments - Rule", "ESCU - Suspicious Rundll32 StartW - Rule", "ESCU - Suspicious SearchProtocolHost no Command Line Arguments - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows Driver Load Non-Standard Path - Rule", "ESCU - Windows Drivers Loaded by Signature - Rule", "ESCU - Windows Modify Registry EnableLinkedConnections - Rule", "ESCU - Windows Modify Registry LongPathsEnabled - Rule", "ESCU - Windows MSExchange Management Mailbox Cmdlet Usage - Rule", "ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - Windows RDP Connection Successful - Rule", "ESCU - Windows Vulnerable Driver Loaded - Rule", "ESCU - ProxyShell ProxyNotShell Behavior Detected - Rule", "ESCU - Windows Exchange Autodiscover SSRF Abuse - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the BlackByte ransomware, including looking for file writes associated with BlackByte, persistence, initial access, account registry modification and more.
narrative = BlackByte ransomware campaigns targeting business operations, involve the use of ransomware payloads, infection chain to collect and exfiltrate data and drop payload on the targeted system. BlackByte Ransomware operates by infiltrating a system through various methods, such as malicious email attachments, exploit kits, or compromised websites. Once inside a system, it begins encrypting files using strong encryption algorithms, rendering them unusable. After completing the encryption process, BlackByte Ransomware typically leaves a ransom note that explains the situation to the victim and provides instructions on how to pay the ransom to obtain the decryption key.

[analytic_story://BlackLotus Campaign]
category = Adversary Tactics
last_updated = 2023-04-14
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/", "https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows BootLoader Inventory - Rule", "ESCU - Windows Impair Defenses Disable HVCI - Rule", "ESCU - Windows WinLogon with Public Network Connection - Rule"]
description = The first in-the-wild UEFI bootkit bypassing UEFI Secure Boot on fully updated UEFI systems is now a reality
narrative = The number of UEFI vulnerabilities discovered in recent years and the failures in patching them or revoking vulnerable binaries within a reasonable time window hasn't gone unnoticed by threat actors. As a result, the first publicly known UEFI bootkit bypassing the essential platform security feature  UEFI Secure Boot  is now a reality. present the first public analysis of this UEFI bootkit, which is capable of running on even fully-up-to-date Windows 11 systems with UEFI Secure Boot enabled. Functionality of the bootkit and its individual features leads us to believe that we are dealing with a bootkit known as BlackLotus, the UEFI bootkit being sold on hacking forums for $5,000 since at least October 2022. (ESET, 2023) The following content aims to aid defenders in detecting suspicious bootloaders and understanding the diverse techniques employed in this campaign.

[analytic_story://BlackMatter Ransomware]
category = Malware
last_updated = 2021-09-06
version = 1
references = ["https://news.sophos.com/en-us/2021/08/09/blackmatter-ransomware-emerges-from-the-shadow-of-darkside/", "https://www.bleepingcomputer.com/news/security/blackmatter-ransomware-gang-rises-from-the-ashes-of-darkside-revil/", "https://blog.malwarebytes.com/ransomware/2021/07/blackmatter-a-new-ransomware-group-claims-link-to-darkside-revil/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Add DefaultUser And Password In Registry - Rule", "ESCU - Auto Admin Logon Registry Entry - Rule", "ESCU - Bcdedit Command Back To Normal Mode Boot - Rule", "ESCU - Change To Safe Mode With Network Config - Rule", "ESCU - Known Services Killed by Ransomware - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - Ransomware Notes bulk creation - Rule", "ESCU - SchCache Change By App Connect And Create ADSI Object - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the BlackMatter ransomware, including looking for file writes associated with BlackMatter, force safe mode boot, autadminlogon account registry modification and more.
narrative = BlackMatter ransomware campaigns targeting healthcare and other vertical sectors, involve the use of ransomware payloads along with exfiltration of data per HHS bulletin. Malicious actors demand payment for ransome of data and threaten deletion and exposure of exfiltrated data.

[analytic_story://Brand Monitoring]
category = Abuse
last_updated = 2017-12-19
version = 1
references = ["https://www.zerofox.com/blog/what-is-digital-risk-monitoring/", "https://securingtomorrow.mcafee.com/consumer/family-safety/what-is-typosquatting/", "https://blog.malwarebytes.com/cybercrime/2016/06/explained-typosquatting/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Monitor Email For Brand Abuse - Rule", "ESCU - Monitor DNS For Brand Abuse - Rule", "ESCU - Monitor Web Traffic For Brand Abuse - Rule", "ESCU - Get Email Info - Response Task", "ESCU - Get Emails From Specific Sender - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Detect and investigate activity that may indicate that an adversary is using faux domains to mislead users into interacting with malicious infrastructure. Monitor DNS, email, and web traffic for permutations of your brand name.
narrative = While you can educate your users and customers about the risks and threats posed by typosquatting, phishing, and corporate espionage, human error is a persistent fact of life. Of course, your adversaries are all too aware of this reality and will happily leverage it for nefarious purposes whenever possible&#51;phishing with lookalike addresses, embedding faux command-and-control domains in malware, and hosting malicious content on domains that closely mimic your corporate servers. This is where brand monitoring comes in.\
You can use our adaptation of `DNSTwist`, together with the support searches in this Analytic Story, to generate permutations of specified brands and external domains. Splunk can monitor email, DNS requests, and web traffic for these permutations and provide you with early warnings and situational awareness--powerful elements of an effective defense.\
Notable events will include IP addresses, URLs, and user data. Drilling down can provide you with even more actionable intelligence, including likely geographic information, contextual searches to help you scope the problem, and investigative searches.

[analytic_story://Brute Ratel C4]
category = Data Destruction
last_updated = 2022-08-23
version = 1
references = ["https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/", "https://www.mdsec.co.uk/2022/08/part-3-how-i-met-your-beacon-brute-ratel/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Access Token Manipulation Winlogon Duplicate Token Handle - Rule", "ESCU - Windows Access Token Winlogon Duplicate Handle In Uncommon Path - Rule", "ESCU - Windows Defacement Modify Transcodedwallpaper File - Rule", "ESCU - Windows Gather Victim Identity SAM Info - Rule", "ESCU - Windows Hijack Execution Flow Version Dll Side Load - Rule", "ESCU - Windows Input Capture Using Credential UI Dll - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule", "ESCU - Windows Process Injection With Public Source Path - Rule", "ESCU - Windows Remote Access Software BRC4 Loaded Dll - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Windows Service Deletion In Registry - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that may be related to Brute Ratel Red Teaming tool. This includes creation, modification and deletion of services, collection or data, ping IP, DNS cache, process injection, debug privileges adjustment, winlogon process duplicate token, lock workstation, get clipboard or screenshot and much more.
narrative = Brute RATEL BRC4 is the latest red-teaming tool that simulate several TTP's. It uses several techniques like syscall, patching ETW/AMSI and written in native C to minimize noise in process command-line. This tool was seen in the wild being abused by some ransomware (blackcat) and adversaries in their campaigns to install the BRC4 agent that can serve as remote admin tool to compromise the target host or network.

[analytic_story://Caddy Wiper]
category = Data Destruction
last_updated = 2022-03-25
version = 1
references = ["https://twitter.com/ESETresearch/status/1503436420886712321", "https://www.welivesecurity.com/2022/03/15/caddywiper-new-wiper-malware-discovered-ukraine/"]
maintainers = [{"company": "Rod Soto, Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule"]
description = Caddy Wiper is a destructive payload that detects if its running on a Domain Controller and executes killswitch if detected. If not in a DC it destroys Users and subsequent mapped drives. This wiper also destroys drive partitions inculding boot partitions.
narrative = Caddy Wiper is destructive malware operation found by ESET multiple organizations in Ukraine. This malicious payload destroys user files, avoids executing on Dnomain Controllers and destroys boot and drive partitions.

[analytic_story://Chaos Ransomware]
category = Malware
last_updated = 2023-01-11
version = 1
references = ["https://blog.qualys.com/vulnerabilities-threat-research/2022/01/17/the-chaos-ransomware-can-be-ravaging", "https://www.fortinet.com/blog/threat-research/chaos-ransomware-variant-in-fake-minecraft-alt-list-brings-destruction", "https://marcoramilli.com/2021/06/14/the-allegedly-ryuk-ransomware-builder-ryukjoke/", "https://www.trendmicro.com/en_us/research/21/h/chaos-ransomware-a-dangerous-proof-of-concept.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Prevent Automatic Repair Mode using Bcdedit - Rule", "ESCU - Ransomware Notes bulk creation - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - WBAdmin Delete System Backups - Rule", "ESCU - Windows Boot or Logon Autostart Execution In Startup Folder - Rule", "ESCU - Windows Replication Through Removable Media - Rule", "ESCU - Windows User Execution Malicious URL Shortcut File - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Chaos ransomware, including looking for file writes (file encryption and ransomware notes), deleting shadow volume storage, registry key modification, dropping of files in startup folder, and more.
narrative = CHAOS ransomware has been seen and monitored since 2021. This ransomware is purportedly a .NET version of Ryuk ransomware but upon closer look to its code and behavior, this malware sample reveals that it doesn't share much relation to the notorious RYUK ransomware. This ransomware is one of the known ransomware that was used in the ongoing geo-political war. This ransomware is capable to check that only one copy of itself is running on the targeted host, delay of execution as part of its defense evasion technique, persistence through registry and startup folder, drop a copy of itself in each root drive of the targeted host and also in %appdata% folder and many more. As of writing this ransomware is still active and keeps on infecting Windows Operating machines and Windows networks.

[analytic_story://CISA AA22-257A]
category = Adversary Tactics
last_updated = 2022-09-15
version = 1
references = ["https://www.cisa.gov/uscert/ncas/alerts/aa21-321a", "https://www.cisa.gov/uscert/ncas/alerts/aa22-257a", "https://www.ic3.gov/Media/News/2021/210527.pdf", "https://www.us-cert.gov/sites/default/files/AA22-257A.stix.xml", "https://www.us-cert.cisa.gov/iran"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Dump LSASS via procdump Rename - Rule", "ESCU - Create local admin accounts using net exe - Rule", "ESCU - Creation of lsass Dump with Taskmgr - Rule", "ESCU - Detect Exchange Web Shell - Rule", "ESCU - Detect New Local Admin account - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Dump LSASS via procdump - Rule", "ESCU - Extraction of Registry Hives - Rule", "ESCU - Randomly Generated Scheduled Task Name - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks Run Task On Demand - Rule", "ESCU - Short Lived Scheduled Task - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows Hidden Schedule Task Settings - Rule", "ESCU - Windows Possible Credential Dumping - Rule", "ESCU - Windows Protocol Tunneling with Plink - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule", "ESCU - Log4Shell JNDI Payload Injection Attempt - Rule"]
description = The Iranian government-sponsored APT actors are actively targeting a broad range of victims across multiple U.S. critical infrastructure sectors, including the Transportation Sector and the Healthcare and Public Health Sector, as well as Australian organizations.
narrative = This advisory updates joint CSA Iranian Government-Sponsored APT Cyber Actors Exploiting Microsoft Exchange and Fortinet Vulnerabilities in Furtherance of Malicious Activities, which provides information on these Iranian government-sponsored APT actors exploiting known Fortinet and Microsoft Exchange vulnerabilities to gain initial access to a broad range of targeted entities in furtherance of malicious activities, including ransom operations. The authoring agencies now judge these actors are an APT group affiliated with the IRGC. Since the initial reporting of this activity in the FBI Liaison Alert System (FLASH) report APT Actors Exploiting Fortinet Vulnerabilities to Gain Access for Malicious Activity from May 2021, the authoring agencies have continued to observe these IRGC-affiliated actors exploiting known vulnerabilities for initial access. In addition to exploiting Fortinet and Microsoft Exchange vulnerabilities, the authoring agencies have observed these APT actors exploiting VMware Horizon Log4j vulnerabilities for initial access. The IRGC-affiliated actors have used this access for follow-on activity, including disk encryption and data extortion, to support ransom operations. The IRGC-affiliated actors are actively targeting a broad range of entities, including entities across multiple U.S. critical infrastructure sectors as well as Australian, Canadian, and United Kingdom organizations. These actors often operate under the auspices of Najee Technology Hooshmand Fater LLC, based in Karaj, Iran, and Afkar System Yazd Company, based in Yazd, Iran. The authoring agencies assess the actors are exploiting known vulnerabilities on unprotected networks rather than targeting specific targeted entities or sectors. This advisory provides observed tactics, techniques, and indicators of compromise (IOCs) that the authoring agencies assess are likely associated with this IRGC-affiliated APT. The authoring agencies urge organizations, especially critical infrastructure organizations, to apply the recommendations listed in the Mitigations section of this advisory to mitigate risk of compromise from these IRGC-affiliated cyber actors.

[analytic_story://CISA AA22-264A]
category = Adversary Tactics
last_updated = 2022-09-22
version = 1
references = ["https://www.cisa.gov/uscert/ncas/alerts/aa22-264a", "https://www.cisa.gov/uscert/sites/default/files/publications/aa22-264a-iranian-cyber-actors-conduct-cyber-operations-against-the-government-of-albania.pdf", "https://www.mandiant.com/resources/blog/likely-iranian-threat-actor-conducts-politically-motivated-disruptive-activity-against", "https://www.microsoft.com/security/blog/2022/09/08/microsoft-investigates-iranian-attacks-against-the-albanian-government/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Attacker Tools On Endpoint - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Excessive Usage Of Taskkill - Rule", "ESCU - Exchange PowerShell Module Usage - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows Event Log Cleared - Rule", "ESCU - Windows Possible Credential Dumping - Rule", "ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - Windows System File on Disk - Rule"]
description = Iranian State Actors Conduct Cyber Operations Against the Government of Albania.
narrative = The Federal Bureau of Investigation (FBI) and the Cybersecurity and Infrastructure Security Agency (CISA) are releasing this joint Cybersecurity Advisory to provide information on recent cyber operations against the Government of Albania in July and September. This advisory provides a timeline of activity observed, from initial access to execution of encryption and wiper attacks. Additional information concerning files used by the actors during their exploitation of and cyber attack against the victim organization is provided in Appendices A and B. In September 2022, Iranian cyber actors launched another wave of cyber attacks against the Government of Albania, using similar TTPs and malware as the cyber attacks in July. These were likely done in retaliation for public attribution of the cyber attacks in July and severed diplomatic ties between Albania and Iran.

[analytic_story://CISA AA22-277A]
category = Adversary Tactics
last_updated = 2022-10-05
version = 1
references = ["https://www.cisa.gov/uscert/ncas/alerts/aa22-277a", "https://www.cisa.gov/uscert/sites/default/files/publications/aa22-277a-impacket-and-exfiltration-tool-used-to-steal-sensitive-information-from-defense-industrial-base-organization.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Detect Renamed WinRAR - Rule", "ESCU - Excessive Usage Of Taskkill - Rule", "ESCU - Exchange PowerShell Module Usage - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Network Discovery Using Route Windows App - Rule"]
description = From November 2021 through January 2022, the Cybersecurity and Infrastructure Security Agency (CISA) responded to advanced persistent threat (APT) activity on a Defense Industrial Base (DIB) Sector organization's enterprise network. During incident response activities, multiple utilities were utilized.
narrative = CISA uncovered that likely multiple APT groups compromised the organization's network, and some APT actors had long-term access to the environment. APT actors used an open-source toolkit called Impacket to gain their foothold within the environment and further compromise the network, and also used a custom data exfiltration tool, CovalentStealer, to steal the victim's sensitive data.

[analytic_story://CISA AA22-320A]
category = Adversary Tactics
last_updated = 2022-11-16
version = 1
references = ["https://www.cisa.gov/uscert/ncas/alerts/aa22-320a", "https://www.cisa.gov/uscert/sites/default/files/publications/aa22-320a_joint_csa_iranian_government-sponsored_apt_actors_compromise_federal%20network_deploy_crypto%20miner_credential_harvester.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Suspicious Powershell Command-Line Arguments - Rule", "ESCU - Add or Set Windows Defender Exclusion - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Enable WDigest UseLogonCredential Registry - Rule", "ESCU - GetAdComputer with PowerShell Script Block - Rule", "ESCU - Log4Shell CVE-2021-44228 Exploitation - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Mimikatz PassTheTicket CommandLine Parameters - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Suspicious Driver Loaded Path - Rule", "ESCU - Windows Driver Load Non-Standard Path - Rule", "ESCU - Windows Drivers Loaded by Signature - Rule", "ESCU - Windows Mimikatz Binary Execution - Rule", "ESCU - Windows Ngrok Reverse Proxy Usage - Rule", "ESCU - Windows Service Create Kernel Mode Driver - Rule", "ESCU - XMRIG Driver Loaded - Rule", "ESCU - Ngrok Reverse Proxy on Network - Rule", "ESCU - Hunting for Log4Shell - Rule", "ESCU - Log4Shell JNDI Payload Injection Attempt - Rule", "ESCU - Log4Shell JNDI Payload Injection with Outbound Connection - Rule"]
description = CISA and the FBI have identified an APT activity where the adversary gained initial access via Log4Shell via a unpatched VMware Horizon server. From there the adversary moved laterally and continued to its objective.
narrative = From mid-June through mid-July 2022, CISA conducted an incident response engagement at a Federal Civilian Executive Branch (FCEB) organization where CISA observed suspected advanced persistent threat (APT) activity. In the course of incident response activities, CISA determined that cyber threat actors exploited the Log4Shell vulnerability in an unpatched VMware Horizon server, installed XMRig crypto mining software, moved laterally to the domain controller (DC), compromised credentials, and then implanted Ngrok reverse proxies on several hosts to maintain persistence. CISA and the Federal Bureau of Investigation (FBI) assess that the FCEB network was compromised by Iranian government-sponsored APT actors.

[analytic_story://CISA AA23-347A]
category = Data Destruction
last_updated = 2023-12-14
version = 1
references = ["https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a"]
maintainers = [{"company": "Rod Soto, Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Access LSASS Memory for Dump Creation - Rule", "ESCU - AdsiSearcher Account Discovery - Rule", "ESCU - Attempted Credential Dump From Registry via Reg exe - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Detect Credential Dumping through LSASS access - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - Disable AMSI Through Registry - Rule", "ESCU - Disable Defender BlockAtFirstSeen Feature - Rule", "ESCU - Disable Defender Enhanced Notification - Rule", "ESCU - Disable Defender Spynet Reporting - Rule", "ESCU - Disable Defender Submit Samples Consent Feature - Rule", "ESCU - Disable ETW Through Registry - Rule", "ESCU - Disable Logs Using WevtUtil - Rule", "ESCU - Disable Security Logs Using MiniNt Registry - Rule", "ESCU - Disable UAC Remote Restriction - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Disable Windows SmartScreen Protection - Rule", "ESCU - Disabled Kerberos Pre-Authentication Discovery With Get-ADUser - Rule", "ESCU - Disabling FolderOptions Windows Feature - Rule", "ESCU - Domain Controller Discovery with Nltest - Rule", "ESCU - ETW Registry Disabled - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Extraction of Registry Hives - Rule", "ESCU - Get ADUser with PowerShell - Rule", "ESCU - Get ADUser with PowerShell Script Block - Rule", "ESCU - Get ADUserResultantPasswordPolicy with Powershell - Rule", "ESCU - Get ADUserResultantPasswordPolicy with Powershell Script Block - Rule", "ESCU - Get DomainUser with PowerShell - Rule", "ESCU - Get DomainUser with PowerShell Script Block - Rule", "ESCU - Mimikatz PassTheTicket CommandLine Parameters - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - PowerShell Domain Enumeration - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Remote Process Instantiation via WMI - Rule", "ESCU - Remote WMI Command Attempt - Rule", "ESCU - Rubeus Command Line Parameters - Rule", "ESCU - Rubeus Kerberos Ticket Exports Through Winlogon Access - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Services Escalate Exe - Rule", "ESCU - Services LOLBAS Execution Process Spawn - Rule", "ESCU - Short Lived Scheduled Task - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Suspicious wevtutil Usage - Rule", "ESCU - System User Discovery With Whoami - Rule", "ESCU - Unload Sysmon Filter Driver - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Account Discovery for None Disable User Account - Rule", "ESCU - Windows Account Discovery for Sam Account Name - Rule", "ESCU - Windows Account Discovery With NetUser PreauthNotRequire - Rule", "ESCU - Windows Archive Collected Data via Powershell - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Disable Notification Center - Rule", "ESCU - Windows Disable Windows Event Logging Disable HTTP Logging - Rule", "ESCU - Windows Disable Windows Group Policy Features Through Registry - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows DISM Remove Defender - Rule", "ESCU - Windows Domain Account Discovery Via Get-NetComputer - Rule", "ESCU - Windows Excessive Disabled Services Event - Rule", "ESCU - Windows Hunting System Account Targeting Lsass - Rule", "ESCU - Windows Impair Defenses Disable Win Defender Auto Logging - Rule", "ESCU - Windows Known GraphicalProton Loaded Modules - Rule", "ESCU - Windows LSA Secrets NoLMhash Registry - Rule", "ESCU - Windows Mimikatz Binary Execution - Rule", "ESCU - Windows Mimikatz Crypto Export File Extensions - Rule", "ESCU - Windows Modify Registry Disable Restricted Admin - Rule", "ESCU - Windows Modify Registry Disable Win Defender Raw Write Notif - Rule", "ESCU - Windows Modify Registry Disable WinDefender Notifications - Rule", "ESCU - Windows Modify Registry Disable Windows Security Center Notif - Rule", "ESCU - Windows Modify Registry DisableSecuritySettings - Rule", "ESCU - Windows Modify Registry Disabling WER Settings - Rule", "ESCU - Windows Modify Registry No Auto Update - Rule", "ESCU - Windows Modify Registry Suppress Win Defender Notif - Rule", "ESCU - Windows Non-System Account Targeting Lsass - Rule", "ESCU - Windows Possible Credential Dumping - Rule", "ESCU - Windows PowerView Constrained Delegation Discovery - Rule", "ESCU - Windows PowerView SPN Discovery - Rule", "ESCU - Windows PowerView Unconstrained Delegation Discovery - Rule", "ESCU - Windows Process Commandline Discovery - Rule", "ESCU - Windows Query Registry Reg Save - Rule", "ESCU - Windows Remote Create Service - Rule", "ESCU - Windows Scheduled Task Created Via XML - Rule", "ESCU - Windows Scheduled Task with Highest Privileges - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Creation on Remote Endpoint - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Windows Service Initiation on Remote Endpoint - Rule", "ESCU - Windows Service Stop Win Updates - Rule", "ESCU - Windows System User Privilege Discovery - Rule", "ESCU - Windows WMI Process Call Create - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinRM Spawning a Process - Rule", "ESCU - JetBrains TeamCity RCE Attempt - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might be related to the  SVR cyber activity tactics and techniques. While SVR followed a similar playbook in each compromise, they also adjusted to each operating environment and not all presented steps or actions below were executed on every host.
narrative = SVR cyber operations pose a persistent threat to public and private organizations' networks globally. Since 2013, cybersecurity companies and governments have reported on SVR operations targeting victim networks to steal confidential and proprietary information. A decade later, the authoring agencies can infer a long-term targeting pattern aimed at collecting, and enabling the collection of, foreign intelligence, a broad concept that for Russia encompasses information on the politics, economics, and military of foreign states; science and technology; and foreign counterintelligence. The SVR also conducts cyber operations targeting technology companies that enable future cyber operations. The SVR's recent operation has targeted networks hosting TeamCity servers, further underscoring its persistent focus on technology companies. By leveraging CVE-2023-42793, a vulnerability within a software development program, the SVR seeks to gain access to victims, potentially compromising numerous software developers' networks. JetBrains responded to this threat by issuing a patch in mid-September 2023, limting the SVR's ability to exploit Internet-accessible TeamCity servers lacking the necessary updates. Despite this mitigation, the SVR has yet to utilize its acquired access to software developers' networks for breaching customer systems. It appears that the SVR is still in the preparatory stages of its operation.

[analytic_story://Cisco IOS XE Software Web Management User Interface vulnerability]
category = Adversary Tactics
last_updated = 2023-10-17
version = 1
references = ["https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Cisco IOS XE Implant Access - Rule"]
description = Cisco has identified active exploitation of a previously unknown vulnerability in the Web User Interface (Web UI) feature of Cisco IOS XE software (CVE-2023-20198) when exposed to the internet or untrusted networks. Successful exploitation of this vulnerability allows an attacker to create an account on the affected device with privilege level 15 access, effectively granting them full control of the compromised device and allowing possible subsequent unauthorized activity.
narrative = Cisco discovered early evidence of potentially malicious activity on September 28, 2023, when a case was opened with Cisco's Technical Assistance Center (TAC) that identified unusual behavior on a customer device. Upon further investigation, they observed what they have determined to be related activity as early as September 18. The activity included an authorized user creating a local user account under the username cisco_tac_admin from a suspicious IP address. On October 12, Cisco Talos Incident Response (Talos IR) and TAC detected what they later determined to be an additional cluster of related activity that began on that same day. In this cluster, an unauthorized user was observed creating a local user account under the name cisco_support from a second suspicious IP address. Unlike the September case, this October activity included several subsequent actions, including the deployment of an implant consisting of a configuration file (cisco_service.conf). The configuration file defines the new web server endpoint (URI path) used to interact with the implant. That endpoint receives certain parameters, described in more detail below, that allows the actor to execute arbitrary commands at the system level or IOS level. For the implant to become active, the web server must be restarted; in at least one observed case the server was not restarted so the implant never became active despite being installed.

[analytic_story://Citrix NetScaler ADC and NetScaler Gateway CVE-2023-4966]
category = Adversary Tactics
last_updated = 2023-10-24
version = 1
references = ["https://www.netscaler.com/blog/news/cve-2023-4966-critical-security-update-now-available-for-netscaler-adc-and-netscaler-gateway/", "https://support.citrix.com/article/CTX579459/netscaler-adc-and-netscaler-gateway-security-bulletin-for-cve20234966-and-cve20234967", "https://www.assetnote.io/resources/research/citrix-bleed-leaking-session-tokens-with-cve-2023-4966", "https://github.com/assetnote/exploits/tree/main/citrix/CVE-2023-4966", "https://github.com/projectdiscovery/nuclei-templates/blob/b815d23b908de52996060163091395d1c89fbeea/http/cves/2023/CVE-2023-4966.yaml"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Citrix ADC and Gateway Unauthorized Data Disclosure - Rule"]
description = A critical security update, CVE-2023-4966, has been released for NetScaler ADC and NetScaler Gateway. This vulnerability, discovered by our internal team, can result in unauthorized data disclosure if exploited. Reports of incidents consistent with session hijacking have been received. The Cybersecurity and Infrastructure Security Agency (CISA) has added an entry for CVE-2023-4966 to its Known Exploited and Vulnerabilities Catalog. No workarounds are available for this vulnerability, and immediate installation of the recommended builds is strongly advised.
narrative = On October 10, 2023, Cloud Software Group released builds to fix CVE-2023-4966, a vulnerability affecting NetScaler ADC and NetScaler Gateway. This vulnerability, if exploited, can lead to unauthorized data disclosure and possibly session hijacking. Although there were no known exploits at the time of disclosure, we have since received credible reports of targeted attacks exploiting this vulnerability. The Cybersecurity and Infrastructure Security Agency (CISA) has added an entry for CVE-2023-4966 to its Known Exploited and Vulnerabilities Catalog, which contains detection and mitigation guidance for observed exploitations of CVE-2023-4966 by threat actors against NetScaler ADC and NetScaler Gateway. We strongly recommend that users of affected builds immediately install the recommended builds, as this vulnerability has been identified as critical. No workarounds are available for this vulnerability.

[analytic_story://Citrix Netscaler ADC CVE-2023-3519]
category = Adversary Tactics
last_updated = 2023-07-20
version = 1
references = ["https://attackerkb.com/topics/si09VNJhHh/cve-2023-3519", "https://www.cisa.gov/sites/default/files/2023-07/aa23-201a_csa_threat_actors_exploiting_citrix-cve-2023-3519_to_implant_webshells.pdf", "https://support.citrix.com/article/CTX561482/citrix-adc-and-citrix-gateway-security-bulletin-for-cve20233519-cve20233466-cve20233467"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Citrix ADC Exploitation CVE-2023-3519 - Rule"]
description = The CVE-2023-3519 vulnerability in NetScaler (formerly Citrix) Application Delivery Controller (ADC) and NetScaler Gateway has been exploited by threat actors, as detailed in a recent advisory. The unauthenticated remote code execution vulnerability was utilized as a zero-day to establish a webshell on a non-production environment NetScaler ADC appliance within a critical infrastructure organization. This facilitated the execution of discovery on the victim's active directory and the collection and exfiltration of data. The advisory offers a comprehensive examination of the threat actors' tactics, techniques, and procedures (TTPs), alongside recommended detection methods and incident response guidelines. Immediate patch application from Citrix and the use of the detection guidance in the advisory is strongly recommended for critical infrastructure organizations to mitigate system compromises.
narrative = Recent advisories have highlighted the exploitation of CVE-2023-3519, a critical vulnerability in Citrix's NetScaler Application Delivery Controller (ADC) and NetScaler Gateway. In June 2023, threat actors utilized this vulnerability to implant a webshell on a NetScaler ADC appliance within a critical infrastructure organization's non-production environment. This action granted them the ability to perform active directory discovery, data collection, and exfiltration. Notably, attempts for lateral movement to a domain controller were obstructed by network-segmentation controls. \
The compromised organization reported the breach, leading Citrix to issue a patch on July 18, 2023. Multiple advisories have since outlined the threat actors' tactics, techniques, and procedures (TTPs), including their initial access, persistence, privilege escalation, defense evasion, credential access, discovery, collection, command and control, and impact. These advisories also provide detection methods and recommend incident response measures. \
The threat actors executed several activities during their attack, such as uploading a TGZ file with a generic webshell, discovery script, and setuid binary on the ADC appliance; conducting SMB scanning on the subnet; using the webshell for active directory enumeration and data exfiltration; and accessing NetScaler configuration files and decryption keys. They also decrypted an active directory credential, queried the active directory for various information, encrypted collected data, exfiltrated it as an image file, and attempted to erase their artifacts. Despite these actions, further discovery and lateral movement were impeded due to the organization's network-segmentation controls. \
Advisories suggest conducting specific checks on the ADC shell interface to detect signs of compromise. If a compromise is detected, organizations should isolate potentially affected hosts, reimage compromised hosts, provide new account credentials, collect and review artifacts, and report the compromise. To mitigate the threat, organizations are advised to promptly install the relevant updates for NetScaler ADC and NetScaler Gateway, adhere to cybersecurity best practices, and apply robust network-segmentation controls on NetScaler appliances and other internet-facing devices. \

[analytic_story://Citrix ShareFile RCE CVE-2023-24489]
category = Adversary Tactics
last_updated = 2023-07-26
version = 1
references = ["https://www.greynoise.io/blog/introducing-cve-2023-24489-a-critical-citrix-sharefile-rce-vulnerability", "https://blog.assetnote.io/2023/07/04/citrix-sharefile-rce/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Citrix ShareFile Exploitation CVE-2023-24489 - Rule"]
description = A critical vulnerability has been discovered in ShareFile's Storage Zones Controller software (CVE-2023-24489), used by numerous organizations for file sharing and storage. The vulnerability allows unauthenticated arbitrary file upload and remote code execution due to a cryptographic bug in the software's encryption but lack of authentication system. The risk comes from a failing encryption check, allowing potential cybercriminals to upload malicious files to the server. The bug was found in the Documentum Connector's .aspx files. The security risk has a potentially large impact due to the software's wide use and the sensitivity of the stored data. Citrix has released a security update to address this issue.
narrative = The ShareFile Storage Zones Controller is a .NET web application running under IIS, which manages the storage of files in ShareFile's system. It was discovered that this software has a critical vulnerability (CVE-2023-24489) in the file upload functionality provided by the Documentum Connector's .aspx files. Specifically, the security flaw lies in the encryption check in the file upload process which could be bypassed, allowing for unauthenticated arbitrary file uploads and remote code execution. \
The application sets the current principal from a session cookie, but if this is missing, the application continues without authentication. The application uses AES encryption, with CBC mode and PKCS#7 padding. A decryption check is in place which returns an error if the decryption fails, but this can be bypassed by supplying a ciphertext that results in valid padding after decryption, thereby not causing an exception. \
The Documentum Connector's upload.aspx file, when uploading a file, calls the ProcessRawPostedFile function, which allows a path traversal due to improper sanitization of the 'uploadId' parameter. It allows the 'filename' and 'uploadId' parameters to be concatenated, and while the 'filename' parameter is sanitized, the 'uploadId' is not. The 'parentid' parameter is passed in but is also not used. \
The vulnerability enables an attacker to upload a webshell or any other malicious file, by providing a properly padded encrypted string for the 'parentid' parameter, and specifying the path for the 'uploadId' and the name for the 'filename'. An attacker can achieve remote code execution by requesting the uploaded file. The issue was addressed by Citrix in a recent security update.

[analytic_story://Clop Ransomware]
category = Malware
last_updated = 2021-03-17
version = 1
references = ["https://www.hhs.gov/sites/default/files/analyst-note-cl0p-tlp-white.pdf", "https://securityaffairs.co/wordpress/115250/data-breach/qualys-clop-ransomware.html", "https://www.darkreading.com/attacks-breaches/qualys-is-the-latest-victim-of-accellion-data-breach/d/d-id/1340323"]
maintainers = [{"company": "Teoderick Contreras, Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Clop Common Exec Parameter - Rule", "ESCU - Clop Ransomware Known Service Name - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - High Process Termination Frequency - Rule", "ESCU - Process Deleting Its Process File Path - Rule", "ESCU - Ransomware Notes bulk creation - Rule", "ESCU - Resize ShadowStorage volume - Rule", "ESCU - Suspicious Event Log Service Behavior - Rule", "ESCU - Suspicious wevtutil Usage - Rule", "ESCU - Windows Event Log Cleared - Rule", "ESCU - Windows High File Deletion Frequency - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Clop ransomware, including looking for file writes associated with Clope, encrypting network shares, deleting and resizing shadow volume storage, registry key modification, deleting of security logs, and more.
narrative = Clop ransomware campaigns targeting healthcare and other vertical sectors, involve the use of ransomware payloads along with exfiltration of data per HHS bulletin. Malicious actors demand payment for ransome of data and threaten deletion and exposure of exfiltrated data.

[analytic_story://Cloud Cryptomining]
category = Cloud Security
last_updated = 2019-10-02
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Abnormally High Number Of Cloud Instances Launched - Rule", "ESCU - Cloud Compute Instance Created By Previously Unseen User - Rule", "ESCU - Cloud Compute Instance Created In Previously Unused Region - Rule", "ESCU - Cloud Compute Instance Created With Previously Unseen Image - Rule", "ESCU - Cloud Compute Instance Created With Previously Unseen Instance Type - Rule", "ESCU - AWS Investigate Security Hub alerts by dest - Response Task", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get EC2 Launch Details - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Investigate AWS activities via region name - Response Task"]
description = Monitor your cloud compute instances for activities related to cryptojacking/cryptomining. New instances that originate from previously unseen regions, users who launch abnormally high numbers of instances, or compute instances started by previously unseen users are just a few examples of potentially malicious behavior.
narrative = Cryptomining is an intentionally difficult, resource-intensive business. Its complexity was designed into the process to ensure that the number of blocks mined each day would remain steady. So, it's par for the course that ambitious, but unscrupulous, miners make amassing the computing power of large enterprises--a practice known as cryptojacking--a top priority. \
Cryptojacking has attracted an increasing amount of media attention since its explosion in popularity in the fall of 2017. The attacks have moved from in-browser exploits and mobile phones to enterprise cloud services, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure. It's difficult to determine exactly how widespread the practice has become, since bad actors continually evolve their ability to escape detection, including employing unlisted endpoints, moderating their CPU usage, and hiding the mining pool's IP address behind a free CDN. \
When malicious miners appropriate a cloud instance, often spinning up hundreds of new instances, the costs can become astronomical for the account holder. So it is critically important to monitor your systems for suspicious activities that could indicate that your network has been infiltrated. \
This Analytic Story is focused on detecting suspicious new instances in your cloud environment to help prevent cryptominers from gaining a foothold. It contains detection searches that will detect when a previously unused instance type or AMI is used. It also contains support searches to build lookup files to ensure proper execution of the detection searches.

[analytic_story://Cloud Federated Credential Abuse]
category = Cloud Security
last_updated = 2021-01-26
version = 1
references = ["https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps", "https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/wp-m-unc2452-2021-000343-01.pdf", "https://us-cert.cisa.gov/ncas/alerts/aa21-008a"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - AWS SAML Access by Provider User and Principal - Rule", "ESCU - AWS SAML Update identity provider - Rule", "ESCU - O365 Add App Role Assignment Grant User - Rule", "ESCU - O365 Added Service Principal - Rule", "ESCU - O365 Excessive SSO logon errors - Rule", "ESCU - O365 New Federated Domain Added - Rule", "ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Detect Mimikatz Via PowerShell And EventCode 4703 - Rule", "ESCU - Certutil exe certificate extraction - Rule", "ESCU - Registry Keys Used For Privilege Escalation - Rule"]
description = This analytical story addresses events that indicate abuse of cloud federated credentials. These credentials are usually extracted from endpoint desktop or servers specially those servers that provide federation services such as Windows Active Directory Federation Services. Identity Federation relies on objects such as Oauth2 tokens, cookies or SAML assertions in order to provide seamless access between cloud and perimeter environments. If these objects are either hijacked or forged then attackers will be able to pivot into victim's cloud environements.
narrative = This story is composed of detection searches based on endpoint that addresses the use of Mimikatz, Escalation of Privileges and Abnormal processes that may indicate the extraction of Federated directory objects such as passwords, Oauth2 tokens, certificates and keys. Cloud environment (AWS, Azure) related events are also addressed in specific cloud environment detection searches.

[analytic_story://Cobalt Strike]
category = Adversary Tactics
last_updated = 2021-02-16
version = 1
references = ["https://www.cobaltstrike.com/", "https://www.infocyte.com/blog/2020/09/02/cobalt-strike-the-new-favorite-among-thieves/", "https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/", "https://blog.talosintelligence.com/2020/09/coverage-strikes-back-cobalt-strike-paper.html", "https://www.fireeye.com/blog/threat-research/2020/12/unauthorized-access-of-fireeye-red-team-tools.html", "https://github.com/MichaelKoczwara/Awesome-CobaltStrike-Defence", "https://github.com/zer0yu/Awesome-CobaltStrike"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Anomalous usage of 7zip - Rule", "ESCU - CMD Echo Pipe - Escalation - Rule", "ESCU - Cobalt Strike Named Pipes - Rule", "ESCU - Detect Regsvr32 Application Control Bypass - Rule", "ESCU - DLLHost with no Command Line Arguments with Network - Rule", "ESCU - GPUpdate with no Command Line Arguments with Network - Rule", "ESCU - Rundll32 with no Command Line Arguments with Network - Rule", "ESCU - SearchProtocolHost with no Command Line with Network - Rule", "ESCU - Services Escalate Exe - Rule", "ESCU - Suspicious DLLHost no Command Line Arguments - Rule", "ESCU - Suspicious GPUpdate no Command Line Arguments - Rule", "ESCU - Suspicious microsoft workflow compiler rename - Rule", "ESCU - Suspicious msbuild path - Rule", "ESCU - Suspicious MSBuild Rename - Rule", "ESCU - Suspicious Rundll32 no Command Line Arguments - Rule", "ESCU - Suspicious Rundll32 StartW - Rule", "ESCU - Suspicious SearchProtocolHost no Command Line Arguments - Rule"]
description = Cobalt Strike is threat emulation software. Red teams and penetration testers use Cobalt Strike to demonstrate the risk of a breach and evaluate mature security programs. Most recently, Cobalt Strike has become the choice tool by threat groups due to its ease of use and extensibility.
narrative = This Analytic Story supports you to detect Tactics, Techniques and Procedures (TTPs) from Cobalt Strike. Cobalt Strike has many ways to be enhanced by using aggressor scripts, malleable C2 profiles, default attack packages, and much more. For endpoint behavior, Cobalt Strike is most commonly identified via named pipes, spawn to processes, and DLL function names. Many additional variables are provided for in memory operation of the beacon implant. On the network, depending on the malleable C2 profile used, it is near infinite in the amount of ways to conceal the C2 traffic with Cobalt Strike. Not every query may be specific to Cobalt Strike the tool, but the methodologies and techniques used by it.\
Splunk Threat Research reviewed all publicly available instances of Malleabe C2 Profiles and generated a list of the most commonly used spawnto and pipenames.\
`Spawnto_x86` and `spawnto_x64` is the process that Cobalt Strike will spawn and injects shellcode into.\
Pipename sets the named pipe name used in Cobalt Strikes Beacon SMB C2 traffic.\
With that, new detections were generated focused on these spawnto processes spawning without command line arguments. Similar, the named pipes most commonly used by Cobalt Strike added as a detection. In generating content for Cobalt Strike, the following is considered:\
- Is it normal for spawnto_ value to have no command line arguments? No command line arguments and a network connection?\
- What is the default, or normal, process lineage for spawnto_ value?\
- Does the spawnto_ value make network connections?\
- Is it normal for spawnto_ value to load jscript, vbscript, Amsi.dll, and clr.dll?\
While investigating a detection related to this Analytic Story, keep in mind the parent process, process path, and any file modifications that may occur. Tuning may need to occur to remove any false positives.

[analytic_story://ColdRoot MacOS RAT]
category = Malware
last_updated = 2019-01-09
version = 1
references = ["https://www.intego.com/mac-security-blog/osxcoldroot-and-the-rat-invasion/", "https://objective-see.com/blog/blog_0x2A.html", "https://www.bleepingcomputer.com/news/security/coldroot-rat-still-undetectable-despite-being-uploaded-on-github-two-years-ago/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Jose Hernandez"}]
spec_version = 3
searches = ["ESCU - Osquery pack - ColdRoot detection - Rule", "ESCU - MacOS - Re-opened Applications - Rule", "ESCU - Processes Tapping Keyboard Events - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Investigate Network Traffic From src ip - Response Task"]
description = Leverage searches that allow you to detect and investigate unusual activities that relate to the ColdRoot Remote Access Trojan that affects MacOS. An example of some of these activities are changing sensative binaries in the MacOS sub-system, detecting process names and executables associated with the RAT, detecting when a keyboard tab is installed on a MacOS machine and more.
narrative = Conventional wisdom holds that Apple's MacOS operating system is significantly less vulnerable to attack than Windows machines. While that point is debatable, it is true that attacks against MacOS systems are much less common. However, this fact does not mean that Macs are impervious to breaches. To the contrary, research has shown that that Mac malware is increasing at an alarming rate. According to AV-test, in 2018, there were 86,865 new MacOS malware variants, up from 27,338 the year before&#151;a 31% increase. In contrast, the independent research firm found that new Windows malware had increased from 65.17M to 76.86M during that same period, less than half the rate of growth. The bottom line is that while the numbers look a lot smaller than Windows, it's definitely time to take Mac security more seriously.\
This Analytic Story addresses the ColdRoot remote access trojan (RAT), which was uploaded to Github in 2016, but was still escaping detection by the first quarter of 2018, when a new, more feature-rich variant was discovered masquerading as an Apple audio driver. Among other capabilities, the Pascal-based ColdRoot can heist passwords from users' keychains and remotely control infected machines without detection. In the initial report of his findings, Patrick Wardle, Chief Research Officer for Digita Security, explained that the new ColdRoot RAT could start and kill processes on the breached system, spawn new remote-desktop sessions, take screen captures and assemble them into a live stream of the victim's desktop, and more.\
Searches in this Analytic Story leverage the capabilities of OSquery to address ColdRoot detection from several different angles, such as looking for the existence of associated files and processes, and monitoring for signs of an installed keylogger.

[analytic_story://Collection and Staging]
category = Adversary Tactics
last_updated = 2020-02-03
version = 1
references = ["https://attack.mitre.org/wiki/Collection", "https://attack.mitre.org/wiki/Technique/T1074"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Email files written outside of the Outlook directory - Rule", "ESCU - Email servers sending high volume traffic to hosts - Rule", "ESCU - Suspicious writes to System Volume Information - Rule", "ESCU - Detect Renamed 7-Zip - Rule", "ESCU - Detect Renamed WinRAR - Rule", "ESCU - Suspicious writes to windows Recycle Bin - Rule", "ESCU - Hosts receiving high volume of network traffic from email server - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Monitor for and investigate activities--such as suspicious writes to the Windows Recycling Bin or email servers sending high amounts of traffic to specific hosts, for example--that may indicate that an adversary is harvesting and exfiltrating sensitive data. 
narrative = A common adversary goal is to identify and exfiltrate data of value from a target organization. This data may include email conversations and addresses, confidential company information, links to network design/infrastructure, important dates, and so on.\
 Attacks are composed of three activities: identification, collection, and staging data for exfiltration. Identification typically involves scanning systems and observing user activity. Collection can involve the transfer of large amounts of data from various repositories. Staging/preparation includes moving data to a central location and compressing (and optionally encoding and/or encrypting) it. All of these activities provide opportunities for defenders to identify their presence. \
Use the searches to detect and monitor suspicious behavior related to these activities.

[analytic_story://Command And Control]
category = Adversary Tactics
last_updated = 2018-06-01
version = 1
references = ["https://attack.mitre.org/wiki/Command_and_Control", "https://searchsecurity.techtarget.com/feature/Command-and-control-servers-The-puppet-masters-that-govern-malware"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Detect Spike in blocked Outbound Traffic from your AWS - Rule", "ESCU - Clients Connecting to Multiple DNS Servers - Rule", "ESCU - Detect Long DNS TXT Record Response - Rule", "ESCU - Detection of DNS Tunnels - Rule", "ESCU - DNS Query Requests Resolved by Unauthorized DNS Servers - Rule", "ESCU - Detect Remote Access Software Usage File - Rule", "ESCU - Detect Remote Access Software Usage FileInfo - Rule", "ESCU - Detect Remote Access Software Usage Process - Rule", "ESCU - DNS Exfiltration Using Nslookup App - Rule", "ESCU - Excessive Usage of NSLOOKUP App - Rule", "ESCU - Windows Remote Access Software Hunt - Rule", "ESCU - Detect DGA domains using pretrained model in DSDL - Rule", "ESCU - Detect hosts connecting to dynamic domain providers - Rule", "ESCU - Detect Large Outbound ICMP Packets - Rule", "ESCU - Detect Remote Access Software Usage DNS - Rule", "ESCU - Detect Remote Access Software Usage Traffic - Rule", "ESCU - DNS Query Length Outliers - MLTK - Rule", "ESCU - DNS Query Length With High Standard Deviation - Rule", "ESCU - Excessive DNS Failures - Rule", "ESCU - Multiple Archive Files Http Post Traffic - Rule", "ESCU - Plain HTTP POST Exfiltrated Data - Rule", "ESCU - Prohibited Network Traffic Allowed - Rule", "ESCU - Protocol or Port Mismatch - Rule", "ESCU - TOR Traffic - Rule", "ESCU - Detect Remote Access Software Usage URL - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - AWS Network ACL Details from ID - Response Task", "ESCU - AWS Network Interface details via resourceId - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Detect and investigate tactics, techniques, and procedures leveraged by attackers to establish and operate Command And Control channels. Implants installed by attackers on compromised endpoints use these channels to receive instructions and send data back to the malicious operators.
narrative = Threat actors typically architect and implement an infrastructure to use in various ways during the course of their attack campaigns. In some cases, they leverage this infrastructure for scanning and performing reconnaissance activities. In others, they may use this infrastructure to launch actual attacks. One of the most important functions of this infrastructure is to establish servers that will communicate with implants on compromised endpoints. These servers establish a command and control channel that is used to proxy data between the compromised endpoint and the attacker. These channels relay commands from the attacker to the compromised endpoint and the output of those commands back to the attacker.\
Because this communication is so critical for an adversary, they often use techniques designed to hide the true nature of the communications. There are many different techniques used to establish and communicate over these channels. This Analytic Story provides searches that look for a variety of the techniques used for these channels, as well as indications that these channels are active, by examining logs associated with border control devices and network-access control lists.

[analytic_story://Compromised User Account]
category = Adversary Tactics
last_updated = 2023-01-19
version = 1
references = ["https://www.proofpoint.com/us/threat-reference/compromised-account"]
maintainers = [{"company": "Bhavin Patel, Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - PingID Mismatch Auth Source and Verification Response - Rule", "ESCU - PingID Multiple Failed MFA Requests For User - Rule", "ESCU - PingID New MFA Method After Credential Reset - Rule", "ESCU - PingID New MFA Method Registered For User - Rule", "ESCU - Abnormally High Number Of Cloud Infrastructure API Calls - Rule", "ESCU - ASL AWS Concurrent Sessions From Different Ips - Rule", "ESCU - ASL AWS Password Policy Changes - Rule", "ESCU - AWS Concurrent Sessions From Different Ips - Rule", "ESCU - AWS Console Login Failed During MFA Challenge - Rule", "ESCU - AWS High Number Of Failed Authentications For User - Rule", "ESCU - AWS High Number Of Failed Authentications From Ip - Rule", "ESCU - AWS Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - AWS Password Policy Changes - Rule", "ESCU - AWS Successful Console Authentication From Multiple IPs - Rule", "ESCU - Azure AD Concurrent Sessions From Different Ips - Rule", "ESCU - Azure AD High Number Of Failed Authentications For User - Rule", "ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule", "ESCU - Azure AD New MFA Method Registered For User - Rule", "ESCU - Azure AD Successful Authentication From Different Ips - Rule", "ESCU - Detect AWS Console Login by User from New City - Rule", "ESCU - Detect AWS Console Login by User from New Country - Rule", "ESCU - Detect AWS Console Login by User from New Region - Rule"]
description = Monitor for activities and techniques associated with Compromised User Account attacks.
narrative = Compromised User Account occurs when cybercriminals gain unauthorized access to accounts by using different techniques like brute force, social engineering, phishing & spear phishing, credential stuffing, etc. By posing as the real user, cyber-criminals can change account details, send out phishing emails, steal financial information or sensitive data, or use any stolen information to access further accounts within the organization. This analytic story groups detections that can help security operations teams identify the potential signs of Compromised User Accounts.

[analytic_story://Confluence Data Center and Confluence Server Vulnerabilities]
category = Adversary Tactics
last_updated = 2024-01-22
version = 1
references = ["https://confluence.atlassian.com/security/cve-2023-22527-rce-remote-code-execution-vulnerability-in-confluence-data-center-and-confluence-server-1333990257.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Confluence Data Center and Server Privilege Escalation - Rule", "ESCU - Confluence Pre-Auth RCE via OGNL Injection CVE-2023-22527 - Rule", "ESCU - Confluence Unauthenticated Remote Code Execution CVE-2022-26134 - Rule"]
description = The following analytic story covers use cases for detecting and investigating potential attacks against Confluence Data Center and Confluence Server.
narrative = The analytic story of Confluence Data Center and Confluence Server encompasses a comprehensive approach to safeguarding these platforms from a variety of threats. By leveraging the analytics created in the project, security teams are equipped to detect, investigate, and respond to potential attacks that target Confluence environments.

[analytic_story://ConnectWise ScreenConnect Vulnerabilities]
category = Adversary Tactics
last_updated = 2024-02-21
version = 1
references = ["https://www.huntress.com/blog/a-catastrophe-for-control-understanding-the-screenconnect-authentication-bypass", "https://www.huntress.com/blog/detection-guidance-for-connectwise-cwe-288-2", "https://www.connectwise.com/company/trust/security-bulletins/connectwise-screenconnect-23.9.8"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - ConnectWise ScreenConnect Path Traversal - Rule", "ESCU - ConnectWise ScreenConnect Path Traversal Windows SACL - Rule", "ESCU - ConnectWise ScreenConnect Authentication Bypass - Rule", "ESCU - Nginx ConnectWise ScreenConnect Authentication Bypass - Rule"]
description = This analytic story provides a comprehensive overview of the ConnectWise ScreenConnect vulnerabilities.
narrative = The following analytic story includes content for recently disclosed CWE-288 Authentication Bypass and CWE-22 Path Traversal. The vulnerabilities, identified as critical with CVSS scores of 10 and 9.8, respectively, enable unauthorized users to bypass authentication and perform path traversal attacks on affected ScreenConnect instances. The analytic story includes detection analytics for both vulnerabilities, which are crucial for identifying and responding to active exploitation in environments running affected versions of ScreenConnect (23.9.7 and prior). It is recommended to update to version 23.9.8 or above immediately to remediate the issues, as detailed in the ConnectWise security advisory and further analyzed by Huntress researchers. The analytic story also includes guidance on how to implement the detection analytics, known false positives, and references to additional resources for further analysis and remediation.

[analytic_story://Credential Dumping]
category = Adversary Tactics
last_updated = 2020-02-04
version = 3
references = ["https://attack.mitre.org/wiki/Technique/T1003", "https://cyberwardog.blogspot.com/2017/03/chronicles-of-threat-hunter-hunting-for.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Dump LSASS via procdump Rename - Rule", "ESCU - Unsigned Image Loaded by LSASS - Rule", "ESCU - Access LSASS Memory for Dump Creation - Rule", "ESCU - Attempted Credential Dump From Registry via Reg exe - Rule", "ESCU - Create Remote Thread into LSASS - Rule", "ESCU - Creation of lsass Dump with Taskmgr - Rule", "ESCU - Creation of Shadow Copy - Rule", "ESCU - Creation of Shadow Copy with wmic and powershell - Rule", "ESCU - Credential Dumping via Copy Command from Shadow Copy - Rule", "ESCU - Credential Dumping via Symlink to Shadow Copy - Rule", "ESCU - Detect Copy of ShadowCopy with Script Block Logging - Rule", "ESCU - Detect Credential Dumping through LSASS access - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Dump LSASS via procdump - Rule", "ESCU - Enable WDigest UseLogonCredential Registry - Rule", "ESCU - Esentutl SAM Copy - Rule", "ESCU - Extraction of Registry Hives - Rule", "ESCU - Ntdsutil Export NTDS - Rule", "ESCU - Potential password in username - Rule", "ESCU - SAM Database File Access Attempt - Rule", "ESCU - SecretDumps Offline NTDS Dumping Tool - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Windows AD Replication Request Initiated by User Account - Rule", "ESCU - Windows AD Replication Request Initiated from Unsanctioned Location - Rule", "ESCU - Windows Credential Dumping LSASS Memory Createdump - Rule", "ESCU - Windows Hunting System Account Targeting Lsass - Rule", "ESCU - Windows Mimikatz Binary Execution - Rule", "ESCU - Windows Non-System Account Targeting Lsass - Rule", "ESCU - Windows Possible Credential Dumping - Rule", "ESCU - Investigate Failed Logins for Multiple Destinations - Response Task", "ESCU - Investigate Pass the Hash Attempts - Response Task", "ESCU - Investigate Pass the Ticket Attempts - Response Task", "ESCU - Investigate Previous Unseen User - Response Task"]
description = Uncover activity consistent with credential dumping, a technique wherein attackers compromise systems and attempt to obtain and exfiltrate passwords. The threat actors use these pilfered credentials to further escalate privileges and spread throughout a target environment. The included searches in this Analytic Story are designed to identify attempts to credential dumping.
narrative = Credential dumping&#151;gathering credentials from a target system, often hashed or encrypted&#151;is a common attack technique. Even though the credentials may not be in plain text, an attacker can still exfiltrate the data and set to cracking it offline, on their own systems. The threat actors target a variety of sources to extract them, including the Security Accounts Manager (SAM), Local Security Authority (LSA), NTDS from Domain Controllers, or the Group Policy Preference (GPP) files.\
Once attackers obtain valid credentials, they use them to move throughout a target network with ease, discovering new systems and identifying assets of interest. Credentials obtained in this manner typically include those of privileged users, which may provide access to more sensitive information and system operations.\
The detection searches in this Analytic Story monitor access to the Local Security Authority Subsystem Service (LSASS) process, the usage of shadowcopies for credential dumping and some other techniques for credential dumping.

[analytic_story://CVE-2022-40684 Fortinet Appliance Auth bypass]
category = Adversary Tactics
last_updated = 2022-10-14
version = 1
references = ["https://www.wordfence.com/blog/2022/10/threat-advisory-cve-2022-40684-fortinet-appliance-auth-bypass/", "https://www.horizon3.ai/fortios-fortiproxy-and-fortiswitchmanager-authentication-bypass-technical-deep-dive-cve-2022-40684/", "https://github.com/horizon3ai/CVE-2022-40684", "https://attackerkb.com/topics/QWOxGIKkGx/cve-2022-40684/rapid7-analysis", "https://www.greynoise.io/blog/fortios-authentication-bypass"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Fortinet Appliance Auth bypass - Rule"]
description = Fortinet recently patched a critical authentication bypass vulnerability in their FortiOS, FortiProxy, and FortiSwitchManager projects CVE-2022-40684.
narrative = FortiOS exposes a management web portal that allows a user configure the system. Additionally, a user can SSH into the system which exposes a locked down CLI interface. Any HTTP requests to the management interface of the system that match the conditions above should be cause for concern. An attacker can use this vulnerability to do just about anything they want to the vulnerable system. This includes changing network configurations, adding new users, and initiating packet captures. Note that this is not the only way to exploit this vulnerability and there may be other sets of conditions that work. For instance, a modified version of this exploit uses the User-Agent Node.js. This exploit seems to follow a trend among recently discovered enterprise software vulnerabilities where HTTP headers are improperly validated or overly trusted. (ref Horizon3.ai)

[analytic_story://CVE-2023-21716 Word RTF Heap Corruption]
category = Adversary Tactics
last_updated = 2023-03-10
version = 1
references = ["https://www.bleepingcomputer.com/news/security/proof-of-concept-released-for-critical-microsoft-word-rce-bug/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Office Application Drop Executable - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Winword Spawning Cmd - Rule", "ESCU - Winword Spawning PowerShell - Rule", "ESCU - Winword Spawning Windows Script Host - Rule"]
description = A proof-of-concept for CVE-2023-21716, a critical vulnerability in Microsoft Word that allows remote code execution utilizing a heap corruption in rich text files.
narrative = This analytic story covers content that will assist organizations in identifying potential RTF RCE abuse on endpoints. The vulnerability was assigned a 9.8 out of 10 severity score, with Microsoft addressing it in the February Patch Tuesday security updates along with a couple of workarounds. Security researcher Joshua Drake last year discovered the vulnerability in Microsoft Office''s "wwlib.dll" and sent Microsoft a technical advisory containing proof-of-concept (PoC) code showing the issue is exploitable. A remote attacker could potentially take advantage of the issue to execute code with the same privileges as the victim that opens a malicious .RTF document. Delivering the malicious file to a victim can be as easy as an attachment to an email, although plenty of other methods exist. Microsoft warns that users don''t have to open a malicious RTF document and simply loading the file in the Preview Pane is enough for the compromise to start. (BleepingComputer, 2023)

[analytic_story://CVE-2023-22515 Privilege Escalation Vulnerability Confluence Data Center and Server]
category = Adversary Tactics
last_updated = 2023-10-04
version = 1
references = ["https://confluence.atlassian.com/security/cve-2023-22515-privilege-escalation-vulnerability-in-confluence-data-center-and-server-1295682276.html", "https://www.rapid7.com/blog/post/2023/10/04/etr-cve-2023-22515-zero-day-privilege-escalation-in-confluence-server-and-data-center/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Confluence CVE-2023-22515 Trigger Vulnerability - Rule", "ESCU - Confluence Data Center and Server Privilege Escalation - Rule", "ESCU - Web Remote ShellServlet Access - Rule"]
description = On October 4, 2023, Atlassian disclosed a critical privilege escalation vulnerability, CVE-2023-22515, affecting on-premises instances of Confluence Server and Confluence Data Center. This flaw might allow external attackers to exploit accessible Confluence instances, creating unauthorized Confluence administrator accounts. Indicators suggest the vulnerability is remotely exploitable. The affected versions range from 8.0.0 to 8.5.1, but versions prior to 8.0.0 and Atlassian Cloud sites are unaffected. Atlassian advises customers to update to a fixed version or implement mitigation strategies. Indicators of compromise (IoCs) and mitigation steps, such as blocking access to /setup/* endpoints, are provided.
narrative = Upon Atlassian's disclosure of CVE-2023-22515, there's an immediate need to assess the threat landscape of on-premises Confluence installations. As the vulnerability affects privilege escalation and may be exploited remotely, SIEM solutions should be poised to detect potential threats.\
By monitoring for specific indicators of compromise, security teams can get ahead of any potential breaches. Key indicators include unexpected members in the 'confluence-administrator' group, newly created user accounts, and specific HTTP requests to /setup/*.action endpoints. Any unusual spikes or patterns associated with these indicators might signify an ongoing or attempted exploitation. \
Furthermore, an audit trail of past logs is essential. Analyzing older logs might uncover any unnoticed exploitation, allowing for a post-incident analysis and ensuring affected systems are patched or isolated. An alert mechanism should be established for any access or changes related to /setup/* endpoints. \
In parallel, updating the affected Confluence Server and Data Center versions to the fixed releases is paramount. If immediate updates aren't feasible, interim mitigation measures, such as blocking external network access to /setup/*, should be implemented, and logs around this activity should be monitored.

[analytic_story://CVE-2023-23397 Outlook Elevation of Privilege]
category = Adversary Tactics
last_updated = 2023-03-15
version = 1
references = ["https://twitter.com/ACEResponder/status/1636116096506818562?s=20", "https://twitter.com/domchell/status/1635999068282408962?s=20", "https://msrc.microsoft.com/blog/2023/03/microsoft-mitigates-outlook-elevation-of-privilege-vulnerability/", "https://www.pwndefend.com/2023/03/15/the-long-game-persistent-hash-theft/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Rundll32 WebDAV Request - Rule", "ESCU - Windows Rundll32 WebDav With Network Connection - Rule"]
description = Microsoft has released CVE-2023-23397 to address the critical elevation of privilege (EoP) vulnerability affecting Microsoft Outlook for Windows.
narrative = Microsoft Threat Intelligence discovered limited, targeted abuse of a vulnerability in Microsoft Outlook for Windows that allows for new technology LAN manager (NTLM) credential theft. Microsoft has released CVE-2023-23397 to address the critical elevation of privilege (EoP) vulnerability affecting Microsoft Outlook for Windows. We strongly recommend all customers update Microsoft Outlook for Windows to remain secure.\ CVE-2023-23397 is a critical EoP vulnerability in Microsoft Outlook that is triggered when an attacker sends a message with an extended MAPI property with a UNC path to an SMB (TCP 445) share on a threat actor-controlled server. No user interaction is required.\ The connection to the remote SMB server sends the user''s NTLM negotiation message, which the attacker can then relay for authentication against other systems that support NTLM authentication. Online services such as Microsoft 365 do not support NTLM authentication and are not vulnerable to being attacked by these messages. (2023, Microsoft)

[analytic_story://CVE-2023-36884 Office and Windows HTML RCE Vulnerability]
category = Adversary Tactics
last_updated = 2023-07-11
version = 1
references = ["https://gist.github.com/MHaggis/22ad19081300493e70ce0b873e98b2d0", "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36884", "https://www.bleepingcomputer.com/news/microsoft/microsoft-july-2023-patch-tuesday-warns-of-6-zero-days-132-flaws/", "https://www.microsoft.com/en-us/security/blog/2023/07/11/storm-0978-attacks-reveal-financial-and-espionage-motives/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - MSHTML Module Load in Office Product - Rule", "ESCU - Office Document Spawned Child Process To Download - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Office Product Spawning BITSAdmin - Rule", "ESCU - Office Product Spawning CertUtil - Rule", "ESCU - Office Product Spawning MSHTA - Rule", "ESCU - Office Product Spawning Rundll32 with no DLL - Rule", "ESCU - Office Product Spawning Windows Script Host - Rule", "ESCU - Office Product Spawning Wmic - Rule"]
description = CVE-2023-36884 is an unpatched zero-day vulnerability affecting Windows and Microsoft Office products. The vulnerability allows for remote code execution through specially crafted Microsoft Office documents, enabling an attacker to operate in the context of the victim. As of now, there are no security updates available. However, users of Microsoft Defender for Office and the "Block all Office applications from creating child processes" Attack Surface Reduction Rule are safeguarded against this exploit. For other users, temporary mitigation can be achieved by adding specific application names to a designated registry key.
narrative = CVE-2023-36884 is a serious security vulnerability that affects a range of Microsoft Office products and Windows systems. It is a zero-day flaw, meaning it was already being exploited before Microsoft became aware of it or had a chance to develop a patch. \
An attacker exploiting this vulnerability would create a Microsoft Office document containing malicious code. This document, when opened by the victim, allows for remote code execution, giving the attacker the ability to run their own code on the victim's machine. This poses a significant risk as the attacker could perform actions like data theft, system damage, or creating backdoors for future access. \
Currently, there is no security patch available from Microsoft, which makes the issue more critical. Microsoft is working on investigating these vulnerabilities and will likely provide a security update either through their monthly release cycle or an out-of-cycle update, based on the urgency. \
In the meantime, users of Microsoft Defender for Office and those utilizing the "Block all Office applications from creating child processes" Attack Surface Reduction Rule are protected from attempts to exploit this vulnerability. This is because these protections add an extra layer of security, blocking the malicious code from executing. \
For users who are not using these protections, Microsoft recommends a workaround by adding specific application names to a particular Windows registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION) with data set as "1". This action aims to mitigate the risk until a permanent fix is available. \
The disclosure of this flaw involved multiple entities including Microsoft Threat Intelligence, Vlad Stolyarov, Clement Lecigne and Bahare Sabouri from Google's Threat Analysis Group (TAG), Paul Rascagneres and Tom Lancaster from Volexity, and the Microsoft Office Product Group Security Team. This collective effort indicates the severity and importance of addressing this issue.

[analytic_story://Cyclops Blink]
category = Malware
last_updated = 2024-03-14
version = 2
references = ["https://www.ncsc.gov.uk/files/Cyclops-Blink-Malware-Analysis-Report.pdf", "https://www.trendmicro.com/en_us/research/22/c/cyclops-blink-sets-sights-on-asus-routers--.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Linux Iptables Firewall Modification - Rule", "ESCU - Linux Kworker Process In Writable Process Path - Rule", "ESCU - Linux Stdout Redirection To Dev Null File - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the cyclopsblink malware including firewall modification, spawning more process, botnet c2 communication, defense evasion and etc. Cyclops Blink is a Linux ELF executable compiled for 32-bit x86 and PowerPC architecture that has targeted several network devices. The complete list of targeted devices is unknown at this time, but WatchGuard FireBox has specifically been listed as a target. The modular malware consists of core components and modules that are deployed as child processes using the Linux API fork. At this point, four modules have been identified that download and upload files, gather system information and contain updating mechanisms for the malware itself. Additional modules can be downloaded and executed from the Command And Control (C2) server.
narrative = Adversaries may use this technique to maximize the impact on the target organization in operations where network wide availability interruption is the goal.

[analytic_story://DarkCrystal RAT]
category = Malware
last_updated = 2022-07-26
version = 1
references = ["https://www.mandiant.com/resources/analyzing-dark-crystal-rat-backdoor", "https://malpedia.caad.fkie.fraunhofer.de/details/win.dcrat"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Any Powershell DownloadFile - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Malicious PowerShell Process - Execution Policy Bypass - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Windows Command Shell DCRat ForkBomb Payload - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows Gather Victim Host Information Camera - Rule", "ESCU - Windows Gather Victim Network Info Through Ip Check Web Services - Rule", "ESCU - Windows High File Deletion Frequency - Rule", "ESCU - Windows Ingress Tool Transfer Using Explorer - Rule", "ESCU - Windows System LogOff Commandline - Rule", "ESCU - Windows System Reboot CommandLine - Rule", "ESCU - Windows System Shutdown CommandLine - Rule", "ESCU - Windows System Time Discovery W32tm Delay - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule", "ESCU - Winword Spawning Cmd - Rule", "ESCU - Winword Spawning PowerShell - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the DcRat malware including ddos, spawning more process, botnet c2 communication, defense evasion and etc. The DcRat malware is known commercial backdoor that was first released in 2018. This tool was sold in underground forum and known to be one of the cheapest commercial RATs. DcRat is modular and bespoke plugin framework make it a very flexible option, helpful for a range of nefearious uses.
narrative = Adversaries may use this technique to maximize the impact on the target organization in operations where network wide availability interruption is the goal.

[analytic_story://DarkGate Malware]
category = Adversary Tactics
last_updated = 2023-10-31
version = 1
references = ["https://github.security.telekom.com/2023/08/darkgate-loader.html", "https://redcanary.com/blog/intelligence-insights-october-2023"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Create local admin accounts using net exe - Rule", "ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Delete ShadowCopy With PowerShell - Rule", "ESCU - Deleting Of Net Users - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Regasm Spawning a Process - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Execution of File with Multiple Extensions - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - Powershell Remote Services Add TrustedHost - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Archive Collected Data via Rar - Rule", "ESCU - Windows AutoIt3 Execution - Rule", "ESCU - Windows CAB File on Disk - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Credentials from Password Stores Creation - Rule", "ESCU - Windows Credentials from Password Stores Deletion - Rule", "ESCU - Windows Credentials from Password Stores Query - Rule", "ESCU - Windows Indicator Removal Via Rmdir - Rule", "ESCU - Windows Modify Registry AuthenticationLevelOverride - Rule", "ESCU - Windows Modify Registry DisableRemoteDesktopAntiAlias - Rule", "ESCU - Windows Modify Registry DisableSecuritySettings - Rule", "ESCU - Windows Modify Registry DontShowUI - Rule", "ESCU - Windows Modify Registry ProxyEnable - Rule", "ESCU - Windows Modify Registry ProxyServer - Rule", "ESCU - Windows MSIExec Spawn WinDBG - Rule", "ESCU - Windows System Reboot CommandLine - Rule", "ESCU - Windows System Shutdown CommandLine - Rule", "ESCU - Windows WinDBG Spawning AutoIt3 - Rule"]
description = Telekom Security CTI has uncovered a new phishing-driven malware campaign distributing DarkGate malware. This campaign utilizes stolen email threads to trick users into downloading malicious payloads via hyperlinks. An initial false link to Emotet stirred the security community, but deeper analysis confirmed its true identity as DarkGate, with characteristics like AutoIt scripts and a known command-and-control protocol. This report by Fabian Marquardt details the intricate infection mechanisms, including MSI and VBS file deliveries, sophisticated evasion techniques, and a robust configuration extraction method surpassing current standards. The single developer behind DarkGate, active on cybercrime forums, has shifted the malware's use from private to a rent-out model, implying an expected rise in its deployment. Researchers have also developed a decryption technique for the DarkGate malware, which aids in static analysis and detection, though it requires careful validation to avoid false positives.
narrative = Telekom Security CTi has recently put a spotlight on the proliferation of DarkGate malware via a sophisticated malspam campaign, initially mistaken for the notorious Emotet malware. The campaign smartly manipulates stolen email conversations, embedding hyperlinks that, once clicked, activate a malware download. Fabian Marquardt's analysis traces the infection's footprint, revealing a dual delivery mechanism through MSI and VBS files. These files, cloaked in legitimate wrappers or obscured with junk code, ultimately download the malware via embedded scripts. \
Marquardt delves into the AutoIt script-based infection, uncovering the calculated use of compiled scripts and base64-encoded data to disguise the execution of malicious shellcode. The subsequent stages of infection exhibit the malware's capability to evade detection, leveraging memory allocation techniques to bypass security measures. Marquardt also explores the loader's function, which decrypts further malicious payloads by interacting with the script's encoded components. \
The analytical narrative captures a cross-section of the cybersecurity landscape, reflecting the shift in DarkGate's operational strategy from exclusive use by the developer to a broader dissemination through a Malware-as-a-Service (MaaS) model. This transition suggests an anticipated escalation in DarkGate-related attacks. \
Significantly, the report contributes to cybersecurity defenses by outlining a more effective method for extracting malware configurations, providing the community with the means to anticipate and mitigate the evolving threats posed by this pernicious malware. With the insights gained, researchers and security professionals are better equipped to adapt their strategies, constructing more robust defenses against the sophisticated tactics employed by DarkGate and similar malware strains.

[analytic_story://DarkSide Ransomware]
category = Malware
last_updated = 2021-05-12
version = 1
references = ["https://www.splunk.com/en_us/blog/security/the-darkside-of-the-ransomware-pipeline.htmlbig-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/", "https://www.mandiant.com/resources/shining-a-light-on-darkside-ransomware-operations"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Attempted Credential Dump From Registry via Reg exe - Rule", "ESCU - BITSAdmin Download File - Rule", "ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule", "ESCU - CMLUA Or CMSTPLUA UAC Bypass - Rule", "ESCU - Cobalt Strike Named Pipes - Rule", "ESCU - Delete ShadowCopy With PowerShell - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect RClone Command-Line Usage - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Detect Renamed RClone - Rule", "ESCU - Extraction of Registry Hives - Rule", "ESCU - Ransomware Notes bulk creation - Rule", "ESCU - SLUI RunAs Elevated - Rule", "ESCU - SLUI Spawning a Process - Rule", "ESCU - Windows Possible Credential Dumping - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the DarkSide Ransomware
narrative = This story addresses Darkside ransomware. This ransomware payload has many similarities to common ransomware however there are certain items particular to it. The creation of a .TXT log that shows every item being encrypted as well as the creation of ransomware notes and files adding a machine ID created based on CRC32 checksum algorithm. This ransomware payload leaves machines in minimal operation level,enough to browse the attackers websites. A customized URI with leaked information is presented to each victim.This is the ransomware payload that shut down the Colonial pipeline. The story is composed of several detection searches covering similar items to other ransomware payloads and those particular to Darkside payload.

[analytic_story://Data Destruction]
category = Malware
last_updated = 2023-04-06
version = 1
references = ["https://attack.mitre.org/techniques/T1485/", "https://researchcenter.paloaltonetworks.com/2018/09/unit42-xbash-combines-botnet-ransomware-coinmining-worm-targets-linux-windows/", "https://www.picussecurity.com/blog/a-brief-history-and-further-technical-analysis-of-sodinokibi-ransomware", "https://www.splunk.com/en_us/blog/security/threat-advisory-strt-ta02-destructive-software.html", "https://www.splunk.com/en_us/blog/security/detecting-hermeticwiper.html", "https://www.splunk.com/en_us/blog/security/threat-update-doublezero-destructor.html", "https://www.splunk.com/en_us/blog/security/threat-update-caddywiper.html", "https://www.splunk.com/en_us/blog/security/strt-ta03-cpe-destructive-software.html", "https://www.splunk.com/en_us/blog/security/threat-update-cyclopsblink.html", "https://www.splunk.com/en_us/blog/security/threat-update-acidrain-wiper.html", "https://www.splunk.com/en_us/blog/security/threat-update-industroyer2.html", "https://www.splunk.com/en_us/blog/security/threat-advisory-swiftslicer-wiper-strt-ta03.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Email Attachments With Lots Of Spaces - Rule", "ESCU - Suspicious Email Attachment Extensions - Rule", "ESCU - Active Setup Registry Autostart - Rule", "ESCU - Add or Set Windows Defender Exclusion - Rule", "ESCU - AdsiSearcher Account Discovery - Rule", "ESCU - Any Powershell DownloadFile - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - Attempt To Stop Security Service - Rule", "ESCU - Attempted Credential Dump From Registry via Reg exe - Rule", "ESCU - Change Default File Association - Rule", "ESCU - Child Processes of Spoolsv exe - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Detect Empire with PowerShell Script Block Logging - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - ETW Registry Disabled - Rule", "ESCU - Excessive File Deletion In WinDefender Folder - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Kerberoasting spn request with RC4 encryption - Rule", "ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux Data Destruction Command - Rule", "ESCU - Linux DD File Overwrite - Rule", "ESCU - Linux Deleting Critical Directory Using RM Command - Rule", "ESCU - Linux Deletion Of Cron Jobs - Rule", "ESCU - Linux Deletion Of Init Daemon Script - Rule", "ESCU - Linux Deletion Of Services - Rule", "ESCU - Linux Disable Services - Rule", "ESCU - Linux Hardware Addition SwapOff - Rule", "ESCU - Linux High Frequency Of File Deletion In Boot Folder - Rule", "ESCU - Linux High Frequency Of File Deletion In Etc Folder - Rule", "ESCU - Linux Impair Defenses Process Kill - Rule", "ESCU - Linux Indicator Removal Clear Cache - Rule", "ESCU - Linux Indicator Removal Service File Deletion - Rule", "ESCU - Linux Java Spawning Shell - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Shred Overwrite Command - Rule", "ESCU - Linux Stdout Redirection To Dev Null File - Rule", "ESCU - Linux Stop Services - Rule", "ESCU - Linux System Network Discovery - Rule", "ESCU - Linux System Reboot Via System Request Key - Rule", "ESCU - Linux Unix Shell Enable All SysRq Functions - Rule", "ESCU - Logon Script Event Trigger Execution - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Malicious PowerShell Process With Obfuscation Techniques - Rule", "ESCU - MSI Module Loaded by Non-System Binary - Rule", "ESCU - Overwriting Accessibility Binaries - Rule", "ESCU - Ping Sleep Batch Command - Rule", "ESCU - Possible Lateral Movement PowerShell Spawn - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - PowerShell Domain Enumeration - Rule", "ESCU - Powershell Enable SMB1Protocol Feature - Rule", "ESCU - Powershell Execute COM Object - Rule", "ESCU - Powershell Fileless Process Injection via GetProcAddress - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule", "ESCU - Powershell Processing Stream Of Data - Rule", "ESCU - Powershell Remove Windows Defender Directory - Rule", "ESCU - Powershell Using memory As Backing Store - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Print Processor Registry Autostart - Rule", "ESCU - Process Deleting Its Process File Path - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - Registry Keys Used For Privilege Escalation - Rule", "ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule", "ESCU - Runas Execution in CommandLine - Rule", "ESCU - Schtasks Run Task On Demand - Rule", "ESCU - Screensaver Event Trigger Execution - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Suspicious Process DNS Query Known Abuse Web Services - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Process With Discord DNS Query - Rule", "ESCU - Time Provider Persistence Registry - Rule", "ESCU - Unloading AMSI via Reflection - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows Data Destruction Recursive Exec Files Deletion - Rule", "ESCU - Windows Deleted Registry By A Non Critical Process File Path - Rule", "ESCU - Windows Disable Memory Crash Dump - Rule", "ESCU - Windows DotNet Binary in Non Standard Path - Rule", "ESCU - Windows File Without Extension In Critical Folder - Rule", "ESCU - Windows Hidden Schedule Task Settings - Rule", "ESCU - Windows High File Deletion Frequency - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule", "ESCU - Windows Linked Policies In ADSI Discovery - Rule", "ESCU - Windows Modify Show Compress Color And Info Tip Registry - Rule", "ESCU - Windows NirSoft AdvancedRun - Rule", "ESCU - Windows NirSoft Utilities - Rule", "ESCU - Windows Processes Killed By Industroyer2 Malware - Rule", "ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - Windows Root Domain linked policies Discovery - Rule", "ESCU - Windows Terminating Lsass Process - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule", "ESCU - WMI Recon Running Process Or Services - Rule", "ESCU - Wscript Or Cscript Suspicious Child Process - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the data destruction, including deleting files, overwriting files, wiping disk and unrecoverable file encryption. This analytic story may cover several known activities related to malware implants used in geo-political war to wipe disks or files to interrupt the network-wide operation of a targeted organization. Analytics can detect the behavior of "DoubleZero Destructor", "CaddyWiper", "AcidRain", "AwfulShred", "Hermetic Wiper", "Swift Slicer", "Whisper Gate" and many more.
narrative = Adversaries may partially or completely overwrite the contents of a storage device rendering the data irrecoverable through the storage interface or using 3rd party drivers to directly access disk content like Master Boot Record to wipe it. Some of these attacks were seen in geo-political war to impair the operation of targeted organizations or to interrupt network-wide services.

[analytic_story://Data Exfiltration]
category = Adversary Tactics
last_updated = 2023-05-17
version = 2
references = ["https://attack.mitre.org/tactics/TA0010/", "https://bleemb.medium.com/data-exfiltration-with-native-aws-s3-features-c94ae4d13436", "https://labs.nettitude.com/blog/how-to-exfiltrate-aws-ec2-data/", "https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-277a"]
maintainers = [{"company": "Shannon Davis, Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - AWS AMI Attribute Modification for Exfiltration - Rule", "ESCU - AWS Disable Bucket Versioning - Rule", "ESCU - AWS EC2 Snapshot Shared Externally - Rule", "ESCU - AWS Exfiltration via Anomalous GetObject API Activity - Rule", "ESCU - AWS Exfiltration via Batch Service - Rule", "ESCU - AWS Exfiltration via Bucket Replication - Rule", "ESCU - AWS Exfiltration via DataSync Task - Rule", "ESCU - AWS Exfiltration via EC2 Snapshot - Rule", "ESCU - AWS S3 Exfiltration Behavior Identified - Rule", "ESCU - Gdrive suspicious file sharing - Rule", "ESCU - O365 PST export alert - Rule", "ESCU - O365 Suspicious Admin Email Forwarding - Rule", "ESCU - O365 Suspicious User Email Forwarding - Rule", "ESCU - Detect Certipy File Modifications - Rule", "ESCU - DNS Exfiltration Using Nslookup App - Rule", "ESCU - Excessive Usage of NSLOOKUP App - Rule", "ESCU - Linux Curl Upload File - Rule", "ESCU - Mailsniper Invoke functions - Rule", "ESCU - Detect DGA domains using pretrained model in DSDL - Rule", "ESCU - Detect SNICat SNI Exfiltration - Rule", "ESCU - High Volume of Bytes Out to Url - Rule", "ESCU - Multiple Archive Files Http Post Traffic - Rule", "ESCU - Plain HTTP POST Exfiltrated Data - Rule", "ESCU - Get Notable History - Response Task"]
description = Data exfiltration refers to the unauthorized transfer or extraction of sensitive or valuable data from a compromised system or network during a cyber attack. It is a critical phase in many targeted attacks, where adversaries aim to steal confidential information, such as intellectual property, financial records, personal data, or trade secrets.
narrative = This Analytic Story supports you to detect Tactics, Techniques and Procedures (TTPs) leveraged by adversaries to exfiltrate data from your environments. Exfiltration comes in many flavors and its done differently on every environment. Adversaries can collect data over encrypted or non-encrypted channels.  They can utilise Command And Control channels that are already in place to exfiltrate data.  They can use both standard data transfer protocols such as FTP, SCP, etc to exfiltrate data.  Or they can use non-standard protocols such as DNS, ICMP, etc with specially crafted fields to try and circumvent security technologies in place.\
Techniques for getting data out of a target network typically include transferring it over their command and control channel or an alternate channel and may also include putting size limits on the transmission. In context of the cloud, this refers to the unauthorized transfer or extraction of sensitive data from cloud-based systems or services. It involves the compromise of cloud infrastructure or accounts to gain access to valuable information stored in the cloud environment. Attackers may employ various techniques, such as exploiting vulnerabilities, stealing login credentials, or using malicious code to exfiltrate data from cloud repositories or services without detection.

[analytic_story://Data Protection]
category = Abuse
last_updated = 2017-09-14
version = 1
references = ["https://www.cisecurity.org/controls/data-protection/", "https://www.sans.org/reading-room/whitepapers/dns/splunk-detect-dns-tunneling-37022", "https://umbrella.cisco.com/blog/2013/04/15/on-the-trail-of-malicious-dynamic-dns-domains/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect USB device insertion - Rule", "ESCU - Detection of DNS Tunnels - Rule", "ESCU - Detect hosts connecting to dynamic domain providers - Rule", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Fortify your data-protection arsenal--while continuing to ensure data confidentiality and integrity--with searches that monitor for and help you investigate possible signs of data exfiltration.
narrative = Attackers can leverage a variety of resources to compromise or exfiltrate enterprise data. Common exfiltration techniques include remote-access channels via low-risk, high-payoff active-collections operations and close-access operations using insiders and removable media. While this Analytic Story is not a comprehensive listing of all the methods by which attackers can exfiltrate data, it provides a useful starting point.

[analytic_story://Deobfuscate-Decode Files or Information]
category = Adversary Tactics
last_updated = 2021-03-24
version = 1
references = ["https://attack.mitre.org/techniques/T1140/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - CertUtil With Decode Argument - Rule"]
description = Adversaries may use Obfuscated Files or Information to hide artifacts of an intrusion from analysis.
narrative = An example of obfuscated files is `Certutil.exe` usage to encode a portable executable to a certificate file, which is base64 encoded, to hide the originating file. There are many utilities cross-platform to encode using XOR, using compressed .cab files to hide contents and scripting languages that may perform similar native Windows tasks. Triaging an event related will require the capability to review related process events and file modifications. Using a tool such as CyberChef will assist with identifying the encoding that was used, and potentially assist with decoding the contents.

[analytic_story://AWS Cryptomining]
category = Cloud Security
last_updated = 2018-03-08
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Abnormally High AWS Instances Launched by User - Rule", "ESCU - Abnormally High AWS Instances Launched by User - MLTK - Rule", "ESCU - EC2 Instance Started In Previously Unseen Region - Rule", "ESCU - EC2 Instance Started With Previously Unseen AMI - Rule", "ESCU - EC2 Instance Started With Previously Unseen Instance Type - Rule", "ESCU - EC2 Instance Started With Previously Unseen User - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get EC2 Launch Details - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Investigate AWS activities via region name - Response Task"]
description = Monitor your AWS EC2 instances for activities related to cryptojacking/cryptomining. New instances that originate from previously unseen regions, users who launch abnormally high numbers of instances, or EC2 instances started by previously unseen users are just a few examples of potentially malicious behavior.
narrative = Cryptomining is an intentionally difficult, resource-intensive business. Its complexity was designed into the process to ensure that the number of blocks mined each day would remain steady. So, it's par for the course that ambitious, but unscrupulous, miners make amassing the computing power of large enterprises--a practice known as cryptojacking--a top priority. \
Cryptojacking has attracted an increasing amount of media attention since its explosion in popularity in the fall of 2017. The attacks have moved from in-browser exploits and mobile phones to enterprise cloud services, such as Amazon Web Services (AWS). It's difficult to determine exactly how widespread the practice has become, since bad actors continually evolve their ability to escape detection, including employing unlisted endpoints, moderating their CPU usage, and hiding the mining pool's IP address behind a free CDN. \
When malicious miners appropriate a cloud instance, often spinning up hundreds of new instances, the costs can become astronomical for the account holder. So, it is critically important to monitor your systems for suspicious activities that could indicate that your network has been infiltrated. \
This Analytic Story is focused on detecting suspicious new instances in your EC2 environment to help prevent such a disaster. It contains detection searches that will detect when a previously unused instance type or AMI is used. It also contains support searches to build lookup files to ensure proper execution of the detection searches.

[analytic_story://AWS Suspicious Provisioning Activities]
category = Cloud Security
last_updated = 2018-03-16
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - AWS Cloud Provisioning From Previously Unseen City - Rule", "ESCU - AWS Cloud Provisioning From Previously Unseen Country - Rule", "ESCU - AWS Cloud Provisioning From Previously Unseen IP Address - Rule", "ESCU - AWS Cloud Provisioning From Previously Unseen Region - Rule", "ESCU - AWS Investigate Security Hub alerts by dest - Response Task", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get All AWS Activity From City - Response Task", "ESCU - Get All AWS Activity From Country - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task", "ESCU - Get All AWS Activity From Region - Response Task"]
description = Monitor your AWS provisioning activities for behaviors originating from unfamiliar or unusual locations. These behaviors may indicate that malicious activities are occurring somewhere within your network.
narrative = Because most enterprise AWS activities originate from familiar geographic locations, monitoring for activity from unknown or unusual regions is an important security measure. This indicator can be especially useful in environments where it is impossible to add specific IPs to an allow list because they vary. \
This Analytic Story was designed to provide you with flexibility in the precision you employ in specifying legitimate geographic regions. It can be as specific as an IP address or a city, or as broad as a region (think state) or an entire country. By determining how precise you want your geographical locations to be and monitoring for new locations that haven't previously accessed your environment, you can detect adversaries as they begin to probe your environment. Since there are legitimate reasons for activities from unfamiliar locations, this is not a standalone indicator. Nevertheless, location can be a relevant piece of information that you may wish to investigate further.

[analytic_story://Common Phishing Frameworks]
category = Adversary Tactics
last_updated = 2019-04-29
version = 1
references = ["https://github.com/kgretzky/evilginx2", "https://attack.mitre.org/techniques/T1192/", "https://breakdev.org/evilginx-advanced-phishing-with-two-factor-authentication-bypass/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Splunk Research Team"}]
spec_version = 3
searches = ["ESCU - Detect DNS requests to Phishing Sites leveraging EvilGinx2 - Rule", "ESCU - Get Certificate logs for a domain - Response Task"]
description = Detect DNS and web requests to fake websites generated by the EvilGinx2 toolkit. These websites are designed to fool unwitting users who have clicked on a malicious link in a phishing email. 
narrative = As most people know, these emails use fraudulent domains, [email scraping](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), familiar contact names inserted as senders, and other tactics to lure targets into clicking a malicious link, opening an attachment with a [nefarious payload](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), or entering sensitive personal information that perpetrators may intercept. This attack technique requires a relatively low level of skill and allows adversaries to easily cast a wide net. Because phishing is a technique that relies on human psychology, you will never be able to eliminate this vulnerability 100%. But you can use automated detection to significantly reduce the risks.\
This Analytic Story focuses on detecting signs of MiTM attacks enabled by [EvilGinx2](https://github.com/kgretzky/evilginx2), a toolkit that sets up a transparent proxy between the targeted site and the user. In this way, the attacker is able to intercept credentials and two-factor identification tokens. It employs a proxy template to allow a registered domain to impersonate targeted sites, such as Linkedin, Amazon, Okta, Github, Twitter, Instagram, Reddit, Office 365, and others. It can even register SSL certificates and camouflage them via a URL shortener, making them difficult to detect. Searches in this story look for signs of MiTM attacks enabled by EvilGinx2.

[analytic_story://Container Implantation Monitoring and Investigation]
category = Cloud Security
last_updated = 2020-02-20
version = 1
references = ["https://github.com/splunk/cloud-datamodel-security-research"]
maintainers = [{"company": "Rico Valdez, Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = []
description = Use the searches in this story to monitor your Kubernetes registry repositories for upload, and deployment of potentially vulnerable, backdoor, or implanted containers. These searches provide information on source users, destination path, container names and repository names. The searches provide context to address Mitre T1525 which refers to container implantation upload to a company's repository either in Amazon Elastic Container Registry, Google Container Registry and Azure Container Registry.
narrative = Container Registrys provide a way for organizations to keep customized images of their development and infrastructure environment in private. However if these repositories are misconfigured or priviledge users credentials are compromise, attackers can potentially upload implanted containers which can be deployed across the organization. These searches allow operator to monitor who, when and what was uploaded to container registry.

[analytic_story://Host Redirection]
category = Abuse
last_updated = 2017-09-14
version = 1
references = ["https://blog.malwarebytes.com/cybercrime/2016/09/hosts-file-hijacks/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Clients Connecting to Multiple DNS Servers - Rule", "ESCU - DNS Query Requests Resolved by Unauthorized DNS Servers - Rule", "ESCU - Windows hosts file modification - Rule", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get Notable History - Response Task"]
description = Detect evidence of tactics used to redirect traffic from a host to a destination other than the one intended--potentially one that is part of an adversary's attack infrastructure. An example is redirecting communications regarding patches and updates or misleading users into visiting a malicious website.
narrative = Attackers will often attempt to manipulate client communications for nefarious purposes. In some cases, an attacker may endeavor to modify a local host file to redirect communications with resources (such as antivirus or system-update services) to prevent clients from receiving patches or updates. In other cases, an attacker might use this tactic to have the client connect to a site that looks like the intended site, but instead installs malware or collects information from the victim. Additionally, an attacker may redirect a victim in order to execute a MITM attack and observe communications.

[analytic_story://Kubernetes Sensitive Role Activity]
category = Cloud Security
last_updated = 2020-05-20
version = 1
references = ["https://www.splunk.com/en_us/blog/security/approaching-kubernetes-security-detecting-kubernetes-scan-with-splunk.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Kubernetes AWS detect most active service accounts by pod - Rule", "ESCU - Kubernetes AWS detect RBAC authorization by account - Rule", "ESCU - Kubernetes AWS detect sensitive role access - Rule", "ESCU - Kubernetes Azure active service accounts by pod namespace - Rule", "ESCU - Kubernetes Azure detect RBAC authorization by account - Rule", "ESCU - Kubernetes Azure detect sensitive role access - Rule", "ESCU - Kubernetes GCP detect most active service accounts by pod - Rule", "ESCU - Kubernetes GCP detect RBAC authorizations by account - Rule", "ESCU - Kubernetes GCP detect sensitive role access - Rule", "ESCU - Get Notable History - Response Task"]
description = This story addresses detection and response around Sensitive Role usage within a Kubernetes clusters against cluster resources and namespaces.
narrative = Kubernetes is the most used container orchestration platform, this orchestration platform contains sensitive roles within its architecture, specifically configmaps and secrets, if accessed by an attacker can lead to further compromise. These searches allow operator to detect suspicious requests against Kubernetes role activities

[analytic_story://Lateral Movement]
category = Adversary Tactics
last_updated = 2020-02-04
version = 2
references = ["https://www.fireeye.com/blog/executive-perspective/2015/08/malware_lateral_move.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task"]
description =  DEPRECATED IN FAVOR OF ACTIVE DIRECTORY LATERAL MOVEMENT. Detect and investigate tactics, techniques, and procedures around how attackers move laterally within the enterprise. Because lateral movement can expose the adversary to detection, it should be an important focus for security analysts.
narrative = Once attackers gain a foothold within an enterprise, they will seek to expand their accesses and leverage techniques that facilitate lateral movement. Attackers will often spend quite a bit of time and effort moving laterally. Because lateral movement renders an attacker the most vulnerable to detection, it's an excellent focus for detection and investigation. Indications of lateral movement can include the abuse of system utilities (such as `psexec.exe`), unauthorized use of remote desktop services, `file/admin$` shares, WMI, PowerShell, pass-the-hash, or the abuse of scheduled tasks. Organizations must be extra vigilant in detecting lateral movement techniques and look for suspicious activity in and around high-value strategic network assets, such as Active Directory, which are often considered the primary target or "crown jewels" to a persistent threat actor. An adversary can use lateral movement for multiple purposes, including remote execution of tools, pivoting to additional systems, obtaining access to specific information or files, access to additional credentials, exfiltrating data, or delivering a secondary effect. Adversaries may use legitimate credentials alongside inherent network and operating-system functionality to remotely connect to other systems and remain under the radar of network defenders. If there is evidence of lateral movement, it is imperative for analysts to collect evidence of the associated offending hosts. For example, an attacker might leverage host A to gain access to host B. From there, the attacker may try to move laterally to host C. In this example, the analyst should gather as much information as possible from all three hosts. It is also important to collect authentication logs for each host, to ensure that the offending accounts are well-documented. Analysts should account for all processes to ensure that the attackers did not install unauthorized software.

[analytic_story://Monitor Backup Solution]
category = Best Practices
last_updated = 2017-09-12
version = 1
references = ["https://www.carbonblack.com/2016/03/04/tracking-locky-ransomware-using-carbon-black/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Extended Period Without Successful Netbackup Backups - Rule", "ESCU - Unsuccessful Netbackup backups - Rule", "ESCU - All backup logs for host - Response Task", "ESCU - Get Notable History - Response Task"]
description = Address common concerns when monitoring your backup processes. These searches can help you reduce risks from ransomware, device theft, or denial of physical access to a host by backing up data on endpoints.
narrative = Having backups is a standard best practice that helps ensure continuity of business operations.  Having mature backup processes can also help you reduce the risks of many security-related incidents and streamline your response processes. The detection searches in this Analytic Story will help you identify systems that have backup failures, as well as systems that have not been backed up for an extended period of time. The story will also return the notable event history and all of the backup logs for an endpoint.

[analytic_story://Monitor for Unauthorized Software]
category = Best Practices
last_updated = 2017-09-15
version = 1
references = ["https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic-national-committee/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Prohibited Software On Endpoint - Rule", "ESCU - Attacker Tools On Endpoint - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Identify and investigate prohibited/unauthorized software or processes that may be concealing malicious behavior within your environment. 
narrative = It is critical to identify unauthorized software and processes running on enterprise endpoints and determine whether they are likely to be malicious. This Analytic Story requires the user to populate the Interesting Processes table within Enterprise Security with prohibited processes. An included support search will augment this data, adding information on processes thought to be malicious. This search requires data from endpoint detection-and-response solutions, endpoint data sources (such as Sysmon), or Windows Event Logs--assuming that the Active Directory administrator has enabled process tracking within the System Event Audit Logs.\
It is important to investigate any software identified as suspicious, in order to understand how it was installed or executed. Analyzing authentication logs or any historic notable events might elicit additional investigative leads of interest. For best results, schedule the search to run every two weeks. 

[analytic_story://Office 365 Detections]
category = Cloud Security
last_updated = 2020-12-16
version = 2
references = ["https://i.blackhat.com/USA-20/Thursday/us-20-Bienstock-My-Cloud-Is-APTs-Cloud-Investigating-And-Defending-Office-365.pdf", "https://attack.mitre.org/matrices/enterprise/cloud/office365/", "https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-120a"]
maintainers = [{"company": "Mauricio Velazco, Splunk", "email": "-", "name": "Patrick Bareiss"}]
spec_version = 3
searches = []
description = Monitor for activities and anomalies indicative of potential threats within Office 365 environments.
narrative = Office 365 (O365) is Microsoft's cloud-based suite of productivity tools, encompassing email, collaboration platforms, and office applications, all integrated with Azure Active Directory for identity and access management. Given the centralized storage of sensitive organizational data within O365 and its widespread adoption, it has become a focal point for cybersecurity efforts. The platform's complexity, combined with its ubiquity, makes it both a valuable asset and a prime target for potential threats. As O365's importance grows, it increasingly becomes a target for attackers seeking to exploit organizational data and systems. Security teams should prioritize monitoring O365 not just because of the sensitive data it often holds, but also due to the myriad ways the platform can be exploited. Understanding and monitoring O365's security landscape is crucial for organizations to detect, respond to, and mitigate potential threats in a timely manner.

[analytic_story://Spectre And Meltdown Vulnerabilities]
category = Vulnerability
last_updated = 2018-01-08
version = 1
references = ["https://meltdownattack.com/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Spectre and Meltdown Vulnerable Systems - Rule", "ESCU - Get Notable History - Response Task"]
description = Assess and mitigate your systems' vulnerability to Spectre and Meltdown exploitation with the searches in this Analytic Story.
narrative = Meltdown and Spectre exploit critical vulnerabilities in modern CPUs that allow unintended access to data in memory. This Analytic Story will help you identify the systems can be patched for these vulnerabilities, as well as those that still need to be patched.

[analytic_story://Suspicious AWS EC2 Activities]
category = Cloud Security
last_updated = 2018-02-09
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Abnormally High AWS Instances Launched by User - Rule", "ESCU - Abnormally High AWS Instances Launched by User - MLTK - Rule", "ESCU - Abnormally High AWS Instances Terminated by User - Rule", "ESCU - Abnormally High AWS Instances Terminated by User - MLTK - Rule", "ESCU - EC2 Instance Started In Previously Unseen Region - Rule", "ESCU - EC2 Instance Started With Previously Unseen User - Rule", "ESCU - AWS Investigate Security Hub alerts by dest - Response Task", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get EC2 Launch Details - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Investigate AWS activities via region name - Response Task"]
description = Use the searches in this Analytic Story to monitor your AWS EC2 instances for evidence of anomalous activity and suspicious behaviors, such as EC2 instances that originate from unusual locations or those launched by previously unseen users (among others). Included investigative searches will help you probe more deeply, when the information warrants it.
narrative = AWS CloudTrail is an AWS service that helps you enable governance, compliance, and risk auditing within your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail. It is crucial for a company to monitor events and actions taken in the AWS Console, AWS command-line interface, and AWS SDKs and APIs to ensure that your EC2 instances are not vulnerable to attacks. This Analytic Story identifies suspicious activities in your AWS EC2 instances and helps you respond and investigate those activities.

[analytic_story://Unusual AWS EC2 Modifications]
category = Cloud Security
last_updated = 2018-04-09
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - EC2 Instance Modified With Previously Unseen User - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get EC2 Instance Details by instanceId - Response Task", "ESCU - Get Notable History - Response Task"]
description = Identify unusual changes to your AWS EC2 instances that may indicate malicious activity. Modifications to your EC2 instances by previously unseen users is an example of an activity that may warrant further investigation.
narrative = A common attack technique is to infiltrate a cloud instance and make modifications. The adversary can then secure access to your infrastructure or hide their activities. So it's important to stay alert to changes that may indicate that your environment has been compromised. \
 Searches within this Analytic Story can help you detect the presence of a threat by monitoring for EC2 instances that have been created or changed--either by users that have never previously performed these activities or by known users who modify or create instances in a way that have not been done before. This story also provides investigative searches that help you go deeper once you detect suspicious behavior.

[analytic_story://Web Fraud Detection]
category = Abuse
last_updated = 2018-10-08
version = 1
references = ["https://www.fbi.gov/scams-and-safety/common-fraud-schemes/internet-fraud", "https://www.fbi.gov/news/stories/2017-internet-crime-report-released-050718"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Jim Apger"}]
spec_version = 3
searches = ["ESCU - Web Fraud - Account Harvesting - Rule", "ESCU - Web Fraud - Anomalous User Clickspeed - Rule", "ESCU - Web Fraud - Password Sharing Across Accounts - Rule", "ESCU - Get Emails From Specific Sender - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Web Session Information via session id - Response Task"]
description = Monitor your environment for activity consistent with common attack techniques bad actors use when attempting to compromise web servers or other web-related assets.
narrative = The Federal Bureau of Investigations (FBI) defines Internet fraud as the use of Internet services or software with Internet access to defraud victims or to otherwise take advantage of them. According to the Bureau, Internet crime schemes are used to steal millions of dollars each year from victims and continue to plague the Internet through various methods. The agency includes phishing scams, data breaches, Denial of Service (DOS) attacks, email account compromise, malware, spoofing, and ransomware in this category.\
These crimes are not the fraud itself, but rather the attack techniques commonly employed by fraudsters in their pursuit of data that enables them to commit malicious actssuch as obtaining and using stolen credit cards. They represent a serious problem that is steadily increasing and not likely to go away anytime soon.\
When developing a strategy for preventing fraud in your environment, its important to  look across all of your web services for evidence that attackers are abusing enterprise resources to enumerate systems, harvest data for secondary fraudulent activity, or abuse terms of service.This Analytic Story looks for evidence of common Internet attack techniques that could be indicative of web fraud in your environmentincluding account harvesting, anomalous user clickspeed, and password sharing across accounts, to name just a few.\
The account-harvesting search focuses on web pages used for user-account registration. It detects the creation of a large number of user accounts using the same email domain name, a type of activity frequently seen in advance of a fraud campaign.\
The anomalous clickspeed search looks for users who are moving through your website at a faster-than-normal speed or with a perfect click cadence (high periodicity or low standard deviation), which could indicate that the user is a script, not an actual human.\
Another search detects incidents wherein a single password is used across multiple accounts, which may indicate that a fraudster has infiltrated your environment and embedded a common password within a script.

[analytic_story://Detect Zerologon Attack]
category = Adversary Tactics
last_updated = 2020-09-18
version = 1
references = ["https://attack.mitre.org/wiki/Technique/T1003", "https://github.com/SecuraBV/CVE-2020-1472", "https://www.secura.com/blog/zero-logon", "https://nvd.nist.gov/vuln/detail/CVE-2020-1472"]
maintainers = [{"company": "Jose Hernandez, Stan Miskowicz, David Dorsey, Shannon Davis Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Detect Computer Changed with Anonymous Account - Rule", "ESCU - Detect Credential Dumping through LSASS access - Rule", "ESCU - Windows Possible Credential Dumping - Rule", "ESCU - Detect Zerologon via Zeek - Rule", "ESCU - Get Notable History - Response Task"]
description = Uncover activity related to the execution of Zerologon CVE-2020-11472, a technique wherein attackers target a Microsoft Windows Domain Controller to reset its computer account password. The result from this attack is attackers can now provide themselves high privileges and take over Domain Controller. The included searches in this Analytic Story are designed to identify attempts to reset Domain Controller Computer Account via exploit code remotely or via the use of tool Mimikatz as payload carrier.
narrative = This attack is a privilege escalation technique, where attacker targets a Netlogon secure channel connection to a domain controller, using Netlogon Remote Protocol (MS-NRPC). This vulnerability exposes vulnerable Windows Domain Controllers to be targeted via unaunthenticated RPC calls which eventually reset Domain Contoller computer account ($) providing the attacker the opportunity to exfil domain controller credential secrets and assign themselve high privileges that can lead to domain controller and potentially complete network takeover. The detection searches in this Analytic Story use Windows Event viewer events and Sysmon events to detect attack execution, these searches monitor access to the Local Security Authority Subsystem Service (LSASS) process which is an indicator of the use of Mimikatz tool which has bee updated to carry this attack payload.

[analytic_story://Dev Sec Ops]
category = Cloud Security
last_updated = 2021-08-18
version = 1
references = ["https://www.redhat.com/en/topics/devops/what-is-devsecops"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Patrick Bareiss"}]
spec_version = 3
searches = ["ESCU - AWS ECR Container Scanning Findings High - Rule", "ESCU - AWS ECR Container Scanning Findings Low Informational Unknown - Rule", "ESCU - AWS ECR Container Scanning Findings Medium - Rule", "ESCU - AWS ECR Container Upload Outside Business Hours - Rule", "ESCU - AWS ECR Container Upload Unknown User - Rule", "ESCU - Circle CI Disable Security Job - Rule", "ESCU - Circle CI Disable Security Step - Rule", "ESCU - GitHub Actions Disable Security Workflow - Rule", "ESCU - Github Commit Changes In Master - Rule", "ESCU - Github Commit In Develop - Rule", "ESCU - GitHub Dependabot Alert - Rule", "ESCU - GitHub Pull Request from Unknown User - Rule", "ESCU - Gsuite Drive Share In External Email - Rule", "ESCU - GSuite Email Suspicious Attachment - Rule", "ESCU - Gsuite Email Suspicious Subject With Attachment - Rule", "ESCU - Gsuite Email With Known Abuse Web Service Link - Rule", "ESCU - Gsuite Outbound Email With Attachment To External Domain - Rule", "ESCU - Gsuite Suspicious Shared File Name - Rule", "ESCU - Kubernetes Nginx Ingress LFI - Rule", "ESCU - Kubernetes Nginx Ingress RFI - Rule", "ESCU - Kubernetes Scanner Image Pulling - Rule", "ESCU - Risk Rule for Dev Sec Ops by Repository - Rule", "ESCU - Correlation by Repository and Risk - Rule", "ESCU - Correlation by User and Risk - Rule"]
description = This story is focused around detecting attacks on a DevSecOps lifeccycle which consists of the phases plan, code, build, test, release, deploy, operate and monitor.
narrative = DevSecOps is a collaborative framework, which thinks about application and infrastructure security from the start. This means that security tools are part of the continuous integration and continuous deployment pipeline. In this analytics story, we focused on detections around the tools used in this framework such as GitHub as a version control system, GDrive for the documentation, CircleCI as the CI/CD pipeline, Kubernetes as the container execution engine and multiple security tools such as Semgrep and Kube-Hunter.

[analytic_story://DHS Report TA18-074A]
category = Malware
last_updated = 2020-01-22
version = 2
references = ["https://www.us-cert.gov/ncas/alerts/TA18-074A"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - First time seen command line argument - Rule", "ESCU - Create local admin accounts using net exe - Rule", "ESCU - Detect New Local Admin account - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Malicious PowerShell Process - Execution Policy Bypass - Rule", "ESCU - Processes launching netsh - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Single Letter Process On Endpoint - Rule", "ESCU - Suspicious Reg exe Process - Rule", "ESCU - Detect Outbound SMB Traffic - Rule", "ESCU - SMB Traffic Spike - Rule", "ESCU - SMB Traffic Spike - MLTK - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process File Activity - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task"]
description = Monitor for suspicious activities associated with DHS Technical Alert US-CERT TA18-074A. Some of the activities that adversaries used in these compromises included spearfishing attacks, malware, watering-hole domains, many and more.
narrative = The frequency of nation-state cyber attacks has increased significantly over the last decade. Employing numerous tactics and techniques, these attacks continue to escalate in complexity. \
There is a wide range of motivations for these state-sponsored hacks, including stealing valuable corporate, military, or diplomatic data&#1151;all of which could confer advantages in various arenas. They may also target critical infrastructure. \
One joint Technical Alert (TA) issued by the Department of Homeland and the FBI in mid-March of 2018 attributed some cyber activity targeting utility infrastructure to operatives sponsored by the Russian government. The hackers executed spearfishing attacks, installed malware, employed watering-hole domains, and more. While they caused no physical damage, the attacks provoked fears that a nation-state could turn off water, redirect power, or compromise a nuclear power plant.\
Suspicious activities--spikes in SMB traffic, processes that launch netsh (to modify the network configuration), suspicious registry modifications, and many more--may all be events you may wish to investigate further. While the use of these technique may be an indication that a nation-state actor is attempting to compromise your environment, it is important to note that these techniques are often employed by other groups, as well.

[analytic_story://Disabling Security Tools]
category = Adversary Tactics
last_updated = 2020-02-04
version = 2
references = ["https://attack.mitre.org/wiki/Technique/T1089", "https://blog.malwarebytes.com/cybercrime/2015/11/vonteera-adware-uses-certificates-to-disable-anti-malware/", "https://web.archive.org/web/20220425194457/https://www.operationblockbuster.com/wp-content/uploads/2016/02/Operation-Blockbuster-Tools-Report.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Attempt To Add Certificate To Untrusted Store - Rule", "ESCU - Attempt To Stop Security Service - Rule", "ESCU - Processes launching netsh - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Suspicious Reg exe Process - Rule", "ESCU - Unload Sysmon Filter Driver - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Looks for activities and techniques associated with the disabling of security tools on a Windows system, such as suspicious `reg.exe` processes, processes launching netsh, and many others.
narrative = Attackers employ a variety of tactics in order to avoid detection and operate without barriers. This often involves modifying the configuration of security tools to get around them or explicitly disabling them to prevent them from running. This Analytic Story includes searches that look for activity consistent with attackers attempting to disable various security mechanisms. Such activity may involve monitoring for suspicious registry activity, as this is where much of the configuration for Windows and various other programs reside, or explicitly attempting to shut down security-related services. Other times, attackers attempt various tricks to prevent specific programs from running, such as adding the certificates with which the security tools are signed to a block list (which would prevent them from running).

[analytic_story://DNS Amplification Attacks]
category = Abuse
last_updated = 2016-09-13
version = 1
references = ["https://www.us-cert.gov/ncas/alerts/TA13-088A", "https://www.imperva.com/learn/application-security/dns-amplification/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Large Volume of DNS ANY Queries - Rule", "ESCU - Get Notable History - Response Task"]
description = DNS poses a serious threat as a Denial of Service (DOS) amplifier, if it responds to `ANY` queries. This Analytic Story can help you detect attackers who may be abusing your company's DNS infrastructure to launch amplification attacks, causing Denial of Service to other victims.
narrative = The Domain Name System (DNS) is the protocol used to map domain names to IP addresses. It has been proven to work very well for its intended function. However if DNS is misconfigured, servers can be abused by attackers to levy amplification or redirection attacks against victims. Because DNS responses to `ANY` queries are so much larger than the queries themselves--and can be made with a UDP packet, which does not require a handshake--attackers can spoof the source address of the packet and cause much more data to be sent to the victim than if they sent the traffic themselves. The `ANY` requests are will be larger than normal DNS server requests, due to the fact that the server provides significant details, such as MX records and associated IP addresses. A large volume of this traffic can result in a DOS on the victim's machine. This misconfiguration leads to two possible victims, the first being the DNS servers participating in an attack and the other being the hosts that are the targets of the DOS attack.\
The search in this story can help you to detect if attackers are abusing your company's DNS infrastructure to launch DNS amplification attacks causing Denial of Service to other victims.

[analytic_story://DNS Hijacking]
category = Adversary Tactics
last_updated = 2020-02-04
version = 1
references = ["https://www.fireeye.com/blog/threat-research/2017/09/apt33-insights-into-iranian-cyber-espionage.html", "https://umbrella.cisco.com/blog/2013/04/15/on-the-trail-of-malicious-dynamic-dns-domains/", "http://www.noip.com/blog/2014/07/11/dynamic-dns-can-use-2/", "https://www.splunk.com/blog/2015/08/04/detecting-dynamic-dns-domains-in-splunk.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Clients Connecting to Multiple DNS Servers - Rule", "ESCU - DNS Query Requests Resolved by Unauthorized DNS Servers - Rule", "ESCU - DNS record changed - Rule", "ESCU - Detect DGA domains using pretrained model in DSDL - Rule", "ESCU - Detect DNS Data Exfiltration using pretrained model in DSDL - Rule", "ESCU - Detect hosts connecting to dynamic domain providers - Rule", "ESCU - Detect suspicious DNS TXT records using pretrained model in DSDL - Rule", "ESCU - Get DNS Server History for a host - Response Task"]
description = Secure your environment against DNS hijacks with searches that help you detect and investigate unauthorized changes to DNS records.
narrative = Dubbed the Achilles heel of the Internet (see https://www.f5.com/labs/articles/threat-intelligence/dns-is-still-the-achilles-heel-of-the-internet-25613), DNS plays a critical role in routing web traffic but is notoriously vulnerable to attack. One reason is its distributed nature. It relies on unstructured connections between millions of clients and servers over inherently insecure protocols.\
The gravity and extent of the importance of securing DNS from attacks is undeniable. The fallout of compromised DNS can be disastrous. Not only can hackers bring down an entire business, they can intercept confidential information, emails, and login credentials, as well. \
On January 22, 2019, the US Department of Homeland Security 2019's Cybersecurity and Infrastructure Security Agency (CISA) raised awareness of some high-profile DNS hijacking attacks against infrastructure, both in the United States and abroad. It issued Emergency Directive 19-01 (see https://cyber.dhs.gov/ed/19-01/), which summarized the activity and required government agencies to take the following four actions, all within 10 days: \
1. For all .gov or other agency-managed domains, audit public DNS records on all authoritative and secondary DNS servers, verify that they resolve to the intended location or report them to CISA.\
1. Update the passwords for all accounts on systems that can make changes to each agency 2019's DNS records.\
1. Implement multi-factor authentication (MFA) for all accounts on systems that can make changes to each agency's 2019 DNS records or, if impossible, provide CISA with the names of systems, the reasons why MFA cannot be enabled within the required timeline, and an ETA for when it can be enabled.\
1. CISA will begin regular delivery of newly added certificates to Certificate Transparency (CT) logs for agency domains via the Cyber Hygiene service. Upon receipt, agencies must immediately begin monitoring CT log data for certificates issued that they did not request. If an agency confirms that a certificate was unauthorized, it must report the certificate to the issuing certificate authority and to CISA. Of course, it makes sense to put equivalent actions in place within your environment, as well. \
In DNS hijacking, the attacker assumes control over an account or makes use of a DNS service exploit to make changes to DNS records. Once they gain access, attackers can substitute their own MX records, name-server records, and addresses, redirecting emails and traffic through their infrastructure, where they can read, copy, or modify information seen. They can also generate valid encryption certificates to help them avoid browser-certificate checks. In one notable attack on the Internet service provider, GoDaddy, the hackers altered Sender Policy Framework (SPF) records a relatively minor change that did not inflict excessive damage but allowed for more effective spam campaigns.\
The searches in this Analytic Story help you detect and investigate activities that may indicate that DNS hijacking has taken place within your environment.

[analytic_story://sAMAccountName Spoofing and Domain Controller Impersonation]
category = Privilege Escalation
last_updated = 2021-12-20
version = 1
references = ["https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42278", "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42287", "https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - Suspicious Computer Account Name Change - Rule", "ESCU - Suspicious Kerberos Service Ticket Request - Rule", "ESCU - Suspicious Ticket Granting Ticket Request - Rule"]
description = Monitor for activities and techniques associated with the exploitation of the sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287) vulnerabilities.
narrative = On November 9, 2021, Microsoft released patches to address two vulnerabilities that affect Windows Active Directory networks, sAMAccountName Spoofing (CVE-2021-42278) and Domain Controller Impersonation (CVE-2021-42287). On December 10, 2021, security researchers Charlie Clark and Andrew Schwartz released a blog post where they shared how to weaponise these vulnerabilities in a target network an the initial detection opportunities. When successfully exploited, CVE-2021-42278 and CVE-2021-42287 allow an adversary, who has stolen the credentials of a low priviled domain user, to obtain a Kerberos Service ticket for a Domain Controller computer account. The only requirement is to have network connectivity to a domain controller. This attack vector effectivelly allows attackers to escalate their privileges in an Active Directory from a regular domain user account and take control of a domain controller. While patches have been released to address these vulnerabilities, deploying detection controls for this attack may help help defenders identify attackers attempting exploitation.

[analytic_story://Domain Trust Discovery]
category = Adversary Tactics
last_updated = 2021-03-25
version = 1
references = ["https://attack.mitre.org/techniques/T1482/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - DSQuery Domain Discovery - Rule", "ESCU - NLTest Domain Trust Discovery - Rule", "ESCU - Windows AdFind Exe - Rule"]
description = Adversaries may attempt to gather information on domain trust relationships that may be used to identify lateral movement opportunities in Windows multi-domain/forest environments.
narrative = Domain trusts provide a mechanism for a domain to allow access to resources based on the authentication procedures of another domain. Domain trusts allow the users of the trusted domain to access resources in the trusting domain. The information discovered may help the adversary conduct SID-History Injection, Pass the Ticket, and Kerberoasting. Domain trusts can be enumerated using the DSEnumerateDomainTrusts() Win32 API call, .NET methods, and LDAP. The Windows utility Nltest is known to be used by adversaries to enumerate domain trusts.

[analytic_story://Double Zero Destructor]
category = Data Destruction
last_updated = 2022-03-25
version = 1
references = ["https://cert.gov.ua/article/38088", "https://blog.talosintelligence.com/2022/03/threat-advisory-doublezero.html"]
maintainers = [{"company": "Rod Soto, Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Deleted Registry By A Non Critical Process File Path - Rule", "ESCU - Windows Terminating Lsass Process - Rule"]
description = Double Zero Destructor is a destructive payload that enumerates Domain Controllers and executes killswitch if detected. Overwrites files with Zero blocks or using MS Windows API calls such as NtFileOpen, NtFSControlFile. This payload also deletes registry hives HKCU,HKLM, HKU, HKLM BCD.
narrative = Double zero destructor enumerates domain controllers, delete registry hives and overwrites files using zero blocks and API calls.

[analytic_story://Dynamic DNS]
category = Malware
last_updated = 2018-09-06
version = 2
references = ["https://www.fireeye.com/blog/threat-research/2017/09/apt33-insights-into-iranian-cyber-espionage.html", "https://umbrella.cisco.com/blog/2013/04/15/on-the-trail-of-malicious-dynamic-dns-domains/", "http://www.noip.com/blog/2014/07/11/dynamic-dns-can-use-2/", "https://www.splunk.com/blog/2015/08/04/detecting-dynamic-dns-domains-in-splunk.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect web traffic to dynamic domain providers - Rule", "ESCU - DNS Exfiltration Using Nslookup App - Rule", "ESCU - Excessive Usage of NSLOOKUP App - Rule", "ESCU - Detect DGA domains using pretrained model in DSDL - Rule", "ESCU - Detect hosts connecting to dynamic domain providers - Rule", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Detect and investigate hosts in your environment that may be communicating with dynamic domain providers. Attackers may leverage these services to help them avoid firewall blocks and deny lists.
narrative = Dynamic DNS services (DDNS) are legitimate low-cost or free services that allow users to rapidly update domain resolutions to IP infrastructure. While their usage can be benign, malicious actors can abuse DDNS to host harmful payloads or interactive-command-and-control infrastructure. These attackers will manually update or automate domain resolution changes by routing dynamic domains to IP addresses that circumvent firewall blocks and deny lists and frustrate a network defender's analytic and investigative processes. These searches will look for DNS queries made from within your infrastructure to suspicious dynamic domains and then investigate more deeply, when appropriate. While this list of top-level dynamic domains is not exhaustive, it can be dynamically updated as new suspicious dynamic domains are identified.

[analytic_story://Emotet Malware DHS Report TA18-201A]
category = Malware
last_updated = 2020-01-27
version = 1
references = ["https://www.us-cert.gov/ncas/alerts/TA18-201A", "https://www.first.org/resources/papers/conf2017/Advanced-Incident-Detection-and-Threat-Hunting-using-Sysmon-and-Splunk.pdf", "https://www.vkremez.com/2017/05/emotet-banking-trojan-malware-analysis.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Email Attachments With Lots Of Spaces - Rule", "ESCU - Suspicious Email Attachment Extensions - Rule", "ESCU - Prohibited Software On Endpoint - Rule", "ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule", "ESCU - Detection of tools built by NirSoft - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - SMB Traffic Spike - Rule", "ESCU - SMB Traffic Spike - MLTK - Rule"]
description = Detect rarely used executables, specific registry paths that may confer malware survivability and persistence, instances where cmd.exe is used to launch script interpreters, and other indicators that the Emotet financial malware has compromised your environment.
narrative = The trojan downloader known as Emotet first surfaced in 2014, when it was discovered targeting the banking industry to steal credentials. However, according to a joint technical alert (TA) issued by three government agencies (https://www.us-cert.gov/ncas/alerts/TA18-201A), Emotet has evolved far beyond those beginnings to become what a ThreatPost article called a threat-delivery service(see https://threatpost.com/emotet-malware-evolves-beyond-banking-to-threat-delivery-service/134342/).  For example, in early 2018, Emotet was found to be using its loader function to spread the Quakbot and Ransomware variants. \
According to the TA, the the malware continues to be among the most costly and destructive malware affecting the private and public sectors. Researchers have linked it to the threat group Mealybug, which has also been on the security communitys radar since 2014.\
The searches in this Analytic Story will help you find executables that are rarely used in your environment, specific registry paths that malware often uses to ensure survivability and persistence, instances where cmd.exe is used to launch script interpreters, and other indicators that Emotet or other malware has compromised your environment. 

[analytic_story://F5 Authentication Bypass with TMUI]
category = Adversary Tactics
last_updated = 2023-10-30
version = 1
references = ["https://www.praetorian.com/blog/refresh-compromising-f5-big-ip-with-request-smuggling-cve-2023-46747/", "https://github.com/projectdiscovery/nuclei-templates/blob/3b0bb71bd627c6c3139e1d06c866f8402aa228ae/http/cves/2023/CVE-2023-46747.yaml"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - F5 TMUI Authentication Bypass - Rule"]
description = Research into leading software revealed vulnerabilities in both Apache Tomcat and the F5 BIG-IP suite. Apache's AJP protocol vulnerability, designated CVE-2022-26377, relates to AJP request smuggling. Successful exploitation enables unauthorized system activities. F5 BIG-IP Virtual Edition exhibited a distinct vulnerability, an authentication bypass in the Traffic Management User Interface (TMUI), resulting in system compromise. Assigned CVE-2023-46747, this vulnerability also arose from request smuggling, bearing similarity to CVE-2022-26377. Given the wide adoption of both Apache Tomcat and F5 products, these vulnerabilities present grave risks to organizations. Remediation and vulnerability detection mechanisms are essential to address these threats effectively.
narrative = Both Apache Tomcat's AJP protocol and F5's BIG-IP Virtual Edition have been exposed to critical vulnerabilities. Apache's CVE-2022-26377 pertains to request smuggling by manipulating the "Transfer-Encoding" header. If successfully exploited, this allows attackers to bypass security controls and undertake unauthorized actions. \
Similarly, F5 BIG-IP unveiled an authentication bypass vulnerability, CVE-2023-46747. Originating from the TMUI, this vulnerability leads to full system compromise. While distinct, it shares characteristics with Apache's vulnerability, primarily rooted in request smuggling. This vulnerability drew from past F5 CVEs, particularly CVE-2020-5902 and CVE-2022-1388, both previously exploited in real-world scenarios. These highlighted vulnerabilities in Apache HTTP and Apache Tomcat services, as well as authentication flaws in the F5 BIG-IP API.\
Nuclei detection templates offer a proactive solution for identifying and mitigating these vulnerabilities. Integrated into vulnerability management frameworks, these templates notify organizations of potential risks, forming a base for further detection strategies. For detection engineers, understanding these vulnerabilities is crucial. Recognizing the mechanisms and effects of request smuggling, especially in Apache's and F5's context, provides a roadmap to effective detection and response. Prompt detection is a linchpin, potentially stymieing further, more destructive attacks.

[analytic_story://F5 BIG-IP Vulnerability CVE-2022-1388]
category = Adversary Tactics
last_updated = 2022-05-10
version = 1
references = ["https://github.com/dk4trin/templates-nuclei/blob/main/CVE-2022-1388.yaml", "https://www.randori.com/blog/vulnerability-analysis-cve-2022-1388/", "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1388", "https://twitter.com/da_667/status/1523770267327250438?s=20\u0026t=-JnB_aNWuJFsmcOmxGUWLQ", "https://github.com/horizon3ai/CVE-2022-1388/blob/main/CVE-2022-1388.py"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - F5 BIG-IP iControl REST Vulnerability CVE-2022-1388 - Rule"]
description = CVE-2022-1388 is a unauthenticated remote code execution vulnerablity against BIG-IP iControl REST API.
narrative = CVE-2022-1388 is a critical vulnerability (CVSS 9.8) in the management interface of F5 Networks'' BIG-IP solution that enables an unauthenticated attacker to gain remote code execution on the system through bypassing F5''s iControl REST authentication. The vulnerability was first discovered by F5''s internal product security team and disclosed publicly on May 4, 2022, per Randori. This vulnerability,CVE-2022-1388, may allow an unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services. There is no data plane exposure; this is a control plane issue only per F5 article K23605346. Is CVE-2022-1388 Exploitable? Yes. There are now multiple POC scripts available and reports of threat actors scanning and potentially exploiting the vulnerablity. Per Randori the specific interface needed to exploit this vulnerability is rarely publicly exposed, and the risk to most organizations of exploitation by an unauthenticated external actor is low.

[analytic_story://F5 TMUI RCE CVE-2020-5902]
category = Adversary Tactics
last_updated = 2020-08-02
version = 1
references = ["https://www.ptsecurity.com/ww-en/about/news/f5-fixes-critical-vulnerability-discovered-by-positive-technologies-in-big-ip-application-delivery-controller/", "https://support.f5.com/csp/article/K52145254", "https://blog.cloudflare.com/cve-2020-5902-helping-to-protect-against-the-f5-tmui-rce-vulnerability/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Shannon Davis"}]
spec_version = 3
searches = ["ESCU - Detect F5 TMUI RCE CVE-2020-5902 - Rule", "ESCU - Get Notable History - Response Task"]
description = Uncover activity consistent with CVE-2020-5902. Discovered by Positive Technologies researchers, this vulnerability affects F5 BIG-IP, BIG-IQ. and Traffix SDC devices (vulnerable versions in F5 support link below). This vulnerability allows unauthenticated users, along with authenticated users, who have access to the configuration utility to execute system commands, create/delete files, disable services, and/or execute Java code.  This vulnerability can result in full system compromise.
narrative = A client is able to perform a remote code execution on an exposed and vulnerable system. The detection search in this Analytic Story uses syslog to detect the malicious behavior. Syslog is going to be the best detection method, as any systems using SSL to protect their management console will make detection via wire data difficult.  The searches included used Splunk Connect For Syslog (https://splunkbase.splunk.com/app/4740/), and used a custom destination port to help define the data as F5 data (covered in https://splunk-connect-for-syslog.readthedocs.io/en/master/sources/F5/)

[analytic_story://FIN7]
category = Malware
last_updated = 2021-09-14
version = 1
references = ["https://en.wikipedia.org/wiki/FIN7", "https://threatpost.com/fin7-windows-11-release/169206/", "https://www.proofpoint.com/us/blog/threat-insight/jssloader-recoded-and-reloaded"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Check Elevated CMD using whoami - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Jscript Execution Using Cscript App - Rule", "ESCU - MS Scripting Process Loading Ldap Module - Rule", "ESCU - MS Scripting Process Loading WMI Module - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Office Application Drop Executable - Rule", "ESCU - Office Product Spawning Wmic - Rule", "ESCU - Vbscript Execution Using Wscript App - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Wscript Or Cscript Suspicious Child Process - Rule", "ESCU - XSL Script Execution With WMIC - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the FIN7 JS Implant and JSSLoader, including looking for Image Loading of ldap and wmi modules, associated with its payload, data collection and script execution.
narrative = FIN7 is a Russian criminal advanced persistent threat group that has primarily targeted the U.S. retail, restaurant, and hospitality sectors since mid-2015. A portion of FIN7 is run out of the front company Combi Security. It has been called one of the most successful criminal hacking groups in the world. this passed few day FIN7 tools and implant are seen in the wild where its code is updated. the FIN& is known to use the spear phishing attack as a entry to targetted network or host that will drop its staging payload like the JS and JSSloader. Now this artifacts and implants seen downloading other malware like cobaltstrike and event ransomware to encrypt host.

[analytic_story://Flax Typhoon]
category = Adversary Tactics
last_updated = 2023-08-25
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2023/08/24/flax-typhoon-using-legitimate-software-to-quietly-access-taiwanese-organizations/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - BITSAdmin Download File - Rule", "ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Overwriting Accessibility Binaries - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows Mimikatz Binary Execution - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows SQL Spawning CertUtil - Rule"]
description = Microsoft has identified a nation-state activity group, Flax Typhoon, based in China, targeting Taiwanese organizations for espionage. The group maintains long-term access to networks with minimal use of malware, relying on built-in OS tools and benign software. The group's activities are primarily focused on Taiwan, but the techniques used could be easily reused in other operations outside the region. Microsoft has not observed Flax Typhoon using this access to conduct additional actions.
narrative = Flax Typhoon has been active since mid-2021, targeting government agencies, education, critical manufacturing, and IT organizations in Taiwan. The group uses the China Chopper web shell, Metasploit, Juicy Potato privilege escalation tool, Mimikatz, and SoftEther VPN client. However, they primarily rely on living-off-the-land techniques and hands-on-keyboard activity. Initial access is achieved by exploiting known vulnerabilities in public-facing servers and deploying web shells. Following initial access, Flax Typhoon uses command-line tools to establish persistent access over the remote desktop protocol, deploy a VPN connection to actor-controlled network infrastructure, and collect credentials from compromised systems. The group also uses this VPN access to scan for vulnerabilities on targeted systems and organizations from the compromised systems.

[analytic_story://Forest Blizzard]
category = Adversary Tactics
last_updated = 2023-09-11
version = 1
references = ["https://cert.gov.ua/article/5702579", "https://www.zscaler.com/blogs/security-research/steal-it-campaign", "https://attack.mitre.org/groups/G0007/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - CertUtil With Decode Argument - Rule", "ESCU - CHCP Command Execution - Rule", "ESCU - Headless Browser Mockbin or Mocky Request - Rule", "ESCU - Headless Browser Usage - Rule", "ESCU - Windows Curl Download to Suspicious Path - Rule"]
description = CERT-UA has unveiled a cyberattack on Ukraine's energy infrastructure, orchestrated via deceptive emails. These emails, once accessed, lead to a multi-stage cyber operation downloading and executing malicious payloads. Concurrently, Zscaler's "Steal-It" campaign detection revealed striking similarities, hinting at a shared origin - APT28 or Fancy Bear. This notorious group, linked to Russia's GRU, utilizes legitimate platforms like Mockbin, making detection challenging. Their operations underline the evolving cyber threat landscape and stress the importance of advanced defenses.
narrative = APT28, also known as Fancy Bear, blends stealth and expertise in its cyber operations. Affiliated with Russia's GRU, their signature move involves spear-phishing emails, leading to multi-tiered cyberattacks. In Ukraine's recent breach, a ZIP archive's execution triggered a series of actions, culminating in information flow redirection via the TOR network. Simultaneously, Zscaler's "Steal-It" campaign pinpointed similar tactics, specifically targeting NTLMv2 hashes. This campaign used ZIP archives containing LNK files to exfiltrate data via Mockbin. APT28's hallmark is their "Living Off The Land" strategy, manipulating legitimate tools and services to blend in, evading detection. Their innovative tactics, coupled with a geofencing focus on specific regions, make them a formidable cyber threat, highlighting the urgent need for advanced defense strategies.

[analytic_story://Fortinet FortiNAC CVE-2022-39952]
category = Adversary Tactics
last_updated = 2023-02-21
version = 1
references = ["https://www.horizon3.ai/fortinet-fortinac-cve-2022-39952-deep-dive-and-iocs/", "https://viz.greynoise.io/tag/fortinac-rce-attempt?days=30", "https://www.bleepingcomputer.com/news/security/fortinet-fixes-critical-rce-flaws-in-fortinac-and-fortiweb/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Exploit Public-Facing Fortinet FortiNAC CVE-2022-39952 - Rule"]
description = On Thursday, 16 February 2023, Fortinet released a PSIRT that details CVE-2022-39952, a critical vulnerability affecting its FortiNAC product (Horizon3.ai).
narrative = This vulnerability, discovered by Gwendal Guegniaud of Fortinet, allows an unauthenticated attacker to write arbitrary files on the system and as a result obtain remote code execution in the context of the root user (Horizon3.ai). Impacting FortiNAC, is tracked as CVE-2022-39952 and has a CVSS v3 score of 9.8 (critical). FortiNAC is a network access control solution that helps organizations gain real time network visibility, enforce security policies, and detect and mitigate threats. An external control of file name or path vulnerability CWE-73 in FortiNAC webserver may allow an unauthenticated attacker to perform arbitrary write on the system, reads the security advisory.

[analytic_story://GCP Account Takeover]
category = Account Compromise
last_updated = 2022-10-12
version = 1
references = ["https://cloud.google.com/gcp", "https://cloud.google.com/architecture/identity/overview-google-authentication", "https://attack.mitre.org/techniques/T1586/", "https://www.imperva.com/learn/application-security/account-takeover-ato/", "https://www.barracuda.com/glossary/account-takeover"]
maintainers = [{"company": "Bhavin Patel, Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - GCP Authentication Failed During MFA Challenge - Rule", "ESCU - GCP Multi-Factor Authentication Disabled - Rule", "ESCU - GCP Multiple Failed MFA Requests For User - Rule", "ESCU - GCP Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - GCP Successful Single-Factor Authentication - Rule", "ESCU - GCP Unusual Number of Failed Authentications From Ip - Rule"]
description = Monitor for activities and techniques associated with Account Takeover attacks against Google Cloud Platform tenants.
narrative = Account Takeover (ATO) is an attack whereby cybercriminals gain unauthorized access to online accounts by using different techniques like brute force, social engineering, phishing & spear phishing, credential stuffing, etc. By posing as the real user, cyber-criminals can change account details, send out phishing emails, steal financial information or sensitive data, or use any stolen information to access further accounts within the organization. This analytic story groups detections that can help security operations teams identify the potential compromise of Google cloud accounts.

[analytic_story://GCP Cross Account Activity]
category = Cloud Security
last_updated = 2020-09-01
version = 1
references = ["https://cloud.google.com/iam/docs/understanding-service-accounts"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - GCP Detect gcploit framework - Rule", "ESCU - GCP Detect accounts with high risk roles by project - Rule", "ESCU - GCP Detect high risk permissions by resource and account - Rule", "ESCU - gcp detect oauth token abuse - Rule", "ESCU - Get Notable History - Response Task"]
description = Track when a user assumes an IAM role in another GCP account to obtain cross-account access to services and resources in that account. Accessing new roles could be an indication of malicious activity.
narrative = Google Cloud Platform (GCP) admins manage access to GCP resources and services across the enterprise using GCP Identity and Access Management (IAM) functionality. IAM provides the ability to create and manage GCP users, groups, and roles-each with their own unique set of privileges and defined access to specific resources (such as Compute instances, the GCP Management Console, API, or the command-line interface). Unlike conventional (human) users, IAM roles are potentially assumable by anyone in the organization. They provide users with dynamically created temporary security credentials that expire within a set time period.\
In between the time between when the temporary credentials are issued and when they expire is a period of opportunity, where a user could leverage the temporary credentials to wreak havoc-spin up or remove instances, create new users, elevate privileges, and other malicious activities-throughout the environment.\
This Analytic Story includes searches that will help you monitor your GCP Audit logs logs for evidence of suspicious cross-account activity.  For example, while accessing multiple GCP accounts and roles may be perfectly valid behavior, it may be suspicious when an account requests privileges of an account it has not accessed in the past. After identifying suspicious activities, you can use the provided investigative searches to help you probe more deeply.

[analytic_story://Graceful Wipe Out Attack]
category = Data Destruction
last_updated = 2023-06-15
version = 1
references = ["https://thedfirreport.com/2023/06/12/a-truly-graceful-wipe-out/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Anomalous usage of 7zip - Rule", "ESCU - Attempt To Stop Security Service - Rule", "ESCU - CMD Echo Pipe - Escalation - Rule", "ESCU - Cobalt Strike Named Pipes - Rule", "ESCU - Deleting Of Net Users - Rule", "ESCU - Detect Regsvr32 Application Control Bypass - Rule", "ESCU - DLLHost with no Command Line Arguments with Network - Rule", "ESCU - Domain Account Discovery With Net App - Rule", "ESCU - Domain Group Discovery With Net - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - GPUpdate with no Command Line Arguments with Network - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Remote WMI Command Attempt - Rule", "ESCU - Rundll32 with no Command Line Arguments with Network - Rule", "ESCU - SAM Database File Access Attempt - Rule", "ESCU - SearchProtocolHost with no Command Line with Network - Rule", "ESCU - SecretDumps Offline NTDS Dumping Tool - Rule", "ESCU - Services Escalate Exe - Rule", "ESCU - Suspicious DLLHost no Command Line Arguments - Rule", "ESCU - Suspicious GPUpdate no Command Line Arguments - Rule", "ESCU - Suspicious microsoft workflow compiler rename - Rule", "ESCU - Suspicious msbuild path - Rule", "ESCU - Suspicious MSBuild Rename - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Rundll32 no Command Line Arguments - Rule", "ESCU - Suspicious Rundll32 StartW - Rule", "ESCU - Suspicious SearchProtocolHost no Command Line Arguments - Rule", "ESCU - Windows AdFind Exe - Rule", "ESCU - Windows Process Injection Remote Thread - Rule", "ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - Windows Service Stop By Deletion - Rule", "ESCU - Windows Service Stop Via Net  and SC Application - Rule"]
description = This analytic story contains detections that allow security analysts to detect and investigate unusual activities that might relate to the destructive attack or campaign found by "THE DFIR Report" that uses Truebot, FlawedGrace and MBR killer malware. This analytic story looks for suspicious dropped files, cobalt strike execution, im-packet execution, registry modification, scripts, persistence, lateral movement, impact, exfiltration and recon.
narrative = Graceful Wipe Out Attack is a destructive malware campaign found by "The DFIR Report" targeting multiple organizations to collect, exfiltrate and wipe the data of targeted networks. This malicious payload corrupts or wipes Master Boot Records by using an NSIS script after the exfiltration of sensitive information from the targeted host or system.

[analytic_story://HAFNIUM Group]
category = Adversary Tactics
last_updated = 2021-03-03
version = 1
references = ["https://www.splunk.com/en_us/blog/security/detecting-hafnium-exchange-server-zero-day-activity-in-splunk.html", "https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/", "https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/", "https://blog.rapid7.com/2021/03/03/rapid7s-insightidr-enables-detection-and-response-to-microsoft-exchange-0-day/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Email servers sending high volume traffic to hosts - Rule", "ESCU - Dump LSASS via procdump Rename - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - Detect Exchange Web Shell - Rule", "ESCU - Detect New Local Admin account - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Dump LSASS via procdump - Rule", "ESCU - Malicious PowerShell Process - Execution Policy Bypass - Rule", "ESCU - Nishang PowershellTCPOneLine - Rule", "ESCU - Ntdsutil Export NTDS - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - W3WP Spawning Shell - Rule"]
description = HAFNIUM group was identified by Microsoft as exploiting 4 Microsoft Exchange CVEs in the wild - CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065.
narrative = On Tuesday, March 2, 2021, Microsoft released a set of security patches for its mail server, Microsoft Exchange. These patches respond to a group of vulnerabilities known to impact Exchange 2013, 2016, and 2019. It is important to note that an Exchange 2010 security update has also been issued, though the CVEs do not reference that version as being vulnerable.\
While the CVEs do not shed much light on the specifics of the vulnerabilities or exploits, the first vulnerability (CVE-2021-26855) has a remote network attack vector that allows the attacker, a group Microsoft named HAFNIUM, to authenticate as the Exchange server. Three additional vulnerabilities (CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065) were also identified as part of this activity. When chained together along with CVE-2021-26855 for initial access, the attacker would have complete control over the Exchange server. This includes the ability to run code as SYSTEM and write to any path on the server.\
The following Splunk detections assist with identifying the HAFNIUM groups tradecraft and methodology.

[analytic_story://Hermetic Wiper]
category = Data Destruction
last_updated = 2022-03-02
version = 1
references = ["https://www.sentinelone.com/labs/hermetic-wiper-ukraine-under-attack/", "https://www.cisa.gov/uscert/ncas/alerts/aa22-057a"]
maintainers = [{"company": "Rod Soto, Michael Haag, Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Email Attachments With Lots Of Spaces - Rule", "ESCU - Suspicious Email Attachment Extensions - Rule", "ESCU - Suspicious Powershell Command-Line Arguments - Rule", "ESCU - Uncommon Processes On Endpoint - Rule", "ESCU - Active Setup Registry Autostart - Rule", "ESCU - Any Powershell DownloadFile - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - Change Default File Association - Rule", "ESCU - Child Processes of Spoolsv exe - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Detect Empire with PowerShell Script Block Logging - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - ETW Registry Disabled - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Kerberoasting spn request with RC4 encryption - Rule", "ESCU - Linux Java Spawning Shell - Rule", "ESCU - Logon Script Event Trigger Execution - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Malicious PowerShell Process With Obfuscation Techniques - Rule", "ESCU - MSI Module Loaded by Non-System Binary - Rule", "ESCU - Overwriting Accessibility Binaries - Rule", "ESCU - Possible Lateral Movement PowerShell Spawn - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - PowerShell Domain Enumeration - Rule", "ESCU - Powershell Enable SMB1Protocol Feature - Rule", "ESCU - Powershell Execute COM Object - Rule", "ESCU - Powershell Fileless Process Injection via GetProcAddress - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule", "ESCU - Powershell Processing Stream Of Data - Rule", "ESCU - Powershell Using memory As Backing Store - Rule", "ESCU - Print Processor Registry Autostart - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - Registry Keys Used For Privilege Escalation - Rule", "ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule", "ESCU - Runas Execution in CommandLine - Rule", "ESCU - Screensaver Event Trigger Execution - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Time Provider Persistence Registry - Rule", "ESCU - Unloading AMSI via Reflection - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows Disable Memory Crash Dump - Rule", "ESCU - Windows File Without Extension In Critical Folder - Rule", "ESCU - Windows Modify Show Compress Color And Info Tip Registry - Rule", "ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - WMI Recon Running Process Or Services - Rule"]
description = This analytic story contains detections that allow security analysts to detect and investigate unusual activities that might relate to the destructive malware targeting Ukrainian organizations also known as "Hermetic Wiper". This analytic story looks for abuse of Regsvr32, executables written in administrative SMB Share, suspicious processes, disabling of memory crash dump and more.
narrative = Hermetic Wiper is destructive malware operation found by Sentinel One targeting multiple organizations in Ukraine. This malicious payload corrupts Master Boot Records, uses signed drivers and manipulates NTFS attributes for file destruction.

[analytic_story://Hidden Cobra Malware]
category = Malware
last_updated = 2020-01-22
version = 2
references = ["https://web.archive.org/web/20191220004307/https://www.us-cert.gov/HIDDEN-COBRA-North-Korean-Malicious-Cyber-Activity", "https://web.archive.org/web/20220421112536/https://www.operationblockbuster.com/wp-content/uploads/2016/02/Operation-Blockbuster-Destructive-Malware-Report.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - First time seen command line argument - Rule", "ESCU - Suspicious File Write - Rule", "ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Remote Desktop Process Running On System - Rule", "ESCU - Detect Outbound SMB Traffic - Rule", "ESCU - DNS Query Length Outliers - MLTK - Rule", "ESCU - DNS Query Length With High Standard Deviation - Rule", "ESCU - Remote Desktop Network Traffic - Rule", "ESCU - SMB Traffic Spike - Rule", "ESCU - SMB Traffic Spike - MLTK - Rule", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Outbound Emails to Hidden Cobra Threat Actors - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task", "ESCU - Investigate Successful Remote Desktop Authentications - Response Task"]
description = Monitor for and investigate activities, including the creation or deletion of hidden shares and file writes, that may be evidence of infiltration by North Korean government-sponsored cybercriminals. Details of this activity were reported in DHS Report TA-18-149A.
narrative = North Korea's government-sponsored "cyber army" has been slowly building momentum and gaining sophistication over the last 15 years or so. As a result, the group's activity, which the US government refers to as "Hidden Cobra," has surreptitiously crept onto the collective radar as a preeminent global threat.\
These state-sponsored actors are thought to be responsible for everything from a hack on a South Korean nuclear plant to an attack on Sony in anticipation of its release of the movie "The Interview" at the end of 2014. They're also notorious for cyberespionage. In recent years, the group seems to be focused on financial crimes, such as cryptojacking.\
In June of 2018, The Department of Homeland Security, together with the FBI and other U.S. government partners, issued Technical Alert (TA-18-149A) to advise the public about two variants of North Korean malware. One variant, dubbed "Joanap," is a multi-stage peer-to-peer botnet that allows North Korean state actors to exfiltrate data, download and execute secondary payloads, and initialize proxy communications. The other variant, "Brambul," is a Windows32 SMB worm that is dropped into a victim network. When executed, the malware attempts to spread laterally within a victim's local subnet, connecting via the SMB protocol and initiating brute-force password attacks. It reports details to the Hidden Cobra actors via email, so they can use the information for secondary remote operations.\
Among other searches in this Analytic Story is a detection search that looks for the creation or deletion of hidden shares, such as, "adnim$," which the Hidden Cobra malware creates on the target system. Another looks for the creation of three malicious files associated with the malware. You can also use a search in this story to investigate activity that indicates that malware is sending email back to the attackers.

[analytic_story://IIS Components]
category = Adversary Tactics
last_updated = 2022-12-19
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2022/12/12/iis-modules-the-evolution-of-web-shells-and-how-to-detect-them/", "https://attack.mitre.org/techniques/T1505/004/", "https://www.crowdstrike.com/wp-content/uploads/2022/05/crowdstrike-iceapple-a-novel-internet-information-services-post-exploitation-framework-1.pdf", "https://unit42.paloaltonetworks.com/unit42-oilrig-uses-rgdoor-iis-backdoor-targets-middle-east/", "https://www.secureworks.com/research/bronze-union", "https://strontic.github.io/xcyclopedia/library/appcmd.exe-055B2B09409F980BF9B5A3969D01E5B2.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Disable Windows Event Logging Disable HTTP Logging - Rule", "ESCU - Windows IIS Components Add New Module - Rule", "ESCU - Windows IIS Components Get-WebGlobalModule Module Query - Rule", "ESCU - Windows IIS Components Module Failed to Load - Rule", "ESCU - Windows IIS Components New Module Added - Rule", "ESCU - Windows PowerShell Add Module to Global Assembly Cache - Rule", "ESCU - Windows PowerShell Disable HTTP Logging - Rule", "ESCU - Windows PowerShell IIS Components WebGlobalModule Usage - Rule", "ESCU - Windows Server Software Component GACUtil Install to GAC - Rule"]
description = Adversaries may install malicious components that run on Internet Information Services (IIS) web servers to establish persistence.
narrative = IIS provides several mechanisms to extend the functionality of the web servers. For example, Internet Server Application Programming Interface (ISAPI) extensions and filters can be installed to examine and/or modify incoming and outgoing IIS web requests. Extensions and filters are deployed as DLL files that export three functions - Get{Extension/Filter}Version, Http{Extension/Filter}Proc, and (optionally) Terminate{Extension/Filter}. IIS modules may also be installed to extend IIS web servers.\
Adversaries may install malicious ISAPI extensions and filters to observe and/or modify traffic, execute commands on compromised machines, or proxy command and control traffic. ISAPI extensions and filters may have access to all IIS web requests and responses. For example, an adversary may abuse these mechanisms to modify HTTP responses in order to distribute malicious commands/content to previously comprised hosts.\
Adversaries may also install malicious IIS modules to observe and/or modify traffic. IIS 7.0 introduced modules that provide the same unrestricted access to HTTP requests and responses as ISAPI extensions and filters. IIS modules can be written as a DLL that exports RegisterModule, or as a .NET application that interfaces with ASP.NET APIs to access IIS HTTP requests. (reference MITRE)

[analytic_story://Industroyer2]
category = Malware
last_updated = 2022-04-21
version = 1
references = ["https://cert.gov.ua/article/39518", "https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - AdsiSearcher Account Discovery - Rule", "ESCU - Attempted Credential Dump From Registry via Reg exe - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux DD File Overwrite - Rule", "ESCU - Linux Deleting Critical Directory Using RM Command - Rule", "ESCU - Linux Disable Services - Rule", "ESCU - Linux High Frequency Of File Deletion In Boot Folder - Rule", "ESCU - Linux Shred Overwrite Command - Rule", "ESCU - Linux Stdout Redirection To Dev Null File - Rule", "ESCU - Linux Stop Services - Rule", "ESCU - Linux System Network Discovery - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - Schtasks Run Task On Demand - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Hidden Schedule Task Settings - Rule", "ESCU - Windows Linked Policies In ADSI Discovery - Rule", "ESCU - Windows Processes Killed By Industroyer2 Malware - Rule", "ESCU - Windows Root Domain linked policies Discovery - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Industroyer2 attack, including file writes associated with its payload, lateral movement, persistence, privilege escalation and data destruction.
narrative = Industroyer2 is part of continuous attack to ukraine targeting energy facilities. This malware is a windows binary that implement IEC-104 protocol to communicate with industrial equipments. This attack consist of several destructive linux script component to wipe or delete several linux critical files, powershell for domain enumeration and caddywiper to wipe boot sector of the targeted host.

[analytic_story://Information Sabotage]
category = Abuse
last_updated = 2021-11-17
version = 1
references = ["https://insights.sei.cmu.edu/blog/insider-threat-deep-dive-it-sabotage/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - High Frequency Copy Of Files In Network Share - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might correlate to insider threat specially in terms of information sabotage.
narrative = Information sabotage is the type of crime many people associate with insider threat. Where the current or former employees, contractors, or business partners intentionally exceeded or misused an authorized level of access to networks, systems, or data with the intention of harming a specific individual, the organization, or the organization's data, systems, and/or daily business operations.

[analytic_story://Ingress Tool Transfer]
category = Adversary Tactics
last_updated = 2021-03-24
version = 1
references = ["https://attack.mitre.org/techniques/T1105/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Any Powershell DownloadFile - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - BITSAdmin Download File - Rule", "ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule", "ESCU - Curl Download and Bash Execution - Rule", "ESCU - Detect Certify Command Line Arguments - Rule", "ESCU - Detect Certipy File Modifications - Rule", "ESCU - Linux Curl Upload File - Rule", "ESCU - Linux Ingress Tool Transfer Hunting - Rule", "ESCU - Linux Ingress Tool Transfer with Curl - Rule", "ESCU - Linux Proxy Socks Curl - Rule", "ESCU - Suspicious Curl Network Connection - Rule", "ESCU - Wget Download and Bash Execution - Rule", "ESCU - Windows Curl Download to Suspicious Path - Rule", "ESCU - Windows Curl Upload to Remote Destination - Rule"]
description = Adversaries may transfer tools or other files from an external system into a compromised environment. Files may be copied from an external adversary controlled system through the Command And Control channel to bring tools into the victim network or through alternate protocols with another tool such as FTP.
narrative = Ingress tool transfer is a Technique under tactic Command And Control. Behaviors will include the use of living off the land binaries to download implants or binaries over alternate communication ports. It is imperative to baseline applications on endpoints to understand what generates network activity, to where, and what is its native behavior. These utilities, when abused, will write files to disk in world writeable paths.\ During triage, review the reputation of the remote public destination IP or domain. Capture any files written to disk and perform analysis. Review other parrallel processes for additional behaviors.

[analytic_story://Insider Threat]
category = Adversary Tactics
last_updated = 2022-05-19
version = 1
references = ["https://www.imperva.com/learn/application-security/insider-threats/", "https://www.cisa.gov/defining-insider-threats", "https://www.code42.com/glossary/types-of-insider-threats/", "https://github.com/Insider-Threat/Insider-Threat", "https://ctid.mitre-engenuity.org/our-work/insider-ttp-kb/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Jose Hernandez"}]
spec_version = 3
searches = ["ESCU - Gsuite Drive Share In External Email - Rule", "ESCU - Gsuite Outbound Email With Attachment To External Domain - Rule", "ESCU - Detect Remote Access Software Usage File - Rule", "ESCU - Detect Remote Access Software Usage FileInfo - Rule", "ESCU - Detect Remote Access Software Usage Process - Rule", "ESCU - High Frequency Copy Of Files In Network Share - Rule", "ESCU - Potential password in username - Rule", "ESCU - Windows Multiple Users Fail To Authenticate Wth ExplicitCredentials - Rule", "ESCU - Windows Multiple Users Failed To Authenticate From Process - Rule", "ESCU - Windows Remote Access Software Hunt - Rule", "ESCU - Windows Unusual Count Of Users Fail To Auth Wth ExplicitCredentials - Rule", "ESCU - Windows Unusual Count Of Users Failed To Authenticate From Process - Rule", "ESCU - Detect Remote Access Software Usage DNS - Rule", "ESCU - Detect Remote Access Software Usage Traffic - Rule", "ESCU - Detect Remote Access Software Usage URL - Rule"]
description = Monitor for activities and techniques associated with insider threats and specifically focusing on malicious insiders operating with in a corporate environment.
narrative = Insider Threats are best defined by CISA: "Insider threat incidents are possible in any sector or organization. An insider threat is typically a current or former employee, third-party contractor, or business partner. In their present or former role, the person has or had access to an organization's network systems, data, or premises, and uses their access (sometimes unwittingly). To combat the insider threat, organizations can implement a proactive, prevention-focused mitigation program to detect and identify threats, assess risk, and manage that risk - before an incident occurs." An insider is any person who has or had authorized access to or knowledge of an organization's resources, including personnel, facilities, information, equipment, networks, and systems. These are the common insiders that create insider threats: Departing Employees, Security Evaders, Malicious Insiders, and Negligent Employees. This story aims at detecting the malicious insider.

[analytic_story://Ivanti Connect Secure VPN Vulnerabilities]
category = Adversary Tactics
last_updated = 2024-01-16
version = 1
references = ["https://github.com/RootUp/PersonalStuff/blob/master/http-vuln-cve2023-46805_2024_21887.nse", "https://github.com/projectdiscovery/nuclei-templates/blob/c6b351e71b0fb0e40e222e97038f1fe09ac58194/http/misconfiguration/ivanti/CVE-2023-46085-CVE-2024-21887-mitigation-not-applied.yaml", "https://github.com/rapid7/metasploit-framework/pull/18708/files", "https://attackerkb.com/topics/AdUh6by52K/cve-2023-46805/rapid7-analysis", "https://labs.watchtowr.com/welcome-to-2024-the-sslvpn-chaos-continues-ivanti-cve-2023-46805-cve-2024-21887/", "https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/", "https://www.mandiant.com/resources/blog/suspected-apt-targets-ivanti-zero-day", "https://forums.ivanti.com/s/article/CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Access to Vulnerable Ivanti Connect Secure Bookmark Endpoint - Rule", "ESCU - Ivanti Connect Secure Command Injection Attempts - Rule", "ESCU - Ivanti Connect Secure SSRF in SAML Component - Rule", "ESCU - Ivanti Connect Secure System Information Access via Auth Bypass - Rule"]
description = The following analytic story addresses critical vulnerabilities CVE-2023-46805 and CVE-2024-21887 in Ivanti Connect Secure and Ivanti Policy Secure Gateways. CVE-2023-46805 is an authentication bypass vulnerability, while CVE-2024-21887 is a command injection flaw, both presenting significant risks in versions 9.x and 22.x. Combined, these vulnerabilities enable unauthenticated threat actors to execute arbitrary commands, compromising system integrity. Immediate mitigation is imperative, with patches scheduled for staggered release. Ivanti has provided interim mitigation steps, and it's crucial for customers to apply these measures to protect their systems against potential exploits.
narrative = Ivanti Connect Secure and Ivanti Policy Secure gateways face a severe security challenge with the discovery of CVE-2023-46805 and CVE-2024-21887. CVE-2023-46805 allows attackers to bypass authentication in critical web components of versions 9.x and 22.x. More alarmingly, when paired with CVE-2024-21887, a command injection vulnerability, it enables remote attackers to execute arbitrary commands without authentication. This combination poses a heightened threat, undermining the security of enterprise networks. Ivanti has mobilized resources to address these vulnerabilities, offering immediate mitigation advice and scheduling patch releases. Customers are urged to apply these mitigations without delay to safeguard their networks.

[analytic_story://Ivanti EPMM Remote Unauthenticated Access]
category = Vulnerability
last_updated = 2023-08-08
version = 2
references = ["https://www.securityweek.com/second-ivanti-epmm-zero-day-vulnerability-exploited-in-targeted-attacks/", "https://www.cisa.gov/news-events/alerts/2023/07/28/ivanti-releases-security-updates-epmm-address-cve-2023-35081", "https://nvd.nist.gov/vuln/detail/CVE-2023-35078", "https://forums.ivanti.com/s/article/CVE-2023-35078-Remote-unauthenticated-API-access-vulnerability?language=en_US"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Ivanti EPMM Remote Unauthenticated API Access CVE-2023-35078 - Rule", "ESCU - Ivanti EPMM Remote Unauthenticated API Access CVE-2023-35082 - Rule"]
description = Ivanti, a leading technology company, has disclosed two critical zero-day vulnerabilities in its Endpoint Manager Mobile (EPMM) product, CVE-2023-35078 and CVE-2023-35081. A recent update concerning CVE-2023-35082, closely related to CVE-2023-35078, reveals its impact on more versions of Ivanti's software than initially believed. The former allows unauthenticated attackers to obtain sensitive data, modify servers, and access the API, potentially leading to data breaches or malicious system modifications. Meanwhile, CVE-2023-35081 lets authenticated administrators remotely write arbitrary files to the server. Both vulnerabilities have been exploited in targeted attacks against government ministries and could be used in conjunction. With the presence of PoC code for CVE-2023-35078, the risk of broader exploitation has increased. While initially leveraged in limited attacks, the exploitation is expected to rise, possibly involving state-sponsored actors. Organizations are urged to apply immediate patches and conduct regular system assessments to ensure security.
narrative = Ivantis Endpoint Manager Mobile (EPMM) product, formerly known as MobileIron Core and extensively utilized by IT teams to manage mobile devices, applications, and content, has been found to harbor several critical vulnerabilities. Specifically, CVE-2023-35078 allows remote unauthenticated attackers to access sensitive data and make changes to servers. This flaw has been leveraged in targeted attacks against Norwegian government ministries. In addition, CVE-2023-35081 permits an authenticated attacker with administrative privileges to remotely write arbitrary files to the server. \
Recently, attention has shifted to CVE-2023-35082, which was initially believed to affect only MobileIron Core 11.2 and below. Subsequent investigations revealed its wider influence, affecting EPMM versions 11.10, 11.9, 11.8, and MobileIron Core 11.7 and earlier. This vulnerability facilitates unauthorized access to the API via the URI path /mifs/asfV3/api/v2/. \
When combined, these vulnerabilities can be exploited to bypass administrative authentication and access control list (ACL) restrictions, leading to malicious file writing and potential OS command execution. Both have been actively exploited, possibly by state-sponsored actors, prompting urgent advisories from Ivanti and Rapid7, alongside CISA. Given the thousands of potentially vulnerable internet-exposed systems and the presence of PoC code for CVE-2023-35078, the risk of extensive exploitation escalates. The situation is further muddled by Ivanti's 2020 acquisition of MobileIron, which had its known issues. Collectively, these vulnerabilities present a significant risk to organizations utilizing Ivanti's EPMM, emphasizing the need for swift patching, vigilant monitoring, and timely application of fixes to counteract potential threats.

[analytic_story://Ivanti Sentry Authentication Bypass CVE-2023-38035]
category = Adversary Tactics
last_updated = 2023-08-24
version = 1
references = ["https://github.com/horizon3ai/CVE-2023-38035/blob/main/CVE-2023-38035.py", "https://www.horizon3.ai/ivanti-sentry-authentication-bypass-cve-2023-38035-deep-dive/", "https://forums.ivanti.com/s/article/KB-API-Authentication-Bypass-on-Sentry-Administrator-Interface-CVE-2023-38035?language=en_US"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Ivanti Sentry Authentication Bypass - Rule"]
description = A critical vulnerability, designated as CVE-2023-38035, has been identified in Ivanti Sentry (formerly MobileIron Sentry). It affects all supported versions, including 9.18, 9.17, and 9.16, as well as older versions. The vulnerability allows an unauthenticated attacker to access the System Manager Portal (typically hosted on port 8443) and make configuration changes, potentially executing OS commands as root. However, the risk is low for users who haven't exposed port 8443 online. This flaw is distinct from other Ivanti products. It's imperative for organizations to check for unrecognized HTTP requests to /services/* as a potential indicator of compromise.
narrative = CVE-2023-38035 presents a significant security risk in the Ivanti Sentry administration interface. The vulnerability was identified shortly after another notable vulnerability in Ivanti EPMM (CVE-2023-35078) was discovered being exploited in the wild. The current vulnerability allows a malicious actor, without requiring authentication, to access the System Manager Portal, typically hosted on port 8443. Upon successful exploitation, the attacker can make configuration alterations to both the Sentry system and its underlying OS. The potential damage is significant, enabling the attacker to execute commands on the system with root privileges. \
While this vulnerability scored high on the CVSS scale, its risk is relatively mitigated for clients who have not exposed port 8443 to the internet. The primary exploitation vector is the System Manager Portal, an administrative interface for Sentry. \
As of now, definitive indicators of compromise (IoCs) are elusive. However, any unexpected HTTP requests to the endpoint /services/* could be a red flag. It's worth noting that the exploited endpoint might not be the sole vulnerable point, suggesting other potential gateways for attackers. Ivanti Sentry's system doesn't provide a typical Unix shell, but in the event of a known system breach, the /var/log/tomcat2/ directory contains access logs that may reveal accessed endpoints. Additionally, web interface logs may provide insights into suspicious activities and should be monitored closely.

[analytic_story://JBoss Vulnerability]
category = Vulnerability
last_updated = 2017-09-14
version = 1
references = ["http://www.deependresearch.org/2016/04/jboss-exploits-view-from-victim.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect attackers scanning for vulnerable JBoss servers - Rule", "ESCU - Detect malicious requests to exploit JBoss servers - Rule", "ESCU - Get Notable History - Response Task"]
description = In March of 2016, adversaries were seen using JexBoss--an open-source utility used for testing and exploiting JBoss application servers. These searches help detect evidence of these attacks, such as network connections to external resources or web services spawning atypical child processes, among others.
narrative = This Analytic Story looks for probing and exploitation attempts targeting JBoss application servers. While the vulnerabilities associated with this story are rather dated, they were leveraged in a spring 2016 campaign in connection with the Samsam ransomware variant. Incidents involving this ransomware are unique, in that they begin with attacks against vulnerable services, rather than the phishing or drive-by attacks more common with ransomware. In this case, vulnerable JBoss applications appear to be the target of choice.\
It is helpful to understand how often a notable event generated by this story occurs, as well as the commonalities between some of these events, both of which may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. It may also help to understand whether the issue is restricted to a single user/system or whether it is broader in scope.\
When looking at the target of the behavior uncovered by the event, you should note the sensitivity of the user and or/system to help determine the potential impact. It is also helpful to identify other recent events involving the target. This can help tie different events together and give further situational awareness regarding the target host.\
Various types of information for external systems should be reviewed and, potentially, collected if the incident is, indeed, judged to be malicious. This data may be useful for generating your own threat intelligence, so you can create future alerts.\
The following factors may assist you in determining whether the event is malicious: \
1. Country of origin\
1. Responsible party\
1. Fully qualified domain names associated with the external IP address\
1. Registration of fully qualified domain names associated with external IP address Determining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you qualify and understand the event and possible motivation for the attack. In addition, there are various sources that may provide reputation information on the IP address or domain name, which can assist you in determining whether the event is malicious in nature. Finally, determining whether there are other events associated with the IP address may help connect data points or expose other historic events that might be brought back into scope.\
Gathering various data on the system of interest can sometimes help quickly determine whether something suspicious is happening. Some of these items include determining who else may have logged into the system recently, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and/or whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.\
hen a specific service or application is targeted, it is often helpful to know the associated version, to help determine whether it is vulnerable to a specific exploit.\
If you suspect an attack targeting a web server, it is helpful to look at some of the behavior of the web service to see if there is evidence that the service has been compromised. Some indications of this might be network connections to external resources, the web service spawning child processes that are not associated with typical behavior, and whether the service wrote any files that might be malicious in nature.\
If a suspicious file is found, we can review more information about it to help determine if it is, in fact, malicious. Identifying the file type, any processes that opened the file, the processes that may have created and/or modified the file, and how many other systems potentially have this file can you determine whether the file is malicious. Also, determining the file hash and checking it against reputation sources, such as VirusTotal, can sometimes help you quickly determine if it is malicious in nature.\
Often, a simple inspection of a suspect process name and path can tell you if the system has been compromised. For example, if svchost.exe is found running from a location other than `C:\Windows\System32`, it is likely something malicious designed to hide in plain sight when simply reviewing process names. \
It can also be helpful to examine various behaviors of and the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see whether the parent process spawned other processes that might also warrant further scrutiny. If a process is suspect, a review of the network connections made around the time of the event and noting whether the process has spawned any child processes could be helpful in determining whether it is malicious or executing a malicious script.

[analytic_story://Jenkins Server Vulnerabilities]
category = Adversary Tactics
last_updated = 2024-01-29
version = 1
references = ["https://www.jenkins.io/security/advisory/2024-01-24/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Jenkins Arbitrary File Read CVE-2024-23897 - Rule"]
description = This analytic story provides a comprehensive view of Jenkins server vulnerabilities and associated detection analytics.
narrative = The following analytic story provides a comprehensive view of Jenkins server vulnerabilities and associated detection analytics. Jenkins is a popular open-source automation server that is used to automate tasks associated with building, testing, and deploying software. Jenkins is often used in DevOps environments and is a critical component of the software development lifecycle. As a result, Jenkins servers are often targeted by adversaries to gain access to sensitive information, credentials, and other critical assets. This analytic story provides a comprehensive view of Jenkins server vulnerabilities and associated detection analytics.

[analytic_story://JetBrains TeamCity Unauthenticated RCE]
category = Adversary Tactics
last_updated = 2023-10-01
version = 1
references = ["https://blog.jetbrains.com/teamcity/2023/09/critical-security-issue-affecting-teamcity-on-premises-update-to-2023-05-4-now/", "https://www.sonarsource.com/blog/teamcity-vulnerability/", "https://github.com/rapid7/metasploit-framework/pull/18408", "https://attackerkb.com/topics/1XEEEkGHzt/cve-2023-42793/rapid7-analysis"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - JetBrains TeamCity RCE Attempt - Rule"]
description = A critical security vulnerability, CVE-2023-42793, has been discovered affecting all versions of TeamCity On-Premises up to 2023.05.3. This vulnerability allows unauthenticated attackers to execute remote code and gain administrative control of the TeamCity server, posing a significant risk for supply chain attacks. Although the issue has been fixed in version 2023.05.4, servers running older versions remain at risk. A security patch plugin has been released for immediate mitigation, applicable to TeamCity versions 8.0 and above. Organizations are strongly advised to update to the fixed version or apply the security patch, especially if their TeamCity server is publicly accessible. No impact has been reported on TeamCity Cloud as it has been upgraded to the secure version.
narrative = The CVE-2023-42793 vulnerability in TeamCity On-Premises allows an unauthenticated attacker to bypass authentication and gain administrative access through Remote Code Execution (RCE). Specifically, the attacker can send a malicious POST request to /app/rest/users/id:1/tokens/RPC2 to create an administrative token. Once the token is obtained, the attacker has the ability to perform various unauthorized activities, including creating new admin users and executing arbitrary shell commands on the server. \ For Splunk Security Content, the focus should be on identifying suspicious POST requests to /app/rest/users/id:1/tokens/RPC2 and other affected API endpoints, as this is the initial point of exploitation. Monitoring logs for changes to the internal.properties file or the creation of new admin users could also provide crucial indicators of compromise. Furthermore, Splunk can be configured to alert on multiple failed login attempts followed by a successful login from the same IP, which could indicate exploitation attempts.

[analytic_story://JetBrains TeamCity Vulnerabilities]
category = Adversary Tactics
last_updated = 2024-03-04
version = 1
references = ["https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/", "https://blog.jetbrains.com/teamcity/2024/03/teamcity-2023-11-4-is-out/", "https://blog.jetbrains.com/teamcity/2024/03/additional-critical-security-issues-affecting-teamcity-on-premises-cve-2024-27198-and-cve-2024-27199-update-to-2023-11-4-now/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - JetBrains TeamCity Authentication Bypass CVE-2024-27198 - Rule", "ESCU - JetBrains TeamCity Authentication Bypass Suricata CVE-2024-27198 - Rule", "ESCU - JetBrains TeamCity Limited Auth Bypass Suricata CVE-2024-27199 - Rule", "ESCU - JetBrains TeamCity RCE Attempt - Rule"]
description = This story provides a high-level overview of JetBrains TeamCity vulnerabilities and how to detect and respond to them using Splunk.
narrative = JetBrains TeamCity is a continuous integration and deployment server that allows developers to automate the process of building, testing, and deploying code. It is a popular tool used by many organizations to streamline their development and deployment processes. However, like any software, JetBrains TeamCity is not immune to vulnerabilities.

[analytic_story://Juniper JunOS Remote Code Execution]
category = Adversary Tactics
last_updated = 2023-08-29
version = 1
references = ["https://supportportal.juniper.net/s/article/2023-08-Out-of-Cycle-Security-Bulletin-Junos-OS-SRX-Series-and-EX-Series-Multiple-vulnerabilities-in-J-Web-can-be-combined-to-allow-a-preAuth-Remote-Code-Execution?language=en_US", "https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2023/CVE-2023-36844.yaml", "https://thehackernews.com/2023/08/new-juniper-junos-os-flaws-expose.html", "https://github.com/watchtowrlabs/juniper-rce_cve-2023-36844", "https://labs.watchtowr.com/cve-2023-36844-and-friends-rce-in-juniper-firewalls/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Juniper Networks Remote Code Execution Exploit Detection - Rule"]
description = Juniper Networks has resolved multiple critical vulnerabilities in the J-Web component of Junos OS on SRX and EX Series devices. These vulnerabilities, when chained together, could allow an unauthenticated, network-based attacker to remotely execute code on the devices. The vulnerabilities affect all versions of Junos OS on SRX and EX Series, but specific fixes have been released to address each vulnerability. Juniper Networks recommends applying the necessary fixes to mitigate potential remote code execution threats. As a workaround, users can disable J-Web or limit access to only trusted hosts. Proof-of-concept (PoC) exploit code has been released, demonstrating the severity of these flaws and the urgency to apply the fixes.
narrative = Juniper Networks, a networking hardware company, has released an "out-of-cycle" security update to address multiple flaws in the J-Web component of Junos OS that could be combined to achieve remote code execution on susceptible installations. The flaws have a cumulative CVSS rating of 9.8, making them critical in severity. They affect all versions of Junos OS on SRX and EX Series. The J-Web interface allows users to configure, manage, and monitor Junos OS devices. The vulnerabilities include two PHP external variable modification vulnerabilities (CVE-2023-36844 and CVE-2023-36845) and two missing authentications for critical function vulnerabilities (CVE-2023-36846 and CVE-2023-36847). These vulnerabilities could allow an unauthenticated, network-based attacker to control certain important environment variables, cause limited impact to the file system integrity, or upload arbitrary files via J-Web without any authentication. \
The vulnerabilities have been addressed in specific Junos OS versions for EX Series and SRX Series devices. Users are recommended to apply the necessary fixes to mitigate potential remote code execution threats. As a workaround, Juniper Networks suggests disabling J-Web or limiting access to only trusted hosts. \
Additionally, a PoC exploit has been released by watchTowr, combining CVE-2023-36846 and CVE-2023-36845 to upload a PHP file containing malicious shellcode and achieve code execution by injecting the PHPRC environment variable to point to a configuration file to load the booby-trapped PHP script. WatchTowr noted that this is an interesting bug chain, utilizing two bugs that would be near-useless in isolation and combining them for a "world-ending" unauthenticated remote code execution. \
In conclusion, these vulnerabilities pose a significant threat to Juniper SRX and EX Series devices, and it is imperative for users to apply the necessary fixes or implement the recommended workaround to mitigate the potential impact.

[analytic_story://Kubernetes Scanning Activity]
category = Cloud Security
last_updated = 2020-04-15
version = 1
references = ["https://github.com/splunk/cloud-datamodel-security-research"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Amazon EKS Kubernetes cluster scan detection - Rule", "ESCU - Amazon EKS Kubernetes Pod scan detection - Rule", "ESCU - GCP Kubernetes cluster pod scan detection - Rule", "ESCU - GCP Kubernetes cluster scan detection - Rule", "ESCU - Kubernetes Azure pod scan fingerprint - Rule", "ESCU - Kubernetes Azure scan fingerprint - Rule", "ESCU - Amazon EKS Kubernetes activity by src ip - Response Task", "ESCU - GCP Kubernetes activity by src ip - Response Task", "ESCU - Get Notable History - Response Task"]
description = This story addresses detection against Kubernetes cluster fingerprint scan and attack by providing information on items such as source ip, user agent, cluster names.
narrative = Kubernetes is the most used container orchestration platform, this orchestration platform contains sensitve information and management priviledges of production workloads, microservices and applications. These searches allow operator to detect suspicious unauthenticated requests from the internet to kubernetes cluster.

[analytic_story://Kubernetes Security]
category = Cloud Security
last_updated = 2023-12-06
version = 1
references = ["https://kubernetes.io/docs/concepts/security/"]
maintainers = [{"company": "no", "email": "-", "name": "Patrick Bareiss"}]
spec_version = 3
searches = ["ESCU - Kubernetes Abuse of Secret by Unusual Location - Rule", "ESCU - Kubernetes Abuse of Secret by Unusual User Agent - Rule", "ESCU - Kubernetes Abuse of Secret by Unusual User Group - Rule", "ESCU - Kubernetes Abuse of Secret by Unusual User Name - Rule", "ESCU - Kubernetes Access Scanning - Rule", "ESCU - Kubernetes AWS detect suspicious kubectl calls - Rule", "ESCU - Kubernetes Create or Update Privileged Pod - Rule", "ESCU - Kubernetes Cron Job Creation - Rule", "ESCU - Kubernetes DaemonSet Deployed - Rule", "ESCU - Kubernetes Falco Shell Spawned - Rule", "ESCU - Kubernetes Node Port Creation - Rule", "ESCU - Kubernetes Pod Created in Default Namespace - Rule", "ESCU - Kubernetes Pod With Host Network Attachment - Rule", "ESCU - Kubernetes Scanning by Unauthenticated IP Address - Rule", "ESCU - Kubernetes Suspicious Image Pulling - Rule", "ESCU - Kubernetes Unauthorized Access - Rule"]
description = Kubernetes, as a container orchestration platform, faces unique security challenges. This story explores various tactics and techniques adversaries use to exploit Kubernetes environments, including attacking the control plane, exploiting misconfigurations, and compromising containerized applications.
narrative = Kubernetes, a widely used container orchestration system, presents a complex environment that can be targeted by adversaries. Key areas of concern include the control plane, worker nodes, and network communication. Attackers may attempt to exploit vulnerabilities in the Kubernetes API, misconfigured containers, or insecure network policies. The control plane, responsible for managing cluster operations, is a prime target. Compromising this can give attackers control over the entire cluster. Worker nodes, running the containerized applications, can be targeted to disrupt services or to gain access to sensitive data. Common attack vectors include exploiting vulnerabilities in container images, misconfigured role-based access controls (RBAC), exposed Kubernetes dashboards, and insecure network configurations. Attackers can also target the supply chain, injecting malicious code into container images or Helm charts. To mitigate these threats, it is essential to enforce robust security practices such as regular vulnerability scanning, implementing least privilege access, securing the control plane, network segmentation, and continuous monitoring for suspicious activities. Tools like Kubernetes Network Policies, Pod Security Policies, and third-party security solutions can provide additional layers of defense.

[analytic_story://Kubernetes Sensitive Object Access Activity]
category = Cloud Security
last_updated = 2020-05-20
version = 1
references = ["https://www.splunk.com/en_us/blog/security/approaching-kubernetes-security-detecting-kubernetes-scan-with-splunk.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - AWS EKS Kubernetes cluster sensitive object access - Rule", "ESCU - Kubernetes AWS detect service accounts forbidden failure access - Rule", "ESCU - Kubernetes Azure detect sensitive object access - Rule", "ESCU - Kubernetes Azure detect service accounts forbidden failure access - Rule", "ESCU - Kubernetes Azure detect suspicious kubectl calls - Rule", "ESCU - Kubernetes GCP detect sensitive object access - Rule", "ESCU - Kubernetes GCP detect service accounts forbidden failure access - Rule", "ESCU - Kubernetes GCP detect suspicious kubectl calls - Rule", "ESCU - Get Notable History - Response Task"]
description = This story addresses detection and response of accounts acccesing Kubernetes cluster sensitive objects such as configmaps or secrets providing information on items such as user user, group. object, namespace and authorization reason.
narrative = Kubernetes is the most used container orchestration platform, this orchestration platform contains sensitive objects within its architecture, specifically configmaps and secrets, if accessed by an attacker can lead to further compromise. These searches allow operator to detect suspicious requests against Kubernetes sensitive objects.

[analytic_story://Linux Living Off The Land]
category = Adversary Tactics
last_updated = 2022-07-27
version = 1
references = ["https://gtfobins.github.io/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Curl Download and Bash Execution - Rule", "ESCU - Linux Add Files In Known Crontab Directories - Rule", "ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux apt-get Privilege Escalation - Rule", "ESCU - Linux APT Privilege Escalation - Rule", "ESCU - Linux At Allow Config File Creation - Rule", "ESCU - Linux At Application Execution - Rule", "ESCU - Linux AWK Privilege Escalation - Rule", "ESCU - Linux Busybox Privilege Escalation - Rule", "ESCU - Linux c89 Privilege Escalation - Rule", "ESCU - Linux c99 Privilege Escalation - Rule", "ESCU - Linux Change File Owner To Root - Rule", "ESCU - Linux Clipboard Data Copy - Rule", "ESCU - Linux Common Process For Elevation Control - Rule", "ESCU - Linux Composer Privilege Escalation - Rule", "ESCU - Linux Cpulimit Privilege Escalation - Rule", "ESCU - Linux Csvtool Privilege Escalation - Rule", "ESCU - Linux Curl Upload File - Rule", "ESCU - Linux Decode Base64 to Shell - Rule", "ESCU - Linux Docker Privilege Escalation - Rule", "ESCU - Linux Edit Cron Table Parameter - Rule", "ESCU - Linux Emacs Privilege Escalation - Rule", "ESCU - Linux Find Privilege Escalation - Rule", "ESCU - Linux GDB Privilege Escalation - Rule", "ESCU - Linux Gem Privilege Escalation - Rule", "ESCU - Linux GNU Awk Privilege Escalation - Rule", "ESCU - Linux Ingress Tool Transfer Hunting - Rule", "ESCU - Linux Ingress Tool Transfer with Curl - Rule", "ESCU - Linux Make Privilege Escalation - Rule", "ESCU - Linux MySQL Privilege Escalation - Rule", "ESCU - Linux Node Privilege Escalation - Rule", "ESCU - Linux Obfuscated Files or Information Base64 Decode - Rule", "ESCU - Linux Octave Privilege Escalation - Rule", "ESCU - Linux OpenVPN Privilege Escalation - Rule", "ESCU - Linux PHP Privilege Escalation - Rule", "ESCU - Linux pkexec Privilege Escalation - Rule", "ESCU - Linux Possible Access Or Modification Of sshd Config File - Rule", "ESCU - Linux Possible Append Cronjob Entry on Existing Cronjob File - Rule", "ESCU - Linux Possible Cronjob Modification With Editor - Rule", "ESCU - Linux Possible Ssh Key File Creation - Rule", "ESCU - Linux Proxy Socks Curl - Rule", "ESCU - Linux Puppet Privilege Escalation - Rule", "ESCU - Linux RPM Privilege Escalation - Rule", "ESCU - Linux Ruby Privilege Escalation - Rule", "ESCU - Linux Service File Created In Systemd Directory - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Service Started Or Enabled - Rule", "ESCU - Linux Setuid Using Chmod Utility - Rule", "ESCU - Linux Sqlite3 Privilege Escalation - Rule", "ESCU - Linux SSH Authorized Keys Modification - Rule", "ESCU - Linux SSH Remote Services Script Execute - Rule", "ESCU - Suspicious Curl Network Connection - Rule"]
description = Linux Living Off The Land consists of binaries that may be used to bypass local security restrictions within misconfigured systems.
narrative = Similar to Windows LOLBAS project, the GTFOBins project focuses solely on Unix binaries that may be abused in multiple categories including Reverse Shell, File Upload, File Download and much more. These binaries are native to the operating system and the functionality is typically native. The behaviors are typically not malicious by default or vulnerable, but these are built in functionality of the applications. When reviewing any notables or hunting through mountains of events of interest, it's important to identify the binary, review command-line arguments, path of file, and capture any network and file modifications. Linux analysis may be a bit cumbersome due to volume and how process behavior is seen in EDR products. Piecing it together will require some effort.

[analytic_story://Linux Persistence Techniques]
category = Adversary Tactics
last_updated = 2021-12-17
version = 1
references = ["https://attack.mitre.org/techniques/T1053/", "https://kifarunix.com/scheduling-tasks-using-at-command-in-linux/", "https://gtfobins.github.io/gtfobins/at/", "https://www.cert.ssi.gouv.fr/uploads/CERTFR-2021-CTI-005.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Linux Add Files In Known Crontab Directories - Rule", "ESCU - Linux Add User Account - Rule", "ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux At Allow Config File Creation - Rule", "ESCU - Linux At Application Execution - Rule", "ESCU - Linux Change File Owner To Root - Rule", "ESCU - Linux Common Process For Elevation Control - Rule", "ESCU - Linux Doas Conf File Creation - Rule", "ESCU - Linux Doas Tool Execution - Rule", "ESCU - Linux Edit Cron Table Parameter - Rule", "ESCU - Linux File Created In Kernel Driver Directory - Rule", "ESCU - Linux File Creation In Init Boot Directory - Rule", "ESCU - Linux File Creation In Profile Directory - Rule", "ESCU - Linux Insert Kernel Module Using Insmod Utility - Rule", "ESCU - Linux Install Kernel Module Using Modprobe Utility - Rule", "ESCU - Linux NOPASSWD Entry In Sudoers File - Rule", "ESCU - Linux Persistence and Privilege Escalation Risk Behavior - Rule", "ESCU - Linux Possible Access Or Modification Of sshd Config File - Rule", "ESCU - Linux Possible Access To Credential Files - Rule", "ESCU - Linux Possible Access To Sudoers File - Rule", "ESCU - Linux Possible Append Command To At Allow Config File - Rule", "ESCU - Linux Possible Append Command To Profile Config File - Rule", "ESCU - Linux Possible Append Cronjob Entry on Existing Cronjob File - Rule", "ESCU - Linux Possible Cronjob Modification With Editor - Rule", "ESCU - Linux Possible Ssh Key File Creation - Rule", "ESCU - Linux Preload Hijack Library Calls - Rule", "ESCU - Linux Service File Created In Systemd Directory - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Service Started Or Enabled - Rule", "ESCU - Linux Setuid Using Chmod Utility - Rule", "ESCU - Linux Setuid Using Setcap Utility - Rule", "ESCU - Linux Shred Overwrite Command - Rule", "ESCU - Linux Sudo OR Su Execution - Rule", "ESCU - Linux Sudoers Tmp File Creation - Rule", "ESCU - Linux Visudo Utility Execution - Rule"]
description = Monitor for activities and techniques associated with maintaining persistence on a Linux system--a sign that an adversary may have compromised your environment.
narrative = Maintaining persistence is one of the first steps taken by attackers after the initial compromise. Attackers leverage various custom and built-in tools to ensure survivability and persistent access within a compromised enterprise. This Analytic Story provides searches to help you identify various behaviors used by attackers to maintain persistent access to a Linux environment.

[analytic_story://Linux Post-Exploitation]
category = Adversary Tactics
last_updated = 2021-12-03
version = 1
references = ["https://attack.mitre.org/matrices/enterprise/linux/"]
maintainers = [{"company": "no", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Suspicious Linux Discovery Commands - Rule"]
description = This analytic story identifies popular Linux post exploitation tools such as autoSUID, LinEnum, LinPEAS, Linux Exploit Suggesters, MimiPenguin.
narrative = These tools allow operators find possible exploits or paths for privilege escalation based on SUID binaries, user permissions, kernel version and distro version.

[analytic_story://Linux Privilege Escalation]
category = Adversary Tactics
last_updated = 2021-12-17
version = 1
references = ["https://attack.mitre.org/tactics/TA0004/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Linux Add Files In Known Crontab Directories - Rule", "ESCU - Linux Add User Account - Rule", "ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux apt-get Privilege Escalation - Rule", "ESCU - Linux APT Privilege Escalation - Rule", "ESCU - Linux At Allow Config File Creation - Rule", "ESCU - Linux At Application Execution - Rule", "ESCU - Linux AWK Privilege Escalation - Rule", "ESCU - Linux Busybox Privilege Escalation - Rule", "ESCU - Linux c89 Privilege Escalation - Rule", "ESCU - Linux c99 Privilege Escalation - Rule", "ESCU - Linux Change File Owner To Root - Rule", "ESCU - Linux Common Process For Elevation Control - Rule", "ESCU - Linux Composer Privilege Escalation - Rule", "ESCU - Linux Cpulimit Privilege Escalation - Rule", "ESCU - Linux Csvtool Privilege Escalation - Rule", "ESCU - Linux Doas Conf File Creation - Rule", "ESCU - Linux Doas Tool Execution - Rule", "ESCU - Linux Docker Privilege Escalation - Rule", "ESCU - Linux Edit Cron Table Parameter - Rule", "ESCU - Linux Emacs Privilege Escalation - Rule", "ESCU - Linux File Created In Kernel Driver Directory - Rule", "ESCU - Linux File Creation In Init Boot Directory - Rule", "ESCU - Linux File Creation In Profile Directory - Rule", "ESCU - Linux Find Privilege Escalation - Rule", "ESCU - Linux GDB Privilege Escalation - Rule", "ESCU - Linux Gem Privilege Escalation - Rule", "ESCU - Linux GNU Awk Privilege Escalation - Rule", "ESCU - Linux Insert Kernel Module Using Insmod Utility - Rule", "ESCU - Linux Install Kernel Module Using Modprobe Utility - Rule", "ESCU - Linux Make Privilege Escalation - Rule", "ESCU - Linux MySQL Privilege Escalation - Rule", "ESCU - Linux Node Privilege Escalation - Rule", "ESCU - Linux NOPASSWD Entry In Sudoers File - Rule", "ESCU - Linux Octave Privilege Escalation - Rule", "ESCU - Linux OpenVPN Privilege Escalation - Rule", "ESCU - Linux Persistence and Privilege Escalation Risk Behavior - Rule", "ESCU - Linux PHP Privilege Escalation - Rule", "ESCU - Linux pkexec Privilege Escalation - Rule", "ESCU - Linux Possible Access Or Modification Of sshd Config File - Rule", "ESCU - Linux Possible Access To Credential Files - Rule", "ESCU - Linux Possible Access To Sudoers File - Rule", "ESCU - Linux Possible Append Command To At Allow Config File - Rule", "ESCU - Linux Possible Append Command To Profile Config File - Rule", "ESCU - Linux Possible Append Cronjob Entry on Existing Cronjob File - Rule", "ESCU - Linux Possible Cronjob Modification With Editor - Rule", "ESCU - Linux Possible Ssh Key File Creation - Rule", "ESCU - Linux Preload Hijack Library Calls - Rule", "ESCU - Linux Puppet Privilege Escalation - Rule", "ESCU - Linux RPM Privilege Escalation - Rule", "ESCU - Linux Ruby Privilege Escalation - Rule", "ESCU - Linux Service File Created In Systemd Directory - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Service Started Or Enabled - Rule", "ESCU - Linux Setuid Using Chmod Utility - Rule", "ESCU - Linux Setuid Using Setcap Utility - Rule", "ESCU - Linux Shred Overwrite Command - Rule", "ESCU - Linux Sqlite3 Privilege Escalation - Rule", "ESCU - Linux Sudo OR Su Execution - Rule", "ESCU - Linux Sudoers Tmp File Creation - Rule", "ESCU - Linux Visudo Utility Execution - Rule"]
description = Monitor for and investigate activities that may be associated with a Linux privilege-escalation attack, including unusual processes running on endpoints, schedule task, services, setuid, root execution and more.
narrative = Privilege escalation is a "land-and-expand" technique, wherein an adversary gains an initial foothold on a host and then exploits its weaknesses to increase his privileges. The motivation is simple: certain actions on a Linux machine--such as installing software--may require higher-level privileges than those the attacker initially acquired. By increasing his privilege level, the attacker can gain the control required to carry out his malicious ends. This Analytic Story provides searches to detect and investigate behaviors that attackers may use to elevate their privileges in your environment.

[analytic_story://Linux Rootkit]
category = Adversary Tactics
last_updated = 2022-07-27
version = 1
references = ["https://attack.mitre.org/techniques/T1014/", "https://content.fireeye.com/apt-41/rpt-apt41", "https://medium.com/chronicle-blog/winnti-more-than-just-windows-and-gates-e4f03436031a"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Linux File Created In Kernel Driver Directory - Rule", "ESCU - Linux Insert Kernel Module Using Insmod Utility - Rule", "ESCU - Linux Install Kernel Module Using Modprobe Utility - Rule", "ESCU - Linux Kernel Module Enumeration - Rule"]
description = Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information.
narrative = Rootkits or rootkit enabling functionality may reside at the user or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware. Rootkits have been seen for Windows, Linux, and Mac OS X systems. Linux rootkits may not standout as much as a Windows rootkit, therefore understanding what kernel modules are installed today and monitoring for new is important. As with any rootkit, it may blend in using a common kernel name or variation of legitimate names.

[analytic_story://Living Off The Land]
category = Adversary Tactics
last_updated = 2022-03-16
version = 2
references = ["https://lolbas-project.github.io/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Lou Stella"}]
spec_version = 3
searches = ["ESCU - BITS Job Persistence - Rule", "ESCU - BITSAdmin Download File - Rule", "ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - CertUtil Download With VerifyCtl and Split Arguments - Rule", "ESCU - Certutil exe certificate extraction - Rule", "ESCU - CertUtil With Decode Argument - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Control Loading from World Writable Directory - Rule", "ESCU - Creation of Shadow Copy with wmic and powershell - Rule", "ESCU - Detect HTML Help Renamed - Rule", "ESCU - Detect HTML Help Spawn Child Process - Rule", "ESCU - Detect HTML Help URL in Command Line - Rule", "ESCU - Detect HTML Help Using InfoTech Storage Handlers - Rule", "ESCU - Detect mshta inline hta execution - Rule", "ESCU - Detect mshta renamed - Rule", "ESCU - Detect MSHTA Url in Command Line - Rule", "ESCU - Detect Regasm Spawning a Process - Rule", "ESCU - Detect Regasm with Network Connection - Rule", "ESCU - Detect Regasm with no Command Line Arguments - Rule", "ESCU - Detect Regsvcs Spawning a Process - Rule", "ESCU - Detect Regsvcs with Network Connection - Rule", "ESCU - Detect Regsvcs with No Command Line Arguments - Rule", "ESCU - Detect Regsvr32 Application Control Bypass - Rule", "ESCU - Detect Rundll32 Application Control Bypass - advpack - Rule", "ESCU - Detect Rundll32 Application Control Bypass - setupapi - Rule", "ESCU - Detect Rundll32 Application Control Bypass - syssetup - Rule", "ESCU - Detect Rundll32 Inline HTA Execution - Rule", "ESCU - Disable Schedule Task - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Esentutl SAM Copy - Rule", "ESCU - Eventvwr UAC Bypass - Rule", "ESCU - Living Off The Land - Rule", "ESCU - LOLBAS With Network Traffic - Rule", "ESCU - MacOS LOLbin - Rule", "ESCU - MacOS plutil - Rule", "ESCU - Mmc LOLBAS Execution Process Spawn - Rule", "ESCU - Mshta spawning Rundll32 OR Regsvr32 Process - Rule", "ESCU - Ntdsutil Export NTDS - Rule", "ESCU - Reg exe Manipulating Windows Services Registry Keys - Rule", "ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule", "ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule", "ESCU - Remote WMI Command Attempt - Rule", "ESCU - Rundll32 Control RunDLL Hunt - Rule", "ESCU - Rundll32 Control RunDLL World Writable Directory - Rule", "ESCU - Rundll32 Create Remote Thread To A Process - Rule", "ESCU - Rundll32 CreateRemoteThread In Browser - Rule", "ESCU - Rundll32 DNSQuery - Rule", "ESCU - Rundll32 Process Creating Exe Dll Files - Rule", "ESCU - Rundll32 Shimcache Flush - Rule", "ESCU - RunDLL Loading DLL By Ordinal - Rule", "ESCU - Schedule Task with HTTP Command Arguments - Rule", "ESCU - Schedule Task with Rundll32 Command Trigger - Rule", "ESCU - Scheduled Task Creation on Remote Endpoint using At - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Scheduled Task Initiation on Remote Endpoint - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Services LOLBAS Execution Process Spawn - Rule", "ESCU - Suspicious IcedID Rundll32 Cmdline - Rule", "ESCU - Suspicious microsoft workflow compiler rename - Rule", "ESCU - Suspicious microsoft workflow compiler usage - Rule", "ESCU - Suspicious msbuild path - Rule", "ESCU - Suspicious MSBuild Rename - Rule", "ESCU - Suspicious MSBuild Spawn - Rule", "ESCU - Suspicious mshta child process - Rule", "ESCU - Suspicious mshta spawn - Rule", "ESCU - Suspicious Regsvr32 Register Suspicious Path - Rule", "ESCU - Suspicious Rundll32 dllregisterserver - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Svchost LOLBAS Execution Process Spawn - Rule", "ESCU - Windows Binary Proxy Execution Mavinject DLL Injection - Rule", "ESCU - Windows COM Hijacking InprocServer32 Modification - Rule", "ESCU - Windows Diskshadow Proxy Execution - Rule", "ESCU - Windows DLL Search Order Hijacking Hunt - Rule", "ESCU - Windows DLL Search Order Hijacking Hunt with Sysmon - Rule", "ESCU - Windows DLL Search Order Hijacking with iscsicpl - Rule", "ESCU - Windows Identify Protocol Handlers - Rule", "ESCU - Windows Indirect Command Execution Via forfiles - Rule", "ESCU - Windows Indirect Command Execution Via pcalua - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule", "ESCU - Windows InstallUtil Remote Network Connection - Rule", "ESCU - Windows InstallUtil Uninstall Option - Rule", "ESCU - Windows InstallUtil Uninstall Option with Network - Rule", "ESCU - Windows InstallUtil URL in Command Line - Rule", "ESCU - Windows Known Abused DLL Created - Rule", "ESCU - Windows MOF Event Triggered Execution via WMI - Rule", "ESCU - Windows Odbcconf Hunting - Rule", "ESCU - Windows Odbcconf Load DLL - Rule", "ESCU - Windows Odbcconf Load Response File - Rule", "ESCU - Windows System Binary Proxy Execution Compiled HTML File Decompile - Rule", "ESCU - Windows System Script Proxy Execution Syncappvpublishingserver - Rule", "ESCU - Windows UAC Bypass Suspicious Child Process - Rule", "ESCU - Windows UAC Bypass Suspicious Escalation Behavior - Rule", "ESCU - WSReset UAC Bypass - Rule"]
description = Leverage analytics that allow you to identify the presence of an adversary leveraging native applications within your environment.
narrative = Living Off The Land refers to an adversary methodology of using native applications already installed on the target operating system to achieve their objective. Native utilities provide the adversary with reduced chances of detection by antivirus software or EDR tools. This allows the adversary to blend in with native process behavior.

[analytic_story://Local Privilege Escalation With KrbRelayUp]
category = Privilege Escalation
last_updated = 2022-04-28
version = 1
references = ["https://github.com/Dec0ne/KrbRelayUp", "https://gist.github.com/tothi/bf6c59d6de5d0c9710f23dae5750c4b9", "https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html", "https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/", "https://github.com/cube0x0/KrbRelay"]
maintainers = [{"company": "Mauricio Velazco, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Computer Account Created by Computer Account - Rule", "ESCU - Windows Computer Account Requesting Kerberos Ticket - Rule", "ESCU - Windows Computer Account With SPN - Rule", "ESCU - Windows Kerberos Local Successful Logon - Rule", "ESCU - Windows KrbRelayUp Service Creation - Rule"]
description = KrbRelayUp is a tool that allows local privilege escalation from low-priviliged domain user to local system on domain-joined computers.
narrative = In October 2021, James Forshaw from Googles Project Zero released a research  blog post titled `Using Kerberos for Authentication Relay Attacks`. This research introduced, for the first time, ways to make Windows authenticate to a different Service Principal Name (SPN) than what would normally be derived from the hostname the client is connecting to. This effectively proved that relaying Kerberos authentication is possible\\. In April 2022, security researcher Mor Davidovich released a tool named KrbRelayUp which implements Kerberos relaying as well as other known Kerberos techniques with the goal of escalating privileges from a low-privileged domain user on a domain-joined device and obtain a SYSTEM shell.

[analytic_story://LockBit Ransomware]
category = Malware
last_updated = 2023-01-16
version = 1
references = ["https://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html", "https://news.sophos.com/en-us/2020/04/24/lockbit-ransomware-borrows-tricks-to-keep-up-with-revil-and-maze/", "https://www.cybereason.com/blog/threat-analysis-report-lockbit-2.0-all-paths-lead-to-ransom", "https://www.trendmicro.com/en_us/research/22/g/lockbit-ransomware-group-augments-its-latest-variant--lockbit-3-.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMLUA Or CMSTPLUA UAC Bypass - Rule", "ESCU - Cobalt Strike Named Pipes - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Fsutil Zeroing File - Rule", "ESCU - High Process Termination Frequency - Rule", "ESCU - Known Services Killed by Ransomware - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - Ransomware Notes bulk creation - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - UAC Bypass With Colorui COM Object - Rule", "ESCU - Wbemprox COM Object Execution - Rule", "ESCU - Windows Modify Registry Default Icon Setting - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the LockBit ransomware, including looking for file writes (file encryption and ransomware notes), deleting services, terminating processes, registry key modification and more.
narrative = LockBit ransomware was first seen in 2019. This ransomware was used by cybercriminal in targeting multiple sectors and organizations. Lockbit is one of the ransomware being offered as a Ransomware-as-a-Service(RaaS) and also known to affiliates to implement the 'double extortion' techniques by uploading the stolen and sensitive victim information to their dark website and then threatening to sell/release it in public if their demands are not met. LockBit Ransomware advertised opportunities for threat actors that could provide credential access via RDP and VPN. Aside from this it is also uses threat emulation like Cobalt Strike and Metasploit to gain foot hold to the targeted host and persist if needed.

[analytic_story://Log4Shell CVE-2021-44228]
category = Adversary Tactics
last_updated = 2021-12-11
version = 1
references = ["https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/", "https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j", "https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/", "https://www.lunasec.io/docs/blog/log4j-zero-day/", "https://www.splunk.com/en_us/blog/security/log-jammin-log4j-2-rce.html"]
maintainers = [{"company": "no", "email": "-", "name": "Jose Hernandez"}]
spec_version = 3
searches = ["ESCU - Any Powershell DownloadFile - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Curl Download and Bash Execution - Rule", "ESCU - Java Class File download by Java User Agent - Rule", "ESCU - Linux Java Spawning Shell - Rule", "ESCU - Log4Shell CVE-2021-44228 Exploitation - Rule", "ESCU - Outbound Network Connection from Java Using Default Ports - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - Wget Download and Bash Execution - Rule", "ESCU - Windows Java Spawning Shells - Rule", "ESCU - Detect Outbound LDAP Traffic - Rule", "ESCU - Hunting for Log4Shell - Rule", "ESCU - Log4Shell JNDI Payload Injection Attempt - Rule", "ESCU - Log4Shell JNDI Payload Injection with Outbound Connection - Rule"]
description = Log4Shell or CVE-2021-44228 is a Remote Code Execution (RCE) vulnerability in the Apache Log4j library, a widely used and ubiquitous logging framework for Java. The vulnerability allows an attacker who can control log messages to execute arbitrary code loaded from attacker-controlled servers and we anticipate that most apps using the Log4j library will meet this condition.
narrative = In late November 2021, Chen Zhaojun of Alibaba identified a remote code execution vulnerability. Previous work was seen in a 2016 Blackhat talk by Alvaro Munoz and Oleksandr Mirosh called ["A Journey from JNDI/LDAP Manipulation to Remote Code Execution Dream Land"](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf). Reported under the CVE ID : CVE-2021-44228, released to the public on December 10, 2021. The vulnerability is exploited through improper deserialization of user input passed into the framework. It permits remote code execution and it can allow an attacker to leak sensitive data, such as environment variables, or execute malicious software on the target system.

[analytic_story://Malicious PowerShell]
category = Adversary Tactics
last_updated = 2017-08-23
version = 5
references = ["https://blogs.mcafee.com/mcafee-labs/malware-employs-powershell-to-infect-systems/", "https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic-national-committee/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Suspicious Powershell Command-Line Arguments - Rule", "ESCU - Any Powershell DownloadFile - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - Detect Certify With PowerShell Script Block Logging - Rule", "ESCU - Detect Empire with PowerShell Script Block Logging - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - GetLocalUser with PowerShell Script Block - Rule", "ESCU - GetWmiObject User Account with PowerShell Script Block - Rule", "ESCU - Malicious Powershell Executed As A Service - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Malicious PowerShell Process With Obfuscation Techniques - Rule", "ESCU - Possible Lateral Movement PowerShell Spawn - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - Powershell COM Hijacking InprocServer32 Modification - Rule", "ESCU - Powershell Creating Thread Mutex - Rule", "ESCU - PowerShell Domain Enumeration - Rule", "ESCU - PowerShell Enable PowerShell Remoting - Rule", "ESCU - Powershell Enable SMB1Protocol Feature - Rule", "ESCU - Powershell Execute COM Object - Rule", "ESCU - Powershell Fileless Process Injection via GetProcAddress - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - PowerShell Invoke CIMMethod CIMSession - Rule", "ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule", "ESCU - Powershell Processing Stream Of Data - Rule", "ESCU - PowerShell Script Block With URL Chain - Rule", "ESCU - Powershell Using memory As Backing Store - Rule", "ESCU - PowerShell WebRequest Using Memory Stream - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - ServicePrincipalNames Discovery with PowerShell - Rule", "ESCU - Set Default PowerShell Execution Policy To Unrestricted or Bypass - Rule", "ESCU - Unloading AMSI via Reflection - Rule", "ESCU - WMI Recon Running Process Or Services - Rule", "ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Attackers are finding stealthy ways "live off the land," leveraging utilities and tools that come standard on the endpoint--such as PowerShell--to achieve their goals without downloading binary files. These searches can help you detect and investigate PowerShell command-line options that may be indicative of malicious intent.
narrative = The searches in this Analytic Story monitor for parameters often used for malicious purposes. It is helpful to understand how often the notable events generated by this story occur, as well as the commonalities between some of these events. These factors may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. Likewise, it is important to determine whether the issue is restricted to a single user/system or is broader in scope. \
The following factors may assist you in determining whether the event is malicious: \
1. Country of origin \
1. Responsible party \
1. Fully qualified domain names associated with the external IP address \
1. Registration of fully qualified domain names associated with external IP address \
Determining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you answer some questions surrounding the attacker and details related to the external system. In addition, there are various sources--such as VirusTotal&#151; that can provide some reputation information on the IP address or domain name, which can assist in determining whether the event is malicious. Finally, determining whether there are other events associated with the IP address may help connect data points or show other events that should be brought into scope. \
Gathering data on the system of interest can sometimes help you quickly determine whether something suspicious is happening. Some of these items include finding out who else may have recently logged into the system, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted. \
Often, a simple inspection of the process name and path can tell you if the system has been compromised. For example, if `svchost.exe` is found running from a location other than `C:\Windows\System32`, it is likely something malicious designed to hide in plain sight when cursorily reviewing process names. Similarly, if the process itself seems legitimate, but the parent process is running from the temporary browser cache, that could be indicative of activity initiated via a compromised website a user visited. \
It can also be very helpful to examine various behaviors of the process of interest or the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see if the parent to that process spawned other processes that might be worth further scrutiny. If a process is suspect, a review of the network connections made in and around the time of the event and/or whether the process spawned any child processes could be helpful, as well. \
In the event a system is suspected of having been compromised via a malicious website, we suggest reviewing the browsing activity from that system around the time of the event. If categories are given for the URLs visited, that can help you zero in on possible malicious sites. \
Most recently we have added new content related to PowerShell Script Block logging, Windows EventCode 4104. Script block logging presents the deobfuscated and raw script executed on an endpoint. The analytics produced were tested against commonly used attack frameworks - PowerShell-Empire, Cobalt Strike and Covenant. In addition, we sampled publicly available samples that utilize PowerShell and validated coverage. The analytics are here to identify suspicious usage, cmdlets, or script values. 4104 events are enabled via the Windows registry and may generate a large volume of data if enabled globally. Enabling on critical systems or a limited set may be best. During triage of 4104 events, review parallel processes for other processes and command executed. Identify any file modifications and network communication and review accordingly. Fortunately, we get the full script to determine the level of threat identified.

[analytic_story://Masquerading - Rename System Utilities]
category = Adversary Tactics
last_updated = 2021-04-26
version = 1
references = ["https://attack.mitre.org/techniques/T1036/003/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Execution of File With Spaces Before Extension - Rule", "ESCU - Suspicious Rundll32 Rename - Rule", "ESCU - Execution of File with Multiple Extensions - Rule", "ESCU - Sdelete Application Execution - Rule", "ESCU - Suspicious microsoft workflow compiler rename - Rule", "ESCU - Suspicious msbuild path - Rule", "ESCU - Suspicious MSBuild Rename - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Windows DotNet Binary in Non Standard Path - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule"]
description = Adversaries may rename legitimate system utilities to try to evade security mechanisms concerning the usage of those utilities.
narrative = Security monitoring and control mechanisms may be in place for system utilities adversaries are capable of abusing. It may be possible to bypass those security mechanisms by renaming the utility prior to utilization (ex: rename rundll32.exe). An alternative case occurs when a legitimate utility is copied or moved to a different directory and renamed to avoid detections based on system utilities executing from non-standard paths.\
The following content is here to assist with binaries within `system32` or `syswow64` being moved to a new location or an adversary bringing a the binary in to execute.\
There will be false positives as some native Windows processes are moved or ran by third party applications from different paths. If file names are mismatched between the file name on disk and that of the binarys PE metadata, this is a likely indicator that a binary was renamed after it was compiled. Collecting and comparing disk and resource filenames for binaries by looking to see if the InternalName, OriginalFilename, and or ProductName match what is expected could provide useful leads, but may not always be indicative of malicious activity. Do not focus on the possible names a file could have, but instead on the command-line arguments that are known to be used and are distinct because it will have a better rate of detection.

[analytic_story://MetaSploit]
category = Adversary Tactics
last_updated = 2022-11-21
version = 1
references = ["https://github.com/rapid7/metasploit-framework", "https://www.varonis.com/blog/what-is-metasploit"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Powershell Load Module in Meterpreter - Rule", "ESCU - Windows Apache Benchmark Binary - Rule"]
description = The following analytic story highlights content related directly to MetaSploit, which may be default configurations attributed to MetaSploit or behaviors of known knowns that are related.
narrative = The Metasploit framework is a very powerful tool which can be used by cybercriminals as well as ethical hackers to probe systematic vulnerabilities on networks and servers. Because it is an open-source framework, it can be easily customized and used with most operating systems.\
The Metasploit Project was undertaken in 2003 by H.D. Moore for use as a Perl-based portable network tool, with assistance from core developer Matt Miller. It was fully converted to Ruby by 2007, and the license was acquired by Rapid7 in 2009, where it remains as part of the Boston-based company repertoire of IDS signature development and targeted remote exploit, fuzzing, anti-forensic, and evasion tools.\
Portions of these other tools reside within the Metasploit framework, which is built into the Kali Linux OS. Rapid7 has also developed two proprietary OpenCore tools, Metasploit Pro, Metasploit Express.\
This framework has become the go-to exploit development and mitigation tool. Prior to Metasploit, pen testers had to perform all probes manually by using a variety of tools that may or may not have supported the platform they were testing, writing their own code by hand, and introducing it onto networks manually. Remote testing was virtually unheard of, and that limited a security specialist reach to the local area and companies spending a fortune on in-house IT or security consultants. (ref. Varonis)

[analytic_story://Meterpreter]
category = Adversary Tactics
last_updated = 2021-06-08
version = 1
references = ["https://www.offensive-security.com/metasploit-unleashed/about-meterpreter/", "https://doubleoctopus.com/security-wiki/threats-and-tools/meterpreter/", "https://www.rapid7.com/products/metasploit/"]
maintainers = [{"company": "no", "email": "-", "name": "Michael Hart"}]
spec_version = 3
searches = ["ESCU - Excessive distinct processes from Windows Temp - Rule", "ESCU - Excessive number of taskhost processes - Rule"]
description = Meterpreter provides red teams, pen testers and threat actors interactive access to a compromised host to run commands, upload payloads, download files, and other actions.
narrative = This Analytic Story supports you to detect Tactics, Techniques and Procedures (TTPs) from Meterpreter. Meterpreter is a Metasploit payload for remote execution that leverages DLL injection to make it extremely difficult to detect.  Since the software runs in memory, no new processes are created upon injection.  It also leverages encrypted communication channels.\
Meterpreter enables the operator to remotely run commands on the target machine, upload payloads, download files, dump password hashes, and much more.  It is difficult to determine from the forensic evidence what actions the operator performed.  Splunk Research, however, has observed anomalous behaviors on the compromised hosts that seem to only appear when Meterpreter is executing various commands.  With that, we have written new detections targeted to these detections.\
While investigating a detection related to this analytic story, please bear in mind that the detections look for anomalies in system behavior.  It will be imperative to look for other signs in the endpoint and network logs for lateral movement, discovery and other actions to confirm that the host was compromised and a remote actor used it to progress on their objectives.

[analytic_story://Microsoft MSHTML Remote Code Execution CVE-2021-40444]
category = Adversary Tactics
last_updated = 2021-09-08
version = 1
references = ["https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/09/windows-mshtml-zero-day-actively-exploited-mitigations-required/", "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444", "https://www.echotrail.io/insights/search/control.exe"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Control Loading from World Writable Directory - Rule", "ESCU - MSHTML Module Load in Office Product - Rule", "ESCU - Office Product Writing cab or inf - Rule", "ESCU - Office Spawning Control - Rule", "ESCU - Rundll32 Control RunDLL Hunt - Rule", "ESCU - Rundll32 Control RunDLL World Writable Directory - Rule"]
description = CVE-2021-40444 is a remote code execution vulnerability in MSHTML, recently used to delivery targeted spearphishing documents.
narrative = Microsoft is aware of targeted attacks that attempt to exploit this vulnerability, CVE-2021-40444 by using specially-crafted Microsoft Office documents. MSHTML is a software component used to render web pages on Windows. Although it is 2019s most commonly associated with Internet Explorer, it is also used in other software.  CVE-2021-40444 received a CVSS score of 8.8 out of 10. MSHTML is the beating heart of Internet Explorer, the vulnerability also exists in that browser. Although given its limited use, there is little risk of infection by that vector. Microsoft Office applications use the MSHTML component to display web content in Office documents. The attack depends on MSHTML loading a specially crafted ActiveX control when the target opens a malicious Office document. The loaded ActiveX control can then run arbitrary code to infect the system with more malware. At the moment all supported Windows versions are vulnerable. Since there is no patch available yet, Microsoft proposes a few methods to block these attacks. \
1. Disable the installation of all ActiveX controls in Internet Explorer via the registry. Previously-installed ActiveX controls will still run, but no new ones will be added, including malicious ones. Open documents from the Internet in Protected View or Application Guard for Office, both of which prevent the current attack. This is a default setting but it may have been changed.

[analytic_story://Microsoft SharePoint Server Elevation of Privilege CVE-2023-29357]
category = Vulnerability
last_updated = 2023-09-27
version = 1
references = ["https://socradar.io/microsoft-sharepoint-server-elevation-of-privilege-vulnerability-exploit-cve-2023-29357/", "https://github.com/Chocapikk/CVE-2023-29357"]
maintainers = [{"company": "Gowthamaraj Rajendran, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Microsoft SharePoint Server Elevation of Privilege - Rule"]
description = This analytic story focuses on the Microsoft SharePoint Server vulnerability CVE-2023-29357, which allows for an elevation of privilege due to improper handling of authentication tokens. Exploitation of this vulnerability could lead to a serious security breach where an attacker might gain privileged access to the SharePoint environment, potentially leading to data theft or other malicious activities. This story is associated with the detection `Microsoft SharePoint Server Elevation of Privilege` which identifies attempts to exploit this vulnerability.
narrative = Microsoft SharePoint Server is a widely used web-based collaborative platform. The vulnerability CVE-2023-29357 exposes a flaw in the handling of authentication tokens, allowing an attacker to escalate privileges and gain unauthorized access to the SharePoint environment. This could potentially lead to data theft, unauthorized system modifications, or other malicious activities. Organizations are urged to apply immediate patches and conduct regular system assessments to ensure security.

[analytic_story://Microsoft Support Diagnostic Tool Vulnerability CVE-2022-30190]
category = Adversary Tactics
last_updated = 2022-05-31
version = 1
references = ["https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/", "https://isc.sans.edu/diary/rss/28694", "https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e", "https://twitter.com/nao_sec/status/1530196847679401984?s=20\u0026t=ZiXYI4dQuA-0_dzQzSUb3A", "https://app.any.run/tasks/713f05d2-fe78-4b9d-a744-f7c133e3fafb/", "https://www.virustotal.com/gui/file/4a24048f81afbe9fb62e7a6a49adbd1faf41f266b5f9feecdceb567aec096784/detection", "https://strontic.github.io/xcyclopedia/library/msdt.exe-152D4C9F63EFB332CCB134C6953C0104.html"]
maintainers = [{"company": "Teoderick Contreras, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Command and Scripting Interpreter Hunting Path Traversal - Rule", "ESCU - Windows Command and Scripting Interpreter Path Traversal Exec - Rule", "ESCU - Windows Execute Arbitrary Commands with MSDT - Rule", "ESCU - Windows Office Product Spawning MSDT - Rule"]
description = On Monday May 30, 2022, Microsoft issued CVE-2022-30190 regarding the Microsoft Support Diagnostic Tool (MSDT) in Windows vulnerability.
narrative = A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user''s rights.

[analytic_story://Monitor for Updates]
category = Best Practices
last_updated = 2017-09-15
version = 1
references = ["https://learn.cisecurity.org/20-controls-download"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - No Windows Updates in a time frame - Rule", "ESCU - Get Notable History - Response Task"]
description = Monitor your enterprise to ensure that your endpoints are being patched and updated. Adversaries notoriously exploit known vulnerabilities that could be mitigated by applying routine security patches.
narrative = It is a common best practice to ensure that endpoints are being patched and updated in a timely manner, in order to reduce the risk of compromise via a publicly disclosed vulnerability. Timely application of updates/patches is important to eliminate known vulnerabilities that may be exploited by various threat actors.\
Searches in this analytic story are designed to help analysts monitor endpoints for system patches and/or updates. This helps analysts identify any systems that are not successfully updated in a timely matter.\
Microsoft releases updates for Windows systems on a monthly cadence. They should be installed as soon as possible after following internal testing and validation procedures. Patches and updates for other systems or applications are typically released as needed.

[analytic_story://MOVEit Transfer Critical Vulnerability]
category = Adversary Tactics
last_updated = 2023-06-01
version = 1
references = ["https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023", "https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer/", "https://www.bleepingcomputer.com/news/security/new-moveit-transfer-zero-day-mass-exploited-in-data-theft-attacks/", "https://www.reddit.com/r/sysadmin/comments/13wxuej/critical_vulnerability_moveit_file_transfer/", "https://gist.github.com/MHaggis/faa672b1929a23fc48fc0ee47585cc48"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows MOVEit Transfer Writing ASPX - Rule"]
description = A critical zero-day vulnerability has been discovered in the MOVEit Transfer file transfer software, widely used by businesses and developers worldwide. The vulnerability has been exploited by unknown threat actors to perform mass data theft from organizations. Progress Software Corporation, the developer of MOVEit, has issued a security advisory urging customers to take immediate action to protect their environments. They recommend blocking external traffic to ports 80 and 445 on the MOVEit server, and to check the c:\MOVEitTransfer\wwwroot\ folder for unusual files. A patch is currently released.
narrative = Hackers have been actively exploiting a zero-day vulnerability found in the MOVEit Transfer software. This software, developed by Progress Software Corporation, a US-based company and its subsidiary Ipswitch, is a managed file transfer solution. It is used by thousands of organizations worldwide, including Chase, Disney, GEICO, and MLB, and by 3.5 million developers. The software allows for secure file transfers between business partners and customers using SFTP, SCP, and HTTP-based uploads.\
The zero-day vulnerability has been exploited to steal data on a large scale from various organizations. The identity of the threat actors and the exact timeline of the exploitation remains unclear. However, it has been confirmed that multiple organizations have experienced breaches and data theft.\
In response to this critical situation, Progress released a security advisory warning customers of the vulnerability and providing mitigation strategies while a patch has been released. They urged customers to take immediate action to protect their MOVEit environments. They suggested blocking external traffic to ports 80 and 445 on the MOVEit server and checking the c:\MOVEitTransfer\wwwroot\ folder for unexpected files, including backups or large file downloads.\
Blocking these ports will prevent external access to the web UI, prevent some MOVEit Automation tasks from working, block APIs, and prevent the Outlook MOVEit plugin from working. However, SFTP and FTP/s protocols can continue to be used for file transfers.\
There is currently no detailed information about the zero-day vulnerability. But based on the ports blocked and the specific location to check for unusual files, the flaw is likely a web-facing vulnerability.\
While Progress has officially confirmed that the vulnerability is being actively exploited, it is clear from several reports that multiple organizations have already had data stolen using this zero-day vulnerability. The exploitation appears very similar to the mass exploitation of a GoAnywhere MFT zero-day in January 2023 and the December 2020 zero-day exploitation of Accellion FTA servers. These were both managed file transfer platforms heavily exploited by the Clop ransomware gang to steal data and extort organizations.

[analytic_story://Netsh Abuse]
category = Abuse
last_updated = 2017-01-05
version = 1
references = ["https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb490939(v=technet.10)", "https://htmlpreview.github.io/?https://github.com/MatthewDemaske/blogbackup/blob/master/netshell.html", "https://blogs.jpcert.or.jp/en/2016/01/windows-commands-abused-by-attackers.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Processes created by netsh - Rule", "ESCU - Processes launching netsh - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Detect activities and various techniques associated with the abuse of `netsh.exe`, which can disable local firewall settings or set up a remote connection to a host from an infected system.
narrative = It is a common practice for attackers of all types to leverage native Windows tools and functionality to execute commands for malicious reasons. One such tool on Windows OS is `netsh.exe`,a command-line scripting utility that allows you to--either locally or remotely--display or modify the network configuration of a computer that is currently running. `Netsh.exe` can be used to discover and disable local firewall settings. It can also be used to set up a remote connection to a host from an infected system.\
To get started, run the detection search to identify parent processes of `netsh.exe`.

[analytic_story://Network Discovery]
category = Malware
last_updated = 2022-02-14
version = 1
references = ["https://attack.mitre.org/techniques/T1016/", "https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf", "https://researchcenter.paloaltonetworks.com/2018/09/unit42-xbash-combines-botnet-ransomware-coinmining-worm-targets-linux-windows/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Linux System Network Discovery - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the network discovery, including looking for network configuration, settings such as IP, MAC address, firewall settings and many more.
narrative = Adversaries may use the information from System Network Configuration Discovery during automated discovery to shape follow-on behaviors, including determining certain access within the target network and what actions to do next.

[analytic_story://NjRAT]
category = Malware
last_updated = 2023-09-07
version = 2
references = ["https://www.checkpoint.com/cyber-hub/threat-prevention/what-is-malware/what-is-njrat-malware/#:~:text=NJRat%20%E2%80%94%20also%20known%20as%20Bladabindi,malware%20variant%20in%20March%202023.", "https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - Allow Network Discovery In Firewall - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Disable Registry Tool - Rule", "ESCU - Disabling CMD Application - Rule", "ESCU - Disabling SystemRestore In Registry - Rule", "ESCU - Disabling Task Manager - Rule", "ESCU - Excessive Usage Of Taskkill - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Office Application Spawn rundll32 process - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Document Spawned Child Process To Download - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Office Product Spawning MSHTA - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Windows Abused Web Services - Rule", "ESCU - Windows Admin Permission Discovery - Rule", "ESCU - Windows Boot or Logon Autostart Execution In Startup Folder - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Delete or Modify System Firewall - Rule", "ESCU - Windows Disable or Modify Tools Via Taskkill - Rule", "ESCU - Windows Executable in Loaded Modules - Rule", "ESCU - Windows Njrat Fileless Storage via Registry - Rule", "ESCU - Windows Modify Registry With MD5 Reg Key Name - Rule", "ESCU - Windows Modify System Firewall with Notable Process Path - Rule", "ESCU - Windows Raw Access To Disk Volume Partition - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - Windows Replication Through Removable Media - Rule", "ESCU - Windows System LogOff Commandline - Rule", "ESCU - Windows System Reboot CommandLine - Rule", "ESCU - Windows System Shutdown CommandLine - Rule", "ESCU - Windows Time Based Evasion - Rule", "ESCU - Windows Unsigned DLL Side-Loading - Rule", "ESCU - Windows User Execution Malicious URL Shortcut File - Rule", "ESCU - Wscript Or Cscript Suspicious Child Process - Rule"]
description = NjRat is a notorious remote access trojan (RAT) predominantly wielded by malicious operators to infiltrate and wield remote control over compromised systems. This analytical story harnesses targeted search methodologies to uncover and investigate activities that could be indicative of NjRAT's presence. These activities include tracking file write operations for dropped files, scrutinizing registry modifications aimed at establishing persistence mechanisms, monitoring suspicious processes, self-deletion behaviors, browser credential parsing, firewall configuration alterations, spread itself via removable drive and an array of other potentially malicious actions.
narrative = NjRat is also known as Bladabindi malware that was first discovered in the wild in 2012. Since then this malware remain active and uses different campaign to spred its malware. While its primary infection vectors are phishing attacks and drive-by downloads, it also has "worm" capability to spread itself via infected removable drives. This RAT has various of capabilities including keylogging, webcam access, browser credential parsing, file upload and downloads, file and process list, service list, shell command execution, registry modification, screen capture, view the desktop of the infected computer and many more. NjRat does not target any industry in particular, but attacking a wide variety of individuals and organizations to gather sensitive information.

[analytic_story://NOBELIUM Group]
category = Adversary Tactics
last_updated = 2020-12-14
version = 3
references = ["https://attack.mitre.org/groups/G0016/", "https://www.microsoft.com/security/blog/2021/03/04/goldmax-goldfinder-sibot-analyzing-nobelium-malware/", "https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html", "https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/", "https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/"]
maintainers = [{"company": "Michael Haag, Mauricio Velazco, Splunk", "email": "-", "name": "Patrick Bareiss"}]
spec_version = 3
searches = ["ESCU - Azure AD Admin Consent Bypassed by Service Principal - Rule", "ESCU - Azure AD FullAccessAsApp Permission Assigned - Rule", "ESCU - Azure AD High Number Of Failed Authentications From Ip - Rule", "ESCU - Azure AD Multi-Source Failed Authentications Spike - Rule", "ESCU - Azure AD Multiple Service Principals Created by SP - Rule", "ESCU - Azure AD Multiple Service Principals Created by User - Rule", "ESCU - Azure AD Privileged Graph API Permission Assigned - Rule", "ESCU - Azure AD Privileged Role Assigned - Rule", "ESCU - Azure AD Privileged Role Assigned to Service Principal - Rule", "ESCU - Azure AD Service Principal Authentication - Rule", "ESCU - Azure AD Service Principal Created - Rule", "ESCU - Azure AD Service Principal New Client Credentials - Rule", "ESCU - Azure AD Service Principal Owner Added - Rule", "ESCU - Azure AD Tenant Wide Admin Consent Granted - Rule", "ESCU - O365 Added Service Principal - Rule", "ESCU - O365 Application Registration Owner Added - Rule", "ESCU - O365 ApplicationImpersonation Role Assigned - Rule", "ESCU - O365 FullAccessAsApp Permission Assigned - Rule", "ESCU - O365 Multi-Source Failed Authentications Spike - Rule", "ESCU - O365 Multiple Mailboxes Accessed via API - Rule", "ESCU - O365 Multiple Service Principals Created by SP - Rule", "ESCU - O365 Multiple Service Principals Created by User - Rule", "ESCU - O365 Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - O365 OAuth App Mailbox Access via EWS - Rule", "ESCU - O365 OAuth App Mailbox Access via Graph API - Rule", "ESCU - O365 Privileged Graph API Permission Assigned - Rule", "ESCU - O365 Service Principal New Client Credentials - Rule", "ESCU - O365 Tenant Wide Admin Consent Granted - Rule", "ESCU - Anomalous usage of 7zip - Rule", "ESCU - Detect Prohibited Applications Spawning cmd exe - Rule", "ESCU - Detect Rundll32 Inline HTA Execution - Rule", "ESCU - First Time Seen Running Windows Service - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Sunburst Correlation DLL and Network Event - Rule", "ESCU - Windows AdFind Exe - Rule", "ESCU - Detect Outbound SMB Traffic - Rule", "ESCU - TOR Traffic - Rule", "ESCU - Supernova Webshell - Rule"]
description = NOBELIUM, also known as APT29, The Dukes, Cozy Bear, CozyDuke, Blue Kitsune, and Midnight Blizzard, is a sophisticated nation-state threat actor, reportedly associated with Russian intelligence. Active since at least 2008, this group primarily targets government networks in Europe and NATO member countries, along with research institutes and think tanks. Their operations typically involve advanced persistent threats (APT), leveraging techniques like spear-phishing, malware deployment, and long-term network compromise to achieve information theft and espionage. Notably, APT29 has been implicated in significant cyber espionage incidents, including the 2015 breach of the Pentagon's Joint Staff email system and attacks on the Democratic National Committee in 2016. Their advanced tactics and persistent approach underscore the serious nature of threats posed by this group to global cybersecurity.
narrative = This Analytic Story groups detections designed to trigger on a comprehensive range of Tactics, Techniques, and Procedures (TTPs) leveraged by the NOBELIUM Group, with a focus on their methods as observed in well-known public breaches.

[analytic_story://Office 365 Account Takeover]
category = Adversary Tactics
last_updated = 2023-10-17
version = 1
references = ["https://docs.microsoft.com/en-us/security/compass/incident-response-playbook-password-spray", "https://www.cisa.gov/uscert/ncas/alerts/aa21-008a", "https://docs.microsoft.com/azure/active-directory/reports-monitoring/reference-sign-ins-error-codes", "https://attack.mitre.org/tactics/TA0001/", "https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/", "https://www.microsoft.com/en-us/security/blog/2022/09/22/malicious-oauth-applications-used-to-compromise-email-servers-and-spread-spam/", "https://learn.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth", "https://www.alteredsecurity.com/post/introduction-to-365-stealer", "https://github.com/AlteredSecurity/365-Stealer"]
maintainers = [{"company": "Patrick Bareiss, Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - High Number of Login Failures from a single source - Rule", "ESCU - O365 Block User Consent For Risky Apps Disabled - Rule", "ESCU - O365 Concurrent Sessions From Different Ips - Rule", "ESCU - O365 Excessive Authentication Failures Alert - Rule", "ESCU - O365 Excessive SSO logon errors - Rule", "ESCU - O365 File Permissioned Application Consent Granted by User - Rule", "ESCU - O365 High Number Of Failed Authentications for User - Rule", "ESCU - O365 Mail Permissioned Application Consent Granted by User - Rule", "ESCU - O365 Multi-Source Failed Authentications Spike - Rule", "ESCU - O365 Multiple AppIDs and UserAgents Authentication Spike - Rule", "ESCU - O365 Multiple Failed MFA Requests For User - Rule", "ESCU - O365 Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - O365 Security And Compliance Alert Triggered - Rule", "ESCU - O365 User Consent Blocked for Risky Application - Rule", "ESCU - O365 User Consent Denied for OAuth Application - Rule"]
description = Monitor for activities and anomalies indicative of initial access techniques within Office 365 environments.
narrative = Office 365 (O365) is Microsoft's cloud-based suite of productivity tools, encompassing email, collaboration platforms, and office applications, all integrated with Azure Active Directory for identity and access management. O365's centralized storage of sensitive data and widespread adoption make it a key asset, yet also a prime target for security threats. The "Office 365 Account Takeover" analytic story focuses on the initial techniques attackers employ to breach or compromise these identities. Initial access, in this context, consists of techniques that use various entry vectors to gain their initial foothold . Identifying these early indicators is crucial for establishing the first line of defense against unauthorized access and potential security incidents within O365 environments.

[analytic_story://Office 365 Persistence Mechanisms]
category = Adversary Tactics
last_updated = 2023-10-17
version = 1
references = ["https://attack.mitre.org/tactics/TA0003/", "https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/wp-m-unc2452-2021-000343-01.pdf", "https://www.cisa.gov/uscert/ncas/alerts/aa21-008a", "https://www.splunk.com/en_us/blog/security/a-golden-saml-journey-solarwinds-continued.html", "https://blog.sygnia.co/detection-and-hunting-of-golden-saml-attack?hsLang=en", "https://www.mandiant.com/sites/default/files/2022-08/remediation-hardening-strategies-for-m365-defend-against-apt29-white-paper.pdf", "https://www.csoonline.com/article/570381/microsoft-365-advanced-audit-what-you-need-to-know.html", "https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/overview-assign-app-owners", "https://i.blackhat.com/USA-20/Thursday/us-20-Bienstock-My-Cloud-Is-APTs-Cloud-Investigating-And-Defending-Office-365.pdf"]
maintainers = [{"company": "Patrick Bareiss, Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - O365 Add App Role Assignment Grant User - Rule", "ESCU - O365 Added Service Principal - Rule", "ESCU - O365 Admin Consent Bypassed by Service Principal - Rule", "ESCU - O365 Advanced Audit Disabled - Rule", "ESCU - O365 Application Registration Owner Added - Rule", "ESCU - O365 ApplicationImpersonation Role Assigned - Rule", "ESCU - O365 Bypass MFA via Trusted IP - Rule", "ESCU - O365 Disable MFA - Rule", "ESCU - O365 FullAccessAsApp Permission Assigned - Rule", "ESCU - O365 High Privilege Role Granted - Rule", "ESCU - O365 Multiple Service Principals Created by SP - Rule", "ESCU - O365 Multiple Service Principals Created by User - Rule", "ESCU - O365 New Federated Domain Added - Rule", "ESCU - O365 New MFA Method Registered - Rule", "ESCU - O365 Privileged Graph API Permission Assigned - Rule", "ESCU - O365 Service Principal New Client Credentials - Rule", "ESCU - O365 Tenant Wide Admin Consent Granted - Rule"]
description = Monitor for activities and anomalies indicative of potential persistence techniques within Office 365 environments.
narrative = Office 365 (O365) is Microsoft's cloud-based suite of productivity tools, encompassing email, collaboration platforms, and office applications, all integrated with Azure Active Directory for identity and access management. O365's centralized storage of sensitive data and widespread adoption make it a key asset, yet also a prime target for security threats. The "Office 365 Persistence Mechanisms" analytic story delves into the tactics and techniques attackers employ to maintain prolonged unauthorized access within the O365 environment. Persistence in this context refers to methods used by adversaries to keep their foothold after an initial compromise. This can involve actions like modifying mailbox rules, establishing covert forwarding rules, manipulating application permissions. By monitoring signs of persistence, organizations can effectively detect and respond to stealthy threats, thereby protecting their O365 assets and data.

[analytic_story://Office 365 Collection Techniques]
category = Adversary Tactics
last_updated = 2024-02-12
version = 1
references = []
maintainers = [{"company": "Splunk", "email": "-", "name": "Mauricio Velazco"}]
spec_version = 3
searches = ["ESCU - O365 ApplicationImpersonation Role Assigned - Rule", "ESCU - O365 Compliance Content Search Exported - Rule", "ESCU - O365 Compliance Content Search Started - Rule", "ESCU - O365 Elevated Mailbox Permission Assigned - Rule", "ESCU - O365 Mailbox Email Forwarding Enabled - Rule", "ESCU - O365 Mailbox Folder Read Permission Assigned - Rule", "ESCU - O365 Mailbox Folder Read Permission Granted - Rule", "ESCU - O365 Mailbox Inbox Folder Shared with All Users - Rule", "ESCU - O365 Mailbox Read Access Granted to Application - Rule", "ESCU - O365 Multiple Mailboxes Accessed via API - Rule", "ESCU - O365 New Email Forwarding Rule Created - Rule", "ESCU - O365 New Email Forwarding Rule Enabled - Rule", "ESCU - O365 New Forwarding Mailflow Rule Created - Rule", "ESCU - O365 OAuth App Mailbox Access via EWS - Rule", "ESCU - O365 OAuth App Mailbox Access via Graph API - Rule", "ESCU - O365 PST export alert - Rule", "ESCU - O365 Suspicious Admin Email Forwarding - Rule", "ESCU - O365 Suspicious Rights Delegation - Rule", "ESCU - O365 Suspicious User Email Forwarding - Rule"]
description = Monitor for activities and anomalies indicative of potential collection techniques within Office 365 environments.
narrative = Office 365 (O365) is Microsoft's cloud-based suite of productivity tools, encompassing email, collaboration platforms, and office applications, all integrated with Azure Active Directory for identity and access management. O365's centralized storage of sensitive data and widespread adoption make it a key asset, yet also a prime target for security threats. The 'Office 365 Collection Techniques' analytic story focuses on the strategies and methodologies that attackers might use to gather critical information within the O365 ecosystem. 'Collection' in this context refers to the various techniques adversaries deploy to accumulate data that are essential for advancing their malicious objectives. This could include tactics such as intercepting communications, accessing sensitive documents, or extracting data from collaboration tools and email platforms. By identifying and monitoring these collection activities, organizations can more effectively spot and counteract attempts to illicitly gather information

[analytic_story://Okta Account Takeover]
category = Adversary Tactics
last_updated = 2024-03-06
version = 1
references = ["https://attack.mitre.org/techniques/T1586/", "https://www.imperva.com/learn/application-security/account-takeover-ato/", "https://www.barracuda.com/glossary/account-takeover", "https://www.okta.com/customer-identity/"]
maintainers = [{"company": "Mauricio Velazco, Bhavin Patel, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Okta Authentication Failed During MFA Challenge - Rule", "ESCU - Okta MFA Exhaustion Hunt - Rule", "ESCU - Okta Mismatch Between Source and Response for Verify Push Request - Rule", "ESCU - Okta Multi-Factor Authentication Disabled - Rule", "ESCU - Okta Multiple Accounts Locked Out - Rule", "ESCU - Okta Multiple Failed MFA Requests For User - Rule", "ESCU - Okta Multiple Failed Requests to Access Applications - Rule", "ESCU - Okta Multiple Users Failing To Authenticate From Ip - Rule", "ESCU - Okta New API Token Created - Rule", "ESCU - Okta New Device Enrolled on Account - Rule", "ESCU - Okta Phishing Detection with FastPass Origin Check - Rule", "ESCU - Okta Risk Threshold Exceeded - Rule", "ESCU - Okta Successful Single Factor Authentication - Rule", "ESCU - Okta Suspicious Activity Reported - Rule", "ESCU - Okta Suspicious Use of a Session Cookie - Rule", "ESCU - Okta ThreatInsight Threat Detected - Rule", "ESCU - Okta Unauthorized Access to Application - Rule", "ESCU - Okta User Logins from Multiple Cities - Rule"]
description = The Okta Account Takeover analytic story encompasses a comprehensive suite of detections aimed at identifying unauthorized access and potential takeover attempts of Okta accounts. This collection leverages diverse data points and behavioral analytics to safeguard user identities and access within cloud environments. Monitor for activities and techniques associated with Account Takeover attacks against Okta tenants.
narrative = Okta is a cloud-based identity management service that provides organizations with a secure way to manage user access to various applications and services. It enables single sign-on (SSO), multi-factor authentication (MFA), lifecycle management, and more, helping organizations streamline the user authentication process. Account Takeover (ATO) is an attack whereby cybercriminals gain unauthorized access to online accounts by using different techniques like brute force, social engineering, phishing & spear phishing, credential stuffing, etc. By posing as the real user, cyber-criminals can change account details, send out phishing emails, access sensitive applications, or use any stolen information to access further accounts within the organization. This analytic story groups detections that can help security operations teams identify the potential compromise of Okta accounts.

[analytic_story://Okta MFA Exhaustion]
category = Adversary Tactics
last_updated = 2022-09-27
version = 1
references = ["https://www.bleepingcomputer.com/news/security/mfa-fatigue-hackers-new-favorite-tactic-in-high-profile-breaches/", "https://www.csoonline.com/article/3674156/multi-factor-authentication-fatigue-attacks-are-on-the-rise-how-to-defend-against-them.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Okta MFA Exhaustion Hunt - Rule", "ESCU - Okta Mismatch Between Source and Response for Verify Push Request - Rule", "ESCU - Okta Risk Threshold Exceeded - Rule", "ESCU - Okta Account Locked Out - Rule", "ESCU - Okta Two or More Rejected Okta Pushes - Rule"]
description = A social engineering technique called 'MFA Fatigue', aka 'MFA push spam' or 'MFA Exhaustion', is growing more popular with threat actors as it does not require malware or phishing infrastructure and has proven to be successful in attacks.
narrative = An MFA Fatigue attack is when a threat actor runs a script that attempts to log in with stolen credentials over and over, causing what feels like an endless stream of MFA push requests to be sent to the account's owner's mobile device. The goal is to keep this up, day and night, to break down the target's cybersecurity posture and inflict a sense of "fatigue" regarding these MFA prompts.

[analytic_story://OpenSSL CVE-2022-3602]
category = Adversary Tactics
last_updated = 2022-11-02
version = 1
references = ["https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/", "https://github.com/advisories/GHSA-h8jm-2x53-xhp5", "https://community.emergingthreats.net/t/out-of-band-ruleset-update-summary-2022-11-01/117", "https://github.com/corelight/CVE-2022-3602/tree/master/scripts"]
maintainers = [{"company": "splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - SSL Certificates with Punycode - Rule", "ESCU - Zeek x509 Certificate with Punycode - Rule"]
description = OpenSSL recently disclosed two vulnerabilities CVE-2022-3602 and CVE-2022-3786. CVE-2022-3602 is a X.509 Email Address 4-byte Buffer Overflow where puny code is utilized. This only affects OpenSSL 3.0.0 - 3.0.6.
narrative = A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the . character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. Users of OpenSSL 3.0.0 - 3.0.6 are encouraged to upgrade to 3.0.7 as soon as possible. If you obtain your copy of OpenSSL from your Operating System vendor or other third party then you should seek to obtain an updated version from them as soon as possible. SSL Certificates with Punycode will identify SSL certificates with Punycode. Note that it does not mean it will capture malicious payloads. If using Zeek, modify the Zeek x509 certificate with punycode to match your environment. We found during this exercise that the FULL x509 with SAN must be captured and stored, decoded, in order to query against it.

[analytic_story://Orangeworm Attack Group]
category = Malware
last_updated = 2020-01-22
version = 2
references = ["https://www.symantec.com/blogs/threat-intelligence/orangeworm-targets-healthcare-us-europe-asia", "https://www.infosecurity-magazine.com/news/healthcare-targeted-by-hacker/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - First time seen command line argument - Rule", "ESCU - First Time Seen Running Windows Service - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Detect activities and various techniques associated with the Orangeworm Attack Group, a group that frequently targets the healthcare industry.
narrative = In May of 2018, the attack group Orangeworm was implicated for installing a custom backdoor called Trojan.Kwampirs within large international healthcare corporations in the United States, Europe, and Asia. This malware provides the attackers with remote access to the target system, decrypting and extracting a copy of its main DLL payload from its resource section. Before writing the payload to disk, it inserts a randomly generated string into the middle of the decrypted payload in an attempt to evade hash-based detections.\
Awareness of the Orangeworm group first surfaced in January, 2015. It has conducted targeted attacks against related industries, as well, such as pharmaceuticals and healthcare IT solution providers.\
Healthcare may be a promising target, because it is notoriously behind in technology, often using older operating systems and neglecting to patch computers. Even so, the group was able to evade detection for a full three years. Sources say that the malware spread quickly within the target networks, infecting computers used to control medical devices, such as MRI and X-ray machines.\
This Analytic Story is designed to help you detect and investigate suspicious activities that may be indicative of an Orangeworm attack. One detection search looks for command-line arguments. Another monitors for uses of sc.exe, a non-essential Windows file that can manipulate Windows services. One of the investigative searches helps you get more information on web hosts that you suspect have been compromised.

[analytic_story://Outlook RCE CVE-2024-21378]
category = Adversary Tactics
last_updated = 2024-03-20
version = 1
references = ["https://www.netspi.com/blog/technical/red-team-operations/microsoft-outlook-remote-code-execution-cve-2024-21378/"]
maintainers = [{"company": "Teoderick Contreras, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows InProcServer32 New Outlook Form - Rule", "ESCU - Windows New InProcServer32 Added - Rule", "ESCU - Windows Phishing Outlook Drop Dll In FORM Dir - Rule"]
description = CVE-2024-21378 exposes a critical vulnerability in Microsoft Outlook, allowing for authenticated remote code execution (RCE) through the manipulation of synced form objects. Discovered by NetSPI in 2023, this vulnerability capitalizes on the unchanged syncing capability of form objects, despite previous patches aimed at securing script code in custom forms. This technical blog delves into the discovery and weaponization of CVE-2024-21378, enhancing the Outlook penetration testing tool, Ruler, to exploit this flaw. A forthcoming pull request will provide a proof-of-concept code, aiding organizations in mitigating this security risk.
narrative = CVE-2024-21378 is a weakness in Microsoft Outlook that lets hackers execute code remotely if they can authenticate themselves. Researchers at NetSPI found this issue in 2023. The problem started with a technique from 2017 by Etienne Stalmans at SensePost, who found a way to run code using VBScript in Outlook forms. Microsoft tried to fix it by only allowing approved script code in custom forms, but they didn't fix the main issue, which is how these forms sync. To exploit this vulnerability, you need to know how Outlook forms sync, using something called MAPI, and how they use certain properties and attachments when they're set up for the first time. Hackers can mess with these properties and attachments to run their own code. They do this by tricking the form's setup process, changing registry keys and files to get past Outlook's security. To show how this could be done, researchers modified Ruler, a tool for testing Outlook's security. They changed it so it could sync a harmful form with the right properties to run a specific type of file, a COM compliant native DLL. This not only showed that CVE-2024-21378 could be exploited but also that it could affect a lot of companies since so many use Microsoft Outlook. The discovery and the way it was exploited remind us that we always need to be on the lookout for security risks and work hard to protect against them. The cybersecurity world is always watching for the next big threat that could put our digital world at risk. As companies rush to fix this issue, it's a reminder of how important it is to stay ahead of these threats.

[analytic_story://PaperCut MF NG Vulnerability]
category = Adversary Tactics
last_updated = 2023-05-15
version = 1
references = ["https://www.cisa.gov/news-events/alerts/2023/05/11/cisa-and-fbi-release-joint-advisory-response-active-exploitation-papercut-vulnerability", "https://www.papercut.com/kb/Main/PO-1216-and-PO-1219", "https://www.horizon3.ai/papercut-cve-2023-27350-deep-dive-and-indicators-of-compromise/", "https://www.bleepingcomputer.com/news/security/hackers-actively-exploit-critical-rce-bug-in-papercut-servers/", "https://www.huntress.com/blog/critical-vulnerabilities-in-papercut-print-management-software"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - PaperCut NG Suspicious Behavior Debug Log - Rule", "ESCU - Windows PaperCut NG Spawn Shell - Rule", "ESCU - PaperCut NG Remote Web Access Attempt - Rule"]
description = The FBI has issued a joint advisory concerning the exploitation of a PaperCut MF/NG vulnerability (CVE-2023-27350) by malicious actors, which began in mid-April 2023 and has been ongoing. In early May 2023, a group identifying themselves as the Bl00dy Ransomware Gang targeted vulnerable PaperCut servers within the Education Facilities Subsector. The advisory provides information on detecting exploitation attempts and shares known indicators of compromise (IOCs) associated with the group's activities.
narrative = PaperCut MF/NG versions 19 and older have reached their end-of-life, as documented on the End of Life Policy page. Customers using these older versions are advised to purchase an updated license online for PaperCut NG or through their PaperCut Partner for PaperCut MF. For users with a currently supported version (version 20 or later), they can upgrade to any maintenance release version they are licensed for.\ If upgrading to a security patch is not possible, there are alternative options to enhance security. Users can lock down network access to their server(s) by blocking all inbound traffic from external IPs to the web management port (port 9191 and 9192 by default) and blocking all inbound traffic to the web management portal on the firewall to the server. Additionally, users can apply "Allow list" restrictions under Options > Advanced > Security > Allowed site server IP addresses, setting this to only allow the IP addresses of verified Site Servers on their network.\
The vulnerabilities CVE-2023-27350 and CVE-2023-27351 have CVSS scores of 9.8 (Critical) and 8.2 (High), respectively. PaperCut and its partner network have activated response teams to assist PaperCut MF and NG customers, with service desks available 24/7 via their support page. The security response team at PaperCut has been working with external security advisors to compile a list of unpatched PaperCut MF/NG servers that have ports open on the public internet. They have been proactively reaching out to potentially exposed customers since Wednesday afternoon (AEST) and are working around the clock through the weekend.\
The exploit was first detected in the wild on April 18th, 2023, at 03:30 AEST / April 17th, 2023, at 17:30 UTC. The earliest signature of suspicious activity on a customer server potentially linked to this vulnerability dates back to April 14th, 2023, at 01:29 AEST / April 13th, 2023, at 15:29 UTC.\
Applying the security fixes should not have any negative impact. Users can follow their usual upgrade procedure to obtain the upgrade. Additional links on the -Check for updates- page (accessed through the Admin interface > About > Version info > Check for updates) allow customers to download fixes for previous major versions that are still supported (e.g., 20.1.7 and 21.2.11) as well as the current version available. PaperCut MF users are advised to follow their regular upgrade process and consult their PaperCut partner or reseller for assistance.

[analytic_story://PetitPotam NTLM Relay on Active Directory Certificate Services]
category = Adversary Tactics
last_updated = 2021-08-31
version = 1
references = ["https://us-cert.cisa.gov/ncas/current-activity/2021/07/27/microsoft-releases-guidance-mitigating-petitpotam-ntlm-relay", "https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429", "https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf", "https://github.com/topotam/PetitPotam/", "https://github.com/gentilkiwi/mimikatz/releases/tag/2.2.0-20210723", "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36942", "https://attack.mitre.org/techniques/T1187/"]
maintainers = [{"company": "Mauricio Velazco, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - PetitPotam Network Share Access Request - Rule", "ESCU - PetitPotam Suspicious Kerberos TGT Request - Rule"]
description = PetitPotam (CVE-2021-36942,) is a vulnerablity identified in Microsofts EFSRPC Protocol that can allow an unauthenticated account to escalate privileges to domain administrator given the right circumstances.
narrative = In June 2021, security researchers at SpecterOps released a blog post and white paper detailing several potential attack vectors against Active Directory Certificated Services (ADCS). ADCS is a Microsoft product that implements Public Key Infrastrucutre (PKI) functionality and can be used by organizations to provide and manage digital certiticates within Active Directory.\ In July 2021, a security researcher released PetitPotam, a tool that allows attackers to coerce Windows systems into authenticating to arbitrary endpoints.\ Combining PetitPotam with the identified ADCS attack vectors allows attackers to escalate privileges from an unauthenticated anonymous user to full domain admin privileges.

[analytic_story://Phemedrone Stealer]
category = Malware
last_updated = 2024-01-24
version = 2
references = ["https://www.trendmicro.com/en_vn/research/23/b/investigating-the-plugx-trojan-disguised-as-a-legitimate-windows.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Any Powershell DownloadFile - Rule", "ESCU - Any Powershell DownloadString - Rule", "ESCU - Download Files Using Telegram - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Suspicious Process DNS Query Known Abuse Web Services - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Gather Victim Network Info Through Ip Check Web Services - Rule"]
description = Phemedrone Stealer is a potent data-stealing malware designed to infiltrate systems discreetly, primarily targeting sensitive user information. Operating with a stealthy modus operandi, it covertly collects and exfiltrates critical data such as login credentials, personal details, and financial information. Notably evasive, Phemedrone employs sophisticated techniques to bypass security measures and remain undetected. Its capabilities extend to exploiting vulnerabilities, leveraging command and control infrastructure, and facilitating remote access. As a formidable threat, Phemedrone Stealer poses a significant risk to user privacy and system integrity, demanding vigilant cybersecurity measures to counteract its malicious activities.
narrative = Phemedrone Stealer, spotlighted in a recent Trend Micro blog, unveils a concerning chapter in cyber threats. Leveraging the CVE-2023-36025 vulnerability for defense evasion, this malware exhibits a relentless pursuit of sensitive data. Originating from the shadows of the dark web, it capitalizes on forums where cybercriminals refine its evasive maneuvers. The blog sheds light on Phemedrone's exploitation of intricate tactics, illustrating its agility in sidestepping security protocols. As cybersecurity experts delve into the intricacies of CVE-2023-36025, the narrative surrounding Phemedrone Stealer underscores the urgency for heightened vigilance and proactive defense measures against this persistent and evolving digital adversary.

[analytic_story://PlugX]
category = Malware
last_updated = 2023-10-12
version = 2
references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.plugx", "https://blog.sekoia.io/my-teas-not-cold-an-overview-of-china-cyber-threat/", "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/carderbee-software-supply-chain-certificate-abuse", "https://go.recordedfuture.com/hubfs/reports/cta-2023-0808.pdf", "https://www.mandiant.com/resources/blog/infected-usb-steal-secrets", "https://attack.mitre.org/software/S0013/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Office Application Drop Executable - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Document Spawned Child Process To Download - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious writes to windows Recycle Bin - Rule", "ESCU - Windows Access Token Manipulation SeDebugPrivilege - Rule", "ESCU - Windows Masquerading Msdtc Process - Rule", "ESCU - Windows Replication Through Removable Media - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Windows Service Deletion In Registry - Rule"]
description = PlugX, also referred to as "PlugX RAT" or "Kaba," is a highly sophisticated remote access Trojan (RAT) discovered in 2012. This malware is notorious for its involvement in targeted cyberattacks, primarily driven by cyber espionage objectives. PlugX provides attackers with comprehensive remote control capabilities over compromised systems, granting them the ability to execute commands, collect sensitive data, and manipulate the infected host.
narrative = PlugX, known as the "silent infiltrator of the digital realm, is a shadowy figure in the world of cyber threats. This remote access Trojan (RAT), first unveiled in 2012, is not your run-of-the-mill malware. It's the go-to tool for sophisticated hackers with one goal in mind, espionage. PlugX's repertoire of capabilities reads like a spy thriller. It doesn't just breach your defenses; it goes a step further, slipping quietly into your systems, much like a ghost. Once inside, it opens the door to a world of possibilities for cybercriminals. With a few keystrokes, they can access your data, capture your screen, and silently watch your every move. In the hands of skilled hackers, it's a versatile instrument for cyber espionage. This malware thrives on persistence. It's not a one-time hit; it's in it for the long haul. Even if you reboot your system, PlugX remains, ensuring that its grip on your infrastructure doesn't waver.

[analytic_story://Possible Backdoor Activity Associated With MUDCARP Espionage Campaigns]
category = Adversary Tactics
last_updated = 2020-01-22
version = 1
references = ["https://www.infosecurity-magazine.com/news/scope-of-mudcarp-attacks-highlight-1/", "http://blog.amossys.fr/badflick-is-not-so-bad.html"]
maintainers = [{"company": "iDefense", "email": "-", "name": "iDefense Cyber Espionage Team"}]
spec_version = 3
searches = ["ESCU - First time seen command line argument - Rule", "ESCU - PowerShell - Connect To Internet With Hidden Window - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Unusually Long Command Line - Rule", "ESCU - Unusually Long Command Line - MLTK - Rule", "ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Monitor your environment for suspicious behaviors that resemble the techniques employed by the MUDCARP threat group.
narrative = This story was created as a joint effort between iDefense and Splunk.\
iDefense analysts have recently discovered a Windows executable file that, upon execution, spoofs a decryption tool and then drops a file that appears to be the custom-built javascript backdoor, "Orz," which is associated with the threat actors known as MUDCARP (as well as "temp.Periscope" and "Leviathan"). The file is executed using Wscript.\
The MUDCARP techniques include the use of the compressed-folders module from Microsoft, zipfldr.dll, with RouteTheCall export to run the malicious process or command. After a successful reboot, the malware is made persistent by a manipulating `[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]'help'='c:\\windows\\system32\\rundll32.exe c:\\windows\\system32\\zipfldr.dll,RouteTheCall c:\\programdata\\winapp.exe'`. Though this technique is not exclusive to MUDCARP, it has been spotted in the group's arsenal of advanced techniques seen in the wild.\
This Analytic Story searches for evidence of tactics, techniques, and procedures (TTPs) that allow for the use of a endpoint detection-and-response (EDR) bypass technique to mask the true parent of a malicious process. It can also be set as a registry key for further sandbox evasion and to allow the malware to launch only after reboot.\
If behavioral searches included in this story yield positive hits, iDefense recommends conducting IOC searches for the following:\
\
1. www.chemscalere[.]com\
1. chemscalere[.]com\
1. about.chemscalere[.]com\
1. autoconfig.chemscalere[.]com\
1. autodiscover.chemscalere[.]com\
1. catalog.chemscalere[.]com\
1. cpanel.chemscalere[.]com\
1. db.chemscalere[.]com\
1. ftp.chemscalere[.]com\
1. mail.chemscalere[.]com\
1. news.chemscalere[.]com\
1. update.chemscalere[.]com\
1. webmail.chemscalere[.]com\
1. www.candlelightparty[.]org\
1. candlelightparty[.]org\
1. newapp.freshasianews[.]comIn addition, iDefense also recommends that organizations review their environments for activity related to the following hashes:\
\
1. cd195ee448a3657b5c2c2d13e9c7a2e2\
1. b43ad826fe6928245d3c02b648296b43\
1. 889a9b52566448231f112a5ce9b5dfaf\
1. b8ec65dab97cdef3cd256cc4753f0c54\
1. 04d83cd3813698de28cfbba326d7647c

[analytic_story://Prestige Ransomware]
category = Malware
last_updated = 2022-11-30
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2022/10/14/new-prestige-ransomware-impacts-organizations-in-ukraine-and-poland/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Change Default File Association - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Domain Group Discovery With Net - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Excessive Usage Of Cacls App - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Connection Discovery With Arp - Rule", "ESCU - Network Connection Discovery With Net - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Network Discovery Using Route Windows App - Rule", "ESCU - Ntdsutil Export NTDS - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - WBAdmin Delete System Backups - Rule", "ESCU - Windows Cached Domain Credentials Reg Query - Rule", "ESCU - Windows Change Default File Association For No File Ext - Rule", "ESCU - Windows ClipBoard Data via Get-ClipBoard - Rule", "ESCU - Windows Credentials from Password Stores Query - Rule", "ESCU - Windows Credentials in Registry Reg Query - Rule", "ESCU - Windows Indirect Command Execution Via Series Of Forfiles - Rule", "ESCU - Windows Information Discovery Fsutil - Rule", "ESCU - Windows Modify Registry Reg Restore - Rule", "ESCU - Windows Password Managers Discovery - Rule", "ESCU - Windows Private Keys Discovery - Rule", "ESCU - Windows Query Registry Reg Save - Rule", "ESCU - Windows Security Support Provider Reg Query - Rule", "ESCU - Windows Service Stop Via Net  and SC Application - Rule", "ESCU - Windows Steal or Forge Kerberos Tickets Klist - Rule", "ESCU - Windows System Network Config Discovery Display DNS - Rule", "ESCU - Windows System Network Connections Discovery Netsh - Rule", "ESCU - Windows System User Discovery Via Quser - Rule", "ESCU - Windows WMI Process And Service List - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Prestige Ransomware
narrative = This story addresses Prestige ransomware. This ransomware payload seen by Microsoft Threat Intelligence Center(MSTIC) as a ransomware campaign targeting organization in the transportation and logistic industries in some countries. This ransomware campaign highlight the destructive attack to its target organization that directly supplies or transporting military and humanitarian services or assistance. MSTIC observed this ransomware has similarities in terms of its deployment techniques with CaddyWiper and HermeticWiper which is also known malware campaign impacted multiple targeted critical infrastructure organizations. This analytic story will provide techniques and analytics that may help SOC or security researchers to monitor this threat.

[analytic_story://PrintNightmare CVE-2021-34527]
category = Vulnerability
last_updated = 2021-07-01
version = 1
references = ["https://github.com/cube0x0/CVE-2021-1675/", "https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/", "https://blog.truesec.com/2021/06/30/exploitable-critical-rce-vulnerability-allows-regular-users-to-fully-compromise-active-directory-printnightmare-cve-2021-1675/", "https://www.reddit.com/r/msp/comments/ob6y02/critical_vulnerability_printnightmare_exposes"]
maintainers = [{"company": "no", "email": "-", "name": "Splunk Threat Research Team"}]
spec_version = 3
searches = ["ESCU - Print Spooler Adding A Printer Driver - Rule", "ESCU - Print Spooler Failed to Load a Plug-in - Rule", "ESCU - Rundll32 with no Command Line Arguments with Network - Rule", "ESCU - Spoolsv Spawning Rundll32 - Rule", "ESCU - Spoolsv Suspicious Loaded Modules - Rule", "ESCU - Spoolsv Suspicious Process Access - Rule", "ESCU - Spoolsv Writing a DLL - Rule", "ESCU - Spoolsv Writing a DLL - Sysmon - Rule", "ESCU - Suspicious Rundll32 no Command Line Arguments - Rule"]
description = The following analytic story identifies behaviors related PrintNightmare, or CVE-2021-34527 previously known as (CVE-2021-1675), to gain privilege escalation on the vulnerable machine.
narrative = This vulnerability affects the Print Spooler service, enabled by default on Windows systems, and allows adversaries to trick this service into installing a remotely hosted print driver using a low privileged user account. Successful exploitation effectively allows adversaries to execute code in the target system (Remote Code Execution) in the context of the Print Spooler service which runs with the highest privileges (Privilege Escalation). \
The prerequisites for successful exploitation consist of: \
1. Print Spooler service enabled on the target system \
1. Network connectivity to the target system (initial access has been obtained) \
1. Hash or password for a low privileged user ( or computer ) account. \
In the most impactful scenario, an attacker would be able to leverage this vulnerability to obtain a SYSTEM shell on a domain controller and so escalate their privileges from a low privileged domain account to full domain access in the target environment as shown below.

[analytic_story://Prohibited Traffic Allowed or Protocol Mismatch]
category = Best Practices
last_updated = 2017-09-11
version = 1
references = ["http://www.novetta.com/2015/02/advanced-methods-to-detect-advanced-cyber-attacks-protocol-abuse/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - Allow Inbound Traffic In Firewall Rule - Rule", "ESCU - Enable RDP In Other Port Number - Rule", "ESCU - Detect hosts connecting to dynamic domain providers - Rule", "ESCU - Prohibited Network Traffic Allowed - Rule", "ESCU - Protocol or Port Mismatch - Rule", "ESCU - TOR Traffic - Rule", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task"]
description = Detect instances of prohibited network traffic allowed in the environment, as well as protocols running on non-standard ports. Both of these types of behaviors typically violate policy and can be leveraged by attackers.
narrative = A traditional security best practice is to control the ports, protocols, and services allowed within your environment. By limiting the services and protocols to those explicitly approved by policy, administrators can minimize the attack surface. The combined effect allows both network defenders and security controls to focus and not be mired in superfluous traffic or data types. Looking for deviations to policy can identify attacker activity that abuses services and protocols to run on alternate or non-standard ports in the attempt to avoid detection or frustrate forensic analysts.

[analytic_story://ProxyNotShell]
category = Adversary Tactics
last_updated = 2022-09-30
version = 1
references = ["https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/", "https://twitter.com/GossiTheDog/status/1575762721353916417?s=20\u0026t=67gq9xCWuyPm1VEm8ydfyA", "https://twitter.com/cglyer/status/1575793769814728705?s=20\u0026t=67gq9xCWuyPm1VEm8ydfyA", "https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html", "https://research.splunk.com/stories/proxyshell/", "https://www.inversecos.com/2022/07/hunting-for-apt-abuse-of-exchange.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - CertUtil Download With URLCache and Split Arguments - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Detect Exchange Web Shell - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Exchange PowerShell Abuse via SSRF - Rule", "ESCU - Exchange PowerShell Module Usage - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows MSExchange Management Mailbox Cmdlet Usage - Rule", "ESCU - ProxyShell ProxyNotShell Behavior Detected - Rule", "ESCU - Windows Exchange Autodiscover SSRF Abuse - Rule"]
description = Two new zero day Microsoft Exchange vulnerabilities have been identified actively exploited in the wild - CVE-2022-41040 and CVE-2022-41082.
narrative = Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019. The first vulnerability, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability, while the second, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker. Originally identified by GTSC monitoring Exchange, some adversary post-exploitation activity was identified and is tagged to this story.

[analytic_story://ProxyShell]
category = Adversary Tactics
last_updated = 2021-08-24
version = 1
references = ["https://y4y.space/2021/08/12/my-steps-of-reproducing-proxyshell/", "https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell", "https://www.youtube.com/watch?v=FC6iHw258RI", "https://www.huntress.com/blog/rapid-response-microsoft-exchange-servers-still-vulnerable-to-proxyshell-exploit#what-should-you-do", "https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf", "https://www.inversecos.com/2022/07/hunting-for-apt-abuse-of-exchange.html"]
maintainers = [{"company": "Teoderick Contreras, Mauricio Velazco, Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Exchange Web Shell - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Exchange PowerShell Abuse via SSRF - Rule", "ESCU - Exchange PowerShell Module Usage - Rule", "ESCU - MS Exchange Mailbox Replication service writing Active Server Pages - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows MSExchange Management Mailbox Cmdlet Usage - Rule", "ESCU - ProxyShell ProxyNotShell Behavior Detected - Rule", "ESCU - Windows Exchange Autodiscover SSRF Abuse - Rule"]
description = ProxyShell is a chain of exploits targeting on-premise Microsoft Exchange Server - CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207.
narrative = During Pwn2Own April 2021, a security researcher demonstrated an attack  chain targeting on-premise Microsoft Exchange Server. August 5th, the same researcher  publicly released further details and demonstrated the attack chain. CVE-2021-34473  Pre-auth path confusion leads to ACL Bypass (Patched in April by KB5001779)  CVE-2021-34523 - Elevation of privilege on Exchange PowerShell backend (Patched in April by KB5001779) . CVE-2021-31207 - Post-auth Arbitrary-File-Write  leads to RCE (Patched in May by KB5003435) Upon successful exploitation,  the remote attacker will have SYSTEM privileges on the Exchange Server. In addition    to remote access/execution, the adversary may be able to run Exchange PowerShell  Cmdlets to perform further actions.

[analytic_story://Qakbot]
category = Malware
last_updated = 2022-11-14
version = 2
references = ["https://www.cisa.gov/sites/default/files/publications/202010221030_QakBot%20TLPWHITE.pdf", "https://malpedia.caad.fkie.fraunhofer.de/details/win.QakBot", "https://securelist.com/QakBot-technical-analysis/103931/", "https://www.fortinet.com/blog/threat-research/new-variant-of-QakBot-spread-by-phishing-emails", "https://attack.mitre.org/software/S0650/", "https://cybersecurity.att.com/blogs/labs-research/the-rise-of-qakbot"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Create Remote Thread In Shell Application - Rule", "ESCU - Disable Defender Spynet Reporting - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Network Connection Discovery With Arp - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Network Discovery Using Route Windows App - Rule", "ESCU - NLTest Domain Trust Discovery - Rule", "ESCU - Office Application Spawn Regsvr32 process - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Process Creating LNK file in Suspicious Location - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Recon Using WMI Class - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks Run Task On Demand - Rule", "ESCU - Services LOLBAS Execution Process Spawn - Rule", "ESCU - Suspicious Copy on System32 - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Regsvr32 Register Suspicious Path - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - System User Discovery With Whoami - Rule", "ESCU - Wermgr Process Spawned CMD Or Powershell Process - Rule", "ESCU - Windows App Layer Protocol Qakbot NamedPipe - Rule", "ESCU - Windows App Layer Protocol Wermgr Connect To NamedPipe - Rule", "ESCU - Windows Command Shell Fetch Env Variables - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows Defender Exclusion Registry Entry - Rule", "ESCU - Windows DLL Search Order Hijacking Hunt with Sysmon - Rule", "ESCU - Windows DLL Side-Loading In Calc - Rule", "ESCU - Windows DLL Side-Loading Process Child Of Calc - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Masquerading Explorer As Child Process - Rule", "ESCU - Windows Modify Registry Qakbot Binary Data Registry - Rule", "ESCU - Windows MsiExec HideWindow Rundll32 Execution - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule", "ESCU - Windows Process Injection In Non-Service SearchIndexer - Rule", "ESCU - Windows Process Injection Of Wermgr to Known Browser - Rule", "ESCU - Windows Process Injection Remote Thread - Rule", "ESCU - Windows Process Injection Wermgr Child Process - Rule", "ESCU - Windows Regsvr32 Renamed Binary - Rule", "ESCU - Windows Schtasks Create Run As System - Rule", "ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows System Discovery Using ldap Nslookup - Rule", "ESCU - Windows System Discovery Using Qwinsta - Rule", "ESCU - Windows WMI Impersonate Token - Rule", "ESCU - Windows WMI Process Call Create - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = QakBot is a modular banking trojan that has been used primarily by financially-motivated actors since at least 2007. QakBot is continuously maintained and developed and has evolved from an information stealer into a delivery agent for ransomware (ref. MITRE ATT&CK).
narrative = QakBot notably has made its way on the CISA top malware list for 2021. QakBot for years has been under continious improvement when it comes to initial access, injection and post-exploitation. Multiple adversaries use QakBot to gain initial access and persist, most notably TA551. The actor(s) behind QakBot possess a modular framework consisting of maldoc builders, signed loaders, and DLLs that produce initially low detection rates at the beginning of the attack, which creates opportunities to deliver additional malware such as Egregor and Cobalt Strike. (ref. Cybersecurity ATT) The more recent campaigns utilize HTML smuggling to deliver a ISO container that has a LNK and QakBot payload. QakBot will either load via regsvr32.exe directly, it will attempt to perform DLL sideloading.

[analytic_story://Ransomware]
category = Malware
last_updated = 2020-02-04
version = 1
references = ["https://web.archive.org/web/20190826231258/https://www.carbonblack.com/2017/06/28/carbon-black-threat-research-technical-analysis-petya-notpetya-ransomware/", "https://www.splunk.com/blog/2017/06/27/closing-the-detection-to-mitigation-gap-or-to-petya-or-notpetya-whocares-.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Scheduled tasks used in BadRabbit ransomware - Rule", "ESCU - 7zip CommandLine To SMB Share Path - Rule", "ESCU - Allow File And Printing Sharing In Firewall - Rule", "ESCU - Allow Network Discovery In Firewall - Rule", "ESCU - Allow Operation with Consent Admin - Rule", "ESCU - BCDEdit Failure Recovery Modification - Rule", "ESCU - Clear Unallocated Sector Using Cipher App - Rule", "ESCU - CMLUA Or CMSTPLUA UAC Bypass - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - Conti Common Exec parameter - Rule", "ESCU - Delete ShadowCopy With PowerShell - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect RClone Command-Line Usage - Rule", "ESCU - Detect Remote Access Software Usage File - Rule", "ESCU - Detect Remote Access Software Usage FileInfo - Rule", "ESCU - Detect Remote Access Software Usage Process - Rule", "ESCU - Detect Renamed RClone - Rule", "ESCU - Detect SharpHound Command-Line Arguments - Rule", "ESCU - Detect SharpHound File Modifications - Rule", "ESCU - Detect SharpHound Usage - Rule", "ESCU - Disable AMSI Through Registry - Rule", "ESCU - Disable ETW Through Registry - Rule", "ESCU - Disable Logs Using WevtUtil - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Excessive Service Stop Attempt - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Excessive Usage Of SC Service Utility - Rule", "ESCU - Execute Javascript With Jscript COM CLSID - Rule", "ESCU - Fsutil Zeroing File - Rule", "ESCU - ICACLS Grant Command - Rule", "ESCU - Known Services Killed by Ransomware - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - MS Exchange Mailbox Replication service writing Active Server Pages - Rule", "ESCU - Msmpeng Application DLL Side Loading - Rule", "ESCU - Permission Modification using Takeown App - Rule", "ESCU - Powershell Disable Security Monitoring - Rule", "ESCU - Powershell Enable SMB1Protocol Feature - Rule", "ESCU - Powershell Execute COM Object - Rule", "ESCU - Prevent Automatic Repair Mode using Bcdedit - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Recursive Delete of Directory In Batch CMD - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Remote Process Instantiation via WMI - Rule", "ESCU - Revil Common Exec Parameter - Rule", "ESCU - Revil Registry Entry - Rule", "ESCU - Rundll32 LockWorkStation - Rule", "ESCU - Schtasks used for forcing a reboot - Rule", "ESCU - Spike in File Writes - Rule", "ESCU - Suspicious Event Log Service Behavior - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Suspicious wevtutil Usage - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - UAC Bypass With Colorui COM Object - Rule", "ESCU - Uninstall App Using MsiExec - Rule", "ESCU - Unusually Long Command Line - Rule", "ESCU - Unusually Long Command Line - MLTK - Rule", "ESCU - USN Journal Deletion - Rule", "ESCU - WBAdmin Delete System Backups - Rule", "ESCU - Wbemprox COM Object Execution - Rule", "ESCU - Windows Disable Change Password Through Registry - Rule", "ESCU - Windows Disable Lock Workstation Feature Through Registry - Rule", "ESCU - Windows Disable LogOff Button Through Registry - Rule", "ESCU - Windows Disable Memory Crash Dump - Rule", "ESCU - Windows Disable Shutdown Button Through Registry - Rule", "ESCU - Windows Disable Windows Group Policy Features Through Registry - Rule", "ESCU - Windows DiskCryptor Usage - Rule", "ESCU - Windows DotNet Binary in Non Standard Path - Rule", "ESCU - Windows Event Log Cleared - Rule", "ESCU - Windows Hide Notification Features Through Registry - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule", "ESCU - Windows NirSoft AdvancedRun - Rule", "ESCU - Windows Raccine Scheduled Task Deletion - Rule", "ESCU - Windows Registry Modification for Safe Mode Persistence - Rule", "ESCU - Windows Remote Access Software Hunt - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - Detect Remote Access Software Usage DNS - Rule", "ESCU - Detect Remote Access Software Usage Traffic - Rule", "ESCU - Prohibited Network Traffic Allowed - Rule", "ESCU - SMB Traffic Spike - Rule", "ESCU - SMB Traffic Spike - MLTK - Rule", "ESCU - TOR Traffic - Rule", "ESCU - Detect Remote Access Software Usage URL - Rule", "ESCU - Get Backup Logs For Endpoint - Response Task", "ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task", "ESCU - Get Sysmon WMI Activity for Host - Response Task"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to ransomware--spikes in SMB traffic, suspicious wevtutil usage, the presence of common ransomware extensions, and system processes run from unexpected locations, and many others.
narrative = Ransomware is an ever-present risk to the enterprise, wherein an infected host encrypts business-critical data, holding it hostage until the victim pays the attacker a ransom. There are many types and varieties of ransomware that can affect an enterprise. Attackers can deploy ransomware to enterprises through spearphishing campaigns and driveby downloads, as well as through traditional remote service-based exploitation. In the case of the WannaCry campaign, there was self-propagating wormable functionality that was used to maximize infection. Fortunately, organizations can apply several techniques--such as those in this Analytic Story--to detect and or mitigate the effects of ransomware.

[analytic_story://Ransomware Cloud]
category = Malware
last_updated = 2020-10-27
version = 1
references = ["https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/", "https://github.com/d1vious/git-wild-hunt", "https://www.youtube.com/watch?v=PgzNib37g0M"]
maintainers = [{"company": "David Dorsey, Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - AWS Detect Users creating keys with encrypt policy without MFA - Rule", "ESCU - AWS Detect Users with KMS keys performing encryption S3 - Rule", "ESCU - Get Notable History - Response Task"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to ransomware. These searches include cloud related objects that may be targeted by malicious actors via cloud providers own encryption features.
narrative = Ransomware is an ever-present risk to the enterprise, wherein an infected host encrypts business-critical data, holding it hostage until the victim pays the attacker a ransom. There are many types and varieties of ransomware that can affect an enterprise.Cloud ransomware can be deployed by obtaining high privilege credentials from targeted users or resources.

[analytic_story://RedLine Stealer]
category = Malware
last_updated = 2023-04-24
version = 1
references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.redline_stealer", "https://blogs.blackberry.com/en/2021/10/threat-thursday-redline-infostealer-update"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Disabling Defender Services - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Boot or Logon Autostart Execution In Startup Folder - Rule", "ESCU - Windows Credentials from Password Stores Chrome Extension Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows Event For Service Disabled - Rule", "ESCU - Windows Modify Registry Auto Minor Updates - Rule", "ESCU - Windows Modify Registry Auto Update Notif - Rule", "ESCU - Windows Modify Registry Disable WinDefender Notifications - Rule", "ESCU - Windows Modify Registry Do Not Connect To Win Update - Rule", "ESCU - Windows Modify Registry No Auto Reboot With Logon User - Rule", "ESCU - Windows Modify Registry No Auto Update - Rule", "ESCU - Windows Modify Registry Tamper Protection - Rule", "ESCU - Windows Modify Registry UpdateServiceUrlAlternate - Rule", "ESCU - Windows Modify Registry USeWuServer - Rule", "ESCU - Windows Modify Registry WuServer - Rule", "ESCU - Windows Modify Registry wuStatusServer - Rule", "ESCU - Windows Query Registry Browser List Application - Rule", "ESCU - Windows Query Registry UnInstall Program List - Rule", "ESCU - Windows Scheduled Task with Highest Privileges - Rule", "ESCU - Windows Service Stop Win Updates - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Redline Stealer trojan, including looking for file writes associated with its payload, screencapture, registry modification, persistence and data collection..
narrative = RedLine Stealer is a malware available on underground forum and subscription basis that are compiled or written in C#. This malware is capable of harvesting sensitive information from browsers such as saved credentials, auto file data, browser cookies and credit card information. It also gathers system information of the targeted or compromised host like username, location IP, RAM size available, hardware configuration and software installed. The current version of this malware contains features to steal wallet and crypto currency information.

[analytic_story://Remcos]
category = Malware
last_updated = 2021-09-23
version = 1
references = ["https://success.trendmicro.com/solution/1123281-remcos-malware-information", "https://attack.mitre.org/software/S0332/", "https://malpedia.caad.fkie.fraunhofer.de/details/win.remcos#:~:text=Remcos%20(acronym%20of%20Remote%20Control,used%20to%20remotely%20control%20computers.\u0026text=Remcos%20can%20be%20used%20for,been%20used%20in%20hacking%20campaigns."]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Add or Set Windows Defender Exclusion - Rule", "ESCU - Detect Outlook exe writing a zip file - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Jscript Execution Using Cscript App - Rule", "ESCU - Loading Of Dynwrapx Module - Rule", "ESCU - Malicious InProcServer32 Modification - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Office Product Spawning Windows Script Host - Rule", "ESCU - Possible Browser Pass View Parameter - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Process Deleting Its Process File Path - Rule", "ESCU - Process Writing DynamicWrapperX - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule", "ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule", "ESCU - Remcos client registry install entry - Rule", "ESCU - Remcos RAT File Creation in Remcos Folder - Rule", "ESCU - Suspicious Image Creation In Appdata Folder - Rule", "ESCU - Suspicious Process DNS Query Known Abuse Web Services - Rule", "ESCU - Suspicious Process Executed From Container File - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious WAV file in Appdata Folder - Rule", "ESCU - System Info Gathering Using Dxdiag Application - Rule", "ESCU - Vbscript Execution Using Wscript App - Rule", "ESCU - Windows Defender Exclusion Registry Entry - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule", "ESCU - Winhlp32 Spawning a Process - Rule", "ESCU - Wscript Or Cscript Suspicious Child Process - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Remcos RAT trojan, including looking for file writes associated with its payload, screencapture, registry modification, UAC bypassed, persistence and data collection..
narrative = Remcos or Remote Control and Surveillance, marketed as a legitimate software for remotely managing Windows systems is now widely used in multiple malicious campaigns both APT and commodity malware by threat actors.

[analytic_story://Reverse Network Proxy]
category = Adversary Tactics
last_updated = 2022-11-16
version = 1
references = ["https://attack.mitre.org/software/S0508/", "https://www.cisa.gov/uscert/sites/default/files/publications/aa22-320a_joint_csa_iranian_government-sponsored_apt_actors_compromise_federal%20network_deploy_crypto%20miner_credential_harvester.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Linux Ngrok Reverse Proxy Usage - Rule", "ESCU - Windows Ngrok Reverse Proxy Usage - Rule", "ESCU - Ngrok Reverse Proxy on Network - Rule"]
description = The following analytic story describes applications that may be abused to reverse proxy back into an organization, either for persistence or remote access.
narrative = This analytic story covers tools like Ngrok which is a legitimate reverse proxy tool that can create a secure tunnel to servers located behind firewalls or on local machines that do not have a public IP. Ngrok in particular has been leveraged by threat actors in several campaigns including use for lateral movement and data exfiltration. There are many open source and closed/paid that fall into this reverse proxy category. The analytic story and complemented analytics will be released as more are identified.

[analytic_story://Revil Ransomware]
category = Malware
last_updated = 2021-06-04
version = 1
references = ["https://krebsonsecurity.com/2021/05/a-closer-look-at-the-darkside-ransomware-gang/", "https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-atr-analyzes-sodinokibi-aka-revil-ransomware-as-a-service-what-the-code-tells-us/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Allow Network Discovery In Firewall - Rule", "ESCU - Delete ShadowCopy With PowerShell - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - Msmpeng Application DLL Side Loading - Rule", "ESCU - Powershell Disable Security Monitoring - Rule", "ESCU - Revil Common Exec Parameter - Rule", "ESCU - Revil Registry Entry - Rule", "ESCU - Wbemprox COM Object Execution - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Revil ransomware, including looking for file writes associated with Revil, encrypting network shares, deleting shadow volume storage, registry key modification, deleting of security logs, and more.
narrative = Revil ransomware is a RaaS,that a single group may operates and manges the development of this ransomware. It involve the use of ransomware payloads along with exfiltration of data. Malicious actors demand payment for ransome of data and threaten deletion and exposure of exfiltrated data.

[analytic_story://Rhysida Ransomware]
category = Malware
last_updated = 2023-12-12
version = 1
references = ["https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-319a"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Rare Executables - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Disable Logs Using WevtUtil - Rule", "ESCU - Domain Account Discovery With Net App - Rule", "ESCU - Domain Controller Discovery with Nltest - Rule", "ESCU - Domain Group Discovery With Net - Rule", "ESCU - Elevated Group Discovery With Net - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - High Process Termination Frequency - Rule", "ESCU - Malicious Powershell Executed As A Service - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - NLTest Domain Trust Discovery - Rule", "ESCU - Ntdsutil Export NTDS - Rule", "ESCU - PowerShell 4104 Hunting - Rule", "ESCU - Ransomware Notes bulk creation - Rule", "ESCU - SAM Database File Access Attempt - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - SecretDumps Offline NTDS Dumping Tool - Rule", "ESCU - Spike in File Writes - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious wevtutil Usage - Rule", "ESCU - System User Discovery With Whoami - Rule", "ESCU - Windows Modify Registry NoChangingWallPaper - Rule", "ESCU - Windows PowerView AD Access Control List Enumeration - Rule", "ESCU - Windows PowerView Constrained Delegation Discovery - Rule", "ESCU - Windows PowerView Kerberos Service Ticket Request - Rule", "ESCU - Windows PowerView SPN Discovery - Rule", "ESCU - Windows PowerView Unconstrained Delegation Discovery - Rule", "ESCU - Windows Rundll32 Apply User Settings Changes - Rule", "ESCU - WinRM Spawning a Process - Rule", "ESCU - Detect Zerologon via Zeek - Rule"]
description = Utilize analytics designed to identify and delve into atypical behaviors, potentially associated with the Rhysida Ransomware. Employing these searches enables the detection of irregular patterns or actions within systems or networks, serving as proactive measures to spot potential indicators of compromise or ongoing threats. By implementing these search strategies, security analysts can effectively pinpoint anomalous activities, such as unusual file modifications, deviations in system behavior, that could potentially signify the presence or attempt of Rhysida Ransomware infiltration. These searches serve as pivotal tools in the arsenal against such threats, aiding in swift detection, investigation, and mitigation efforts to counter the impact of the Rhysida Ransomware or similar malicious entities.
narrative = This story addresses Rhysida ransomware. Rhysida Ransomware emerges as a silent predator, infiltrating systems stealthily and unleashing havoc upon its victims. Employing sophisticated encryption tactics, it swiftly locks critical files and databases, holding them hostage behind an impenetrable digital veil. The haunting demand for ransom sends shockwaves through affected organizations, rendering operations inert and plunging them into a tumultuous struggle between compliance and resilience. Threat actors leveraging Rhysida ransomware are known to impact "targets of opportunity," including victims in the education, healthcare, manufacturing, information technology, and government sectors. Open source reporting details similarities between Vice Society activity and the actors observed deploying Rhysida ransomware. Additionally, open source reporting has confirmed observed instances of Rhysida actors operating in a ransomware-as-a-service (RaaS) capacity, where ransomware tools and infrastructure are leased out in a profit-sharing model. Any ransoms paid are then split between the group and the affiliates.

[analytic_story://Router and Infrastructure Security]
category = Best Practices
last_updated = 2017-09-12
version = 1
references = ["https://web.archive.org/web/20210420020040/https://www.fireeye.com/blog/executive-perspective/2015/09/the_new_route_toper.html", "https://www.cisco.com/c/en/us/about/security-center/event-response/synful-knock.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect New Login Attempts to Routers - Rule", "ESCU - Detect ARP Poisoning - Rule", "ESCU - Detect IPv6 Network Infrastructure Threats - Rule", "ESCU - Detect Port Security Violation - Rule", "ESCU - Detect Rogue DHCP Server - Rule", "ESCU - Detect Software Download To Network Device - Rule", "ESCU - Detect Traffic Mirroring - Rule", "ESCU - Get Notable History - Response Task"]
description = Validate the security configuration of network infrastructure and verify that only authorized users and systems are accessing critical assets. Core routing and switching infrastructure are common strategic targets for attackers.
narrative = Networking devices, such as routers and switches, are often overlooked as resources that attackers will leverage to subvert an enterprise. Advanced threats actors have shown a proclivity to target these critical assets as a means to siphon and redirect network traffic, flash backdoored operating systems, and implement cryptographic weakened algorithms to more easily decrypt network traffic.\
This Analytic Story helps you gain a better understanding of how your network devices are interacting with your hosts. By compromising your network devices, attackers can obtain direct access to the company's internal infrastructure&#151; effectively increasing the attack surface and accessing private services/data.

[analytic_story://Ryuk Ransomware]
category = Malware
last_updated = 2020-11-06
version = 1
references = ["https://www.splunk.com/en_us/blog/security/detecting-ryuk-using-splunk-attack-range.html", "https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/", "https://us-cert.cisa.gov/ncas/alerts/aa20-302a"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Jose Hernandez"}]
spec_version = 3
searches = ["ESCU - Windows connhost exe started forcefully - Rule", "ESCU - BCDEdit Failure Recovery Modification - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - NLTest Domain Trust Discovery - Rule", "ESCU - Ryuk Test Files Detected - Rule", "ESCU - Ryuk Wake on LAN Command - Rule", "ESCU - Spike in File Writes - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - WBAdmin Delete System Backups - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows Security Account Manager Stopped - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - Remote Desktop Network Bruteforce - Rule", "ESCU - Remote Desktop Network Traffic - Rule", "ESCU - Get Notable History - Response Task"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the Ryuk ransomware, including looking for file writes associated with Ryuk, Stopping Security Access Manager, DisableAntiSpyware registry key modification, suspicious psexec use, and more.
narrative = Cybersecurity Infrastructure Security Agency (CISA) released Alert (AA20-302A) on October 28th called Ransomware Activity Targeting the Healthcare and Public Health Sector. This alert details TTPs associated with ongoing and possible imminent attacks against the Healthcare sector, and is a joint advisory in coordination with other U.S. Government agencies. The objective of these malicious campaigns is to infiltrate targets in named sectors and to drop ransomware payloads, which will likely cause disruption of service and increase risk of actual harm to the health and safety of patients at hospitals, even with the aggravant of an ongoing COVID-19 pandemic. This document specifically refers to several crimeware exploitation frameworks, emphasizing the use of Ryuk ransomware as payload. The Ryuk ransomware payload is not new. It has been well documented and identified in multiple variants. Payloads need a carrier, and for Ryuk it has often been exploitation frameworks such as Cobalt Strike, or popular crimeware frameworks such as Emotet or Trickbot.

[analytic_story://SamSam Ransomware]
category = Malware
last_updated = 2018-12-13
version = 1
references = ["https://www.crowdstrike.com/blog/an-in-depth-analysis-of-samsam-ransomware-and-boss-spider/", "https://nakedsecurity.sophos.com/2018/07/31/samsam-the-almost-6-million-ransomware/", "https://thehackernews.com/2018/07/samsam-ransomware-attacks.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Prohibited Software On Endpoint - Rule", "ESCU - Attacker Tools On Endpoint - Rule", "ESCU - Batch File Write to System32 - Rule", "ESCU - Common Ransomware Extensions - Rule", "ESCU - Common Ransomware Notes - Rule", "ESCU - Deleting Shadow Copies - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - File with Samsam Extension - Rule", "ESCU - Samsam Test File Write - Rule", "ESCU - Spike in File Writes - Rule", "ESCU - Remote Desktop Network Bruteforce - Rule", "ESCU - Remote Desktop Network Traffic - Rule", "ESCU - Detect attackers scanning for vulnerable JBoss servers - Rule", "ESCU - Detect malicious requests to exploit JBoss servers - Rule", "ESCU - Get Backup Logs For Endpoint - Response Task", "ESCU - Get History Of Email Sources - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task", "ESCU - Investigate Successful Remote Desktop Authentications - Response Task"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the SamSam ransomware, including looking for file writes associated with SamSam, RDP brute force attacks, the presence of files with SamSam ransomware extensions, suspicious psexec use, and more.
narrative = The first version of the SamSam ransomware (a.k.a. Samas or SamsamCrypt) was launched in 2015 by a group of Iranian threat actors. The malicious software has affected and continues to affect thousands of victims and has raised almost $6M in ransom.\
Although categorized under the heading of ransomware, SamSam campaigns have some importance distinguishing characteristics. Most notable is the fact that conventional ransomware is a numbers game. Perpetrators use a "spray-and-pray" approach with phishing campaigns or other mechanisms, charging a small ransom (typically under $1,000). The goal is to find a large number of victims willing to pay these mini-ransoms, adding up to a lucrative payday. They use relatively simple methods for infecting systems.\
SamSam attacks are different beasts. They have become progressively more targeted and skillful than typical ransomware attacks. First, malicious actors break into a victim's network, surveil it, then run the malware manually. The attacks are tailored to cause maximum damage and the threat actors usually demand amounts in the tens of thousands of dollars.\
In a typical attack on one large healthcare organization in 2018, the company ended up paying a ransom of four Bitcoins, then worth $56,707. Reports showed that access to the company's files was restored within two hours of paying the sum.\
According to Sophos, SamSam previously leveraged  RDP to gain access to targeted networks via brute force. SamSam is not spread automatically, like other malware. It requires skill because it forces the attacker to adapt their tactics to the individual environment. Next, the actors escalate their privileges to admin level. They scan the networks for worthy targets, using conventional tools, such as PsExec or PaExec, to deploy/execute, quickly encrypting files.\
This Analytic Story includes searches designed to help detect and investigate signs of the SamSam ransomware, such as the creation of fileswrites to system32, writes with tell-tale extensions, batch files written to system32, and evidence of brute-force attacks via RDP.

[analytic_story://Sandworm Tools]
category = Data Destruction
last_updated = 2022-04-05
version = 1
references = ["https://cert.gov.ua/article/3718487", "https://attack.mitre.org/groups/G0034/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Detect Mimikatz Using Loaded Images - Rule", "ESCU - Detect Mimikatz With PowerShell Script Block Logging - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Detect Renamed PSExec - Rule", "ESCU - Icacls Deny Command - Rule", "ESCU - Linux Iptables Firewall Modification - Rule", "ESCU - Linux Kworker Process In Writable Process Path - Rule", "ESCU - Local Account Discovery with Net - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Mimikatz PassTheTicket CommandLine Parameters - Rule", "ESCU - Permission Modification using Takeown App - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Copy on System32 - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows DNS Gather Network Info - Rule", "ESCU - Windows High File Deletion Frequency - Rule", "ESCU - Windows Mimikatz Binary Execution - Rule", "ESCU - Windows Mimikatz Crypto Export File Extensions - Rule", "ESCU - Windows System Shutdown CommandLine - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = This analytic story features detections that enable security analysts to identify and investigate unusual activities potentially related to the destructive malware and tools employed by the "Sandworm" group. This analytic story focuses on monitoring suspicious process executions, command-line activities, Master Boot Record (MBR) wiping, data destruction, and other related indicators.
narrative = The Sandworm group's tools are part of destructive malware operations designed to disrupt or attack Ukraine's National Information Agencies. This operation campaign consists of several malware components, including scripts, native Windows executables (LOLBINs), data wiper malware that overwrites or destroys the Master Boot Record (MBR), and file wiping using sdelete.exe on targeted hosts.

[analytic_story://Scheduled Tasks]
category = Adversary Tactics
last_updated = 2023-06-12
version = 1
references = ["https://attack.mitre.org/techniques/T1053/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Linux Add Files In Known Crontab Directories - Rule", "ESCU - Linux Adding Crontab Using List Parameter - Rule", "ESCU - Linux At Allow Config File Creation - Rule", "ESCU - Linux At Application Execution - Rule", "ESCU - Linux Edit Cron Table Parameter - Rule", "ESCU - Linux Possible Append Command To At Allow Config File - Rule", "ESCU - Linux Possible Append Cronjob Entry on Existing Cronjob File - Rule", "ESCU - Linux Possible Cronjob Modification With Editor - Rule", "ESCU - Linux Service File Created In Systemd Directory - Rule", "ESCU - Linux Service Restarted - Rule", "ESCU - Linux Service Started Or Enabled - Rule", "ESCU - Possible Lateral Movement PowerShell Spawn - Rule", "ESCU - Randomly Generated Scheduled Task Name - Rule", "ESCU - Schedule Task with HTTP Command Arguments - Rule", "ESCU - Schedule Task with Rundll32 Command Trigger - Rule", "ESCU - Scheduled Task Creation on Remote Endpoint using At - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Scheduled Task Initiation on Remote Endpoint - Rule", "ESCU - Schtasks Run Task On Demand - Rule", "ESCU - Schtasks scheduling job on remote system - Rule", "ESCU - Schtasks used for forcing a reboot - Rule", "ESCU - Short Lived Scheduled Task - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Svchost LOLBAS Execution Process Spawn - Rule", "ESCU - Windows Enable Win32 ScheduledJob via Registry - Rule", "ESCU - Windows Hidden Schedule Task Settings - Rule", "ESCU - Windows PowerShell ScheduleTask - Rule", "ESCU - Windows Registry Delete Task SD - Rule", "ESCU - Windows Scheduled Task Created Via XML - Rule", "ESCU - Windows Scheduled Task with Highest Privileges - Rule", "ESCU - Windows Schtasks Create Run As System - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = The MITRE ATT&CK technique T1053 refers to Scheduled Task/Job. Adversaries might use task scheduling utilities to execute programs or scripts at a predefined date and time. This method is often used for persistence but can also be used for privilege escalation or to execute tasks under certain conditions. Scheduling tasks can be beneficial for an attacker as it can allow them to execute actions at times when the system is less likely to be monitored actively. Different operating systems have different utilities for task scheduling, for example, Unix-like systems have Cron, while Windows has Scheduled Tasks and At Jobs.
narrative = MITRE ATT&CK technique T1053, labeled "Scheduled Task/Job", is a categorization of methods that adversaries use to execute malicious code by scheduling tasks or jobs on a system. This technique is widely utilized for persistence, privilege escalation, and the remote execution of tasks. The technique is applicable across various environments and platforms, including Windows, Linux, and macOS.\
The technique consists of multiple sub-techniques, each highlighting a distinct mechanism for scheduling tasks or jobs. These sub-techniques include T1053.001 (Scheduled Task), T1053.002 (At for Windows), T1053.003 (Cron), T1053.004 (Launchd), T1053.005 (At for Linux), and T1053.006 (Systemd Timers).\
Scheduled Task (T1053.001) focuses on adversaries' methods for scheduling tasks on a Windows system to maintain persistence or escalate privileges. These tasks can be set to execute at specified times, in response to particular events, or after a defined time interval.\
The At command for Windows (T1053.002) enables administrators to schedule tasks on a Windows system. Adversaries may exploit this command to execute programs at system startup or at a predetermined schedule for persistence.\
Cron (T1053.003) is a built-in job scheduler found in Unix-like operating systems. Adversaries can use cron jobs to execute programs at system startup or on a scheduled basis for persistence.\
Launchd (T1053.004) is a service management framework present in macOS. Adversaries may utilize launchd to maintain persistence on macOS systems by setting up daemons or agents to execute at specific times or in response to defined events.\
The At command for Linux (T1053.005) enables administrators to schedule tasks on a Linux system. Adversaries can use this command to execute programs at system startup or on a scheduled basis for persistence.\
Systemd Timers (T1053.006) offer a means of scheduling tasks on Linux systems using systemd. Adversaries can use systemd timers to execute programs at system startup or on a scheduled basis for persistence.\
Detection and mitigation strategies vary for each sub-technique. For instance, monitoring the creation of scheduled tasks or looking for uncorrelated changes to tasks that do not align with known software or patch cycles can be effective for detecting malicious activity related to this technique. Mitigation strategies may involve restricting permissions and applying application control solutions to prevent adversaries from scheduling tasks.

[analytic_story://Signed Binary Proxy Execution InstallUtil]
category = Adversary Tactics
last_updated = 2021-11-12
version = 1
references = ["https://attack.mitre.org/techniques/T1218/004/", "https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1218.004/T1218.004.md"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows DotNet Binary in Non Standard Path - Rule", "ESCU - Windows InstallUtil Credential Theft - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule", "ESCU - Windows InstallUtil Remote Network Connection - Rule", "ESCU - Windows InstallUtil Uninstall Option - Rule", "ESCU - Windows InstallUtil Uninstall Option with Network - Rule", "ESCU - Windows InstallUtil URL in Command Line - Rule"]
description = Adversaries may use InstallUtil to proxy execution of code through a trusted Windows utility.
narrative = InstallUtil is a command-line utility that allows for installation and uninstallation of resources by executing specific installer components specified in .NET binaries. InstallUtil is digitally signed by Microsoft and located in the .NET directories on a Windows system: C:\Windows\Microsoft.NET\Framework\v\InstallUtil.exe and C:\Windows\Microsoft.NET\Framework64\v\InstallUtil.exe. \
There are multiple ways to instantiate InstallUtil and they are all outlined within Atomic Red Team - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1218.004/T1218.004.md. Two specific ways may be used and that includes invoking via  installer assembly class constructor through .NET and via InstallUtil.exe. \
Typically, adversaries will utilize the most commonly found way to invoke via InstallUtil Uninstall method. \
Note that parallel processes, and parent process, play a role in how InstallUtil is being used. In particular, a developer using InstallUtil will spawn from VisualStudio. Adversaries, will spawn from non-standard processes like Explorer.exe, cmd.exe or PowerShell.exe. It's important to review the command-line to identify the DLL being loaded. \
Parallel processes may also include csc.exe being used to compile a local `.cs` file. This file will be the input to the output. Developers usually do not build direct on the command shell, therefore this should raise suspicion.

[analytic_story://Silver Sparrow]
category = Adversary Tactics
last_updated = 2021-02-24
version = 1
references = ["https://redcanary.com/blog/clipping-silver-sparrows-wings/", "https://www.sentinelone.com/blog/5-things-you-need-to-know-about-silver-sparrow/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Suspicious Curl Network Connection - Rule", "ESCU - Suspicious PlistBuddy Usage - Rule", "ESCU - Suspicious PlistBuddy Usage via OSquery - Rule", "ESCU - Suspicious SQLite3 LSQuarantine Behavior - Rule"]
description = Silver Sparrow, identified by Red Canary Intelligence, is a new forward looking MacOS (Intel and M1) malicious software downloader utilizing JavaScript for execution and a launchAgent to establish persistence.
narrative = Silver Sparrow works is a dropper and uses typical persistence mechanisms on a Mac. It is cross platform, covering both Intel and Apple M1 architecture. To this date, no implant has been downloaded for malicious purposes. During installation of the update.pkg or updater.pkg file, the malicious software utilizes JavaScript to generate files and scripts on disk for persistence.These files later download a implant from an S3 bucket every hour. This analytic assists with identifying different types of macOS malware families establishing LaunchAgent persistence. Per SentinelOne source, it is predicted that Silver Sparrow is likely selling itself as a mechanism to 3rd party Caffiliates or pay-per-install (PPI) partners, typically seen as commodity adware/malware. Additional indicators and behaviors may be found within the references.

[analytic_story://Snake Keylogger]
category = Adversary Tactics
last_updated = 2024-02-12
version = 1
references = ["https://malpedia.caad.fkie.fraunhofer.de/details/win.404keylogger", "https://www.checkpoint.com/cyber-hub/threat-prevention/what-is-malware/snake-keylogger-malware/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Detect Regasm Spawning a Process - Rule", "ESCU - Download Files Using Telegram - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - High Process Termination Frequency - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Processes launching netsh - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Suspicious Driver Loaded Path - Rule", "ESCU - Suspicious Process DNS Query Known Abuse Web Services - Rule", "ESCU - Suspicious Process Executed From Container File - Rule", "ESCU - Windows Credential Access From Browser Password Store - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows File Transfer Protocol In Non-Common Process Path - Rule", "ESCU - Windows Gather Victim Network Info Through Ip Check Web Services - Rule", "ESCU - Windows Non Discord App Access Discord LevelDB - Rule", "ESCU - Windows Phishing PDF File Executes URL Link - Rule", "ESCU - Windows System Network Connections Discovery Netsh - Rule", "ESCU - Windows Time Based Evasion via Choice Exec - Rule", "ESCU - Windows Unsecured Outlook Credentials Access In Registry - Rule", "ESCU - Windows User Execution Malicious URL Shortcut File - Rule"]
description = SnakeKeylogger is a stealthy malware designed to secretly record keystrokes on infected devices. It operates covertly in the background, capturing sensitive information such as passwords and credit card details. This keylogging threat poses a significant risk to user privacy and security.
narrative = SnakeKeylogger, a notorious malware, first emerged in the early 2010s, gaining infamy for its clandestine ability to capture keystrokes on compromised systems. As a stealthy threat, it infiltrates computers silently, recording every keystroke entered by users, including sensitive information like passwords and financial details. Over time, it has evolved to evade detection mechanisms, posing a persistent threat to cybersecurity. Its widespread use in various cybercrime activities underscores its significance as a tool for espionage and data theft. Despite efforts to combat it, SnakeKeylogger continues to lurk in the shadows, perpetuating its malicious activities with devastating consequences.

[analytic_story://Snake Malware]
category = Adversary Tactics
last_updated = 2023-05-10
version = 1
references = ["https://media.defense.gov/2023/May/09/2003218554/-1/-1/0/JOINT_CSA_HUNTING_RU_INTEL_SNAKE_MALWARE_20230509.PDF"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Service Created with Suspicious Service Path - Rule", "ESCU - Windows Service Created Within Public Path - Rule", "ESCU - Windows Snake Malware File Modification Crmlog - Rule", "ESCU - Windows Snake Malware Kernel Driver Comadmin - Rule", "ESCU - Windows Snake Malware Registry Modification wav OpenWithProgIds - Rule", "ESCU - Windows Snake Malware Service Create - Rule"]
description = The Snake implant is considered the most sophisticated cyber espionage tool designed and used by Center 16 of Russia's Federal Security Service (FSB) for long-term intelligence collection on sensitive targets.
narrative = The Snake implant is considered the most sophisticated cyber espionage tool designed and used by Center 16 of Russia's Federal Security Service (FSB) for long-term intelligence collection on sensitive targets. To conduct operations using this tool, the FSB created a covert peer-to-peer (P2P) network of numerous Snake-infected computers worldwide. Many systems in this P2P network serve as relay nodes which route disguised operational traffic to and from Snake implants on the FSB's ultimate targets. Snake's custom communications protocols employ encryption and fragmentation for confidentiality and are designed to hamper detection and collection efforts. We consider Snake to be the most sophisticated cyber espionage tool in the FSB's arsenal. The sophistication of Snake stems from three principal areas. First, Snake employs means to achieve a rare level of stealth in its host components and network communications. Second, Snake's internal technical architecture allows for easy incorporation of new or replacement components. This design also facilitates the development and interoperability of Snake instances running on different host operating systems. We have observed interoperable Snake implants for Windows, MacOS, and Linux operating systems. Lastly, Snake demonstrates careful software engineering design and implementation, with the implant containing surprisingly few bugs given its complexity. (CISA, 2023)

[analytic_story://Sneaky Active Directory Persistence Tricks]
category = Adversary Tactics
last_updated = 2024-03-14
version = 2
references = ["https://adsecurity.org/?p=1929", "https://www.youtube.com/watch?v=Lz6haohGAMc\u0026feature=youtu.be", "https://adsecurity.org/wp-content/uploads/2015/09/DEFCON23-2015-Metcalf-RedvsBlue-ADAttackAndDefense-Final.pdf", "https://attack.mitre.org/tactics/TA0003/", "https://www.dcshadow.com", "https://gist.github.com/gentilkiwi/dcc132457408cf11ad2061340dcb53c2", "https://www.linkedin.com/pulse/mimikatz-dcsync-event-log-detections-john-dwyer"]
maintainers = [{"company": "Mauricio Velazco, Splunk", "email": "-", "name": "Dean Luxton"}]
spec_version = 3
searches = ["ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Windows AD AdminSDHolder ACL Modified - Rule", "ESCU - Windows AD Cross Domain SID History Addition - Rule", "ESCU - Windows AD Domain Controller Audit Policy Disabled - Rule", "ESCU - Windows AD Domain Controller Promotion - Rule", "ESCU - Windows AD Domain Replication ACL Addition - Rule", "ESCU - Windows AD DSRM Account Changes - Rule", "ESCU - Windows AD DSRM Password Reset - Rule", "ESCU - Windows AD Privileged Account SID History Addition - Rule", "ESCU - Windows AD Replication Request Initiated by User Account - Rule", "ESCU - Windows AD Replication Request Initiated from Unsanctioned Location - Rule", "ESCU - Windows AD Same Domain SID History Addition - Rule", "ESCU - Windows AD ServicePrincipalName Added To Domain Account - Rule", "ESCU - Windows AD Short Lived Domain Account ServicePrincipalName - Rule", "ESCU - Windows AD Short Lived Domain Controller SPN Attribute - Rule", "ESCU - Windows AD Short Lived Server Object - Rule", "ESCU - Windows AD SID History Attribute Modified - Rule", "ESCU - Windows Admon Default Group Policy Object Modified - Rule", "ESCU - Windows Admon Group Policy Object Created - Rule", "ESCU - Windows Default Group Policy Object Modified - Rule", "ESCU - Windows Default Group Policy Object Modified with GPME - Rule", "ESCU - Windows Group Policy Object Created - Rule", "ESCU - Windows Security Support Provider Reg Query - Rule", "ESCU - Windows AD Replication Service Traffic - Rule", "ESCU - Windows AD Rogue Domain Controller Network Activity - Rule"]
description = Monitor for activities and techniques associated with Windows Active Directory persistence techniques.
narrative = Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Active Directory is a centralized and hierarchical database that stores information about users, computers, and other resources on a network. It provides secure and efficient management of these resources and enables administrators to enforce security policies and delegate administrative tasks.\
In 2015 Active Directory security researcher Sean Metcalf published a blog post titled `Sneaky Active Directory Persistence Tricks`. In this blog post, Sean described several methods through which an attacker could persist administrative access on an Active Directory network after having Domain Admin level rights for a short period of time. At the time of writing, 8 years after the initial blog post, most of these techniques are still possible since they abuse legitimate administrative functionality and not software vulnerabilities. Security engineers defending Active Directory networks should be aware of these technique available to adversaries post exploitation and deploy both preventive and detective security controls for them.\
This analytic story groups detection opportunities for most of the techniques described on Seans blog post as well as other high impact attacks against Active Directory networks and Domain Controllers like DCSync and DCShadow. For some of these detection opportunities, it is necessary to enable the necessary GPOs and SACLs required, otherwise the event codes will not trigger. Each detection includes a list of requirements for enabling logging.

[analytic_story://Spearphishing Attachments]
category = Adversary Tactics
last_updated = 2019-04-29
version = 1
references = ["https://www.fireeye.com/blog/threat-research/2019/04/spear-phishing-campaign-targets-ukraine-government.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Splunk Research Team"}]
spec_version = 3
searches = ["ESCU - Gdrive suspicious file sharing - Rule", "ESCU - Gsuite suspicious calendar invite - Rule", "ESCU - Detect Outlook exe writing a zip file - Rule", "ESCU - Detect RTLO In File Name - Rule", "ESCU - Detect RTLO In Process - Rule", "ESCU - Excel Spawning PowerShell - Rule", "ESCU - Excel Spawning Windows Script Host - Rule", "ESCU - MSHTML Module Load in Office Product - Rule", "ESCU - Office Application Spawn rundll32 process - Rule", "ESCU - Office Document Creating Schedule Task - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Document Spawned Child Process To Download - Rule", "ESCU - Office Product Spawning BITSAdmin - Rule", "ESCU - Office Product Spawning CertUtil - Rule", "ESCU - Office Product Spawning MSHTA - Rule", "ESCU - Office Product Spawning Rundll32 with no DLL - Rule", "ESCU - Office Product Spawning Windows Script Host - Rule", "ESCU - Office Product Spawning Wmic - Rule", "ESCU - Office Product Writing cab or inf - Rule", "ESCU - Office Spawning Control - Rule", "ESCU - Process Creating LNK file in Suspicious Location - Rule", "ESCU - Windows ConHost with Headless Argument - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Office Product Spawning MSDT - Rule", "ESCU - Windows Phishing PDF File Executes URL Link - Rule", "ESCU - Windows Spearphishing Attachment Connect To None MS Office Domain - Rule", "ESCU - Windows Spearphishing Attachment Onenote Spawn Mshta - Rule", "ESCU - Winword Spawning Cmd - Rule", "ESCU - Winword Spawning PowerShell - Rule", "ESCU - Winword Spawning Windows Script Host - Rule"]
description = Detect signs of malicious payloads that may indicate that your environment has been breached via a phishing attack.
narrative = Despite its simplicity, phishing remains the most pervasive and dangerous cyberthreat. In fact, research shows that as many as [91% of all successful attacks](https://digitalguardian.com/blog/91-percent-cyber-attacks-start-phishing-email-heres-how-protect-against-phishing) are initiated via a phishing email. \
As most people know, these emails use fraudulent domains, [email scraping](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), familiar contact names inserted as senders, and other tactics to lure targets into clicking a malicious link, opening an attachment with a [nefarious payload](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), or entering sensitive personal information that perpetrators may intercept. This attack technique requires a relatively low level of skill and allows adversaries to easily cast a wide net. Worse, because its success relies on the gullibility of humans, it's impossible to completely "automate" it out of your environment. However, you can use ES and ESCU to detect and investigate potentially malicious payloads injected into your environment subsequent to a phishing attack. \
While any kind of file may contain a malicious payload, some are more likely to be perceived as benign (and thus more often escape notice) by the average victim&#151;especially when the attacker sends an email that seems to be from one of their contacts. An example is Microsoft Office files. Most corporate users are familiar with documents with the following suffixes: .doc/.docx (MS Word), .xls/.xlsx (MS Excel), and .ppt/.pptx (MS PowerPoint), so they may click without a second thought, slashing a hole in their organizations' security. \
Following is a typical series of events, according to an [article by Trend Micro](https://blog.trendmicro.com/trendlabs-security-intelligence/rising-trend-attackers-using-lnk-files-download-malware/):\
1. Attacker sends a phishing email. Recipient downloads the attached file, which is typically a .docx or .zip file with an embedded .lnk file\
1. The .lnk file executes a PowerShell script\
1. Powershell executes a reverse shell, rendering the exploit successful </ol>As a side note, adversaries are likely to use a tool like Empire to craft and obfuscate payloads and their post-injection activities, such as [exfiltration, lateral movement, and persistence](https://github.com/EmpireProject/Empire).\
This Analytic Story focuses on detecting signs that a malicious payload has been injected into your environment. For example, one search detects outlook.exe writing a .zip file. Another looks for suspicious .lnk files launching processes.

[analytic_story://Splunk Vulnerabilities]
category = Best Practices
last_updated = 2024-01-22
version = 1
references = ["https://www.splunk.com/en_us/product-security/announcements.html"]
maintainers = [{"company": "Rod Soto, Eric McGinnis, Splunk", "email": "-", "name": "Lou Stella"}]
spec_version = 3
searches = ["ESCU - Detect Risky SPL using Pretrained ML Model - Rule", "ESCU - Path traversal SPL injection - Rule", "ESCU - Splunk Absolute Path Traversal Using runshellscript - Rule", "ESCU - Splunk Account Discovery Drilldown Dashboard Disclosure - Rule", "ESCU - Splunk App for Lookup File Editing RCE via User XSLT - Rule", "ESCU - Splunk Authentication Token Exposure in Debug Log - Rule", "ESCU - Splunk Code Injection via custom dashboard leading to RCE - Rule", "ESCU - Splunk Command and Scripting Interpreter Delete Usage - Rule", "ESCU - Splunk Command and Scripting Interpreter Risky Commands - Rule", "ESCU - Splunk Command and Scripting Interpreter Risky SPL MLTK - Rule", "ESCU - Splunk csrf in the ssg kvstore client endpoint - Rule", "ESCU - Splunk Data exfiltration from Analytics Workspace using sid query - Rule", "ESCU - Splunk Digital Certificates Infrastructure Version - Rule", "ESCU - Splunk Digital Certificates Lack of Encryption - Rule", "ESCU - Splunk DoS Using Malformed SAML Request - Rule", "ESCU - Splunk DOS Via Dump SPL Command - Rule", "ESCU - Splunk DoS via Malformed S2S Request - Rule", "ESCU - Splunk DOS via printf search function - Rule", "ESCU - Splunk Edit User Privilege Escalation - Rule", "ESCU - Splunk Endpoint Denial of Service DoS Zip Bomb - Rule", "ESCU - Splunk Enterprise KV Store Incorrect Authorization - Rule", "ESCU - Splunk Enterprise Windows Deserialization File Partition - Rule", "ESCU - Splunk ES DoS Investigations Manager via Investigation Creation - Rule", "ESCU - Splunk ES DoS Through Investigation Attachments - Rule", "ESCU - Splunk HTTP Response Splitting Via Rest SPL Command - Rule", "ESCU - Splunk Improperly Formatted Parameter Crashes splunkd - Rule", "ESCU - Splunk Information Disclosure in Splunk Add-on Builder - Rule", "ESCU - Splunk list all nonstandard admin accounts - Rule", "ESCU - Splunk Low Privilege User Can View Hashed Splunk Password - Rule", "ESCU - Splunk Path Traversal In Splunk App For Lookup File Edit - Rule", "ESCU - Persistent XSS in RapidDiag through User Interface Views - Rule", "ESCU - Splunk Persistent XSS Via URL Validation Bypass W Dashboard - Rule", "ESCU - Splunk Process Injection Forwarder Bundle Downloads - Rule", "ESCU - Splunk Protocol Impersonation Weak Encryption Configuration - Rule", "ESCU - Splunk protocol impersonation weak encryption selfsigned - Rule", "ESCU - Splunk protocol impersonation weak encryption simplerequest - Rule", "ESCU - Splunk RBAC Bypass On Indexing Preview REST Endpoint - Rule", "ESCU - Splunk RCE via Serialized Session Payload - Rule", "ESCU - Splunk RCE via Splunk Secure Gateway  Splunk Mobile alerts feature - Rule", "ESCU - Splunk RCE via User XSLT - Rule", "ESCU - Splunk Reflected XSS in the templates lists radio - Rule", "ESCU - Splunk Reflected XSS on App Search Table Endpoint - Rule", "ESCU - Splunk risky Command Abuse disclosed february 2023 - Rule", "ESCU - Splunk Stored XSS via Data Model objectName field - Rule", "ESCU - Splunk Unauthenticated Log Injection Web Service Log - Rule", "ESCU - Splunk unnecessary file extensions allowed by lookup table uploads - Rule", "ESCU - Splunk User Enumeration Attempt - Rule", "ESCU - Splunk XSS in Highlighted JSON Events - Rule", "ESCU - Splunk XSS in Monitoring Console - Rule", "ESCU - Splunk XSS in Save table dialog header in search page - Rule", "ESCU - Splunk XSS via View - Rule", "ESCU - Open Redirect in Splunk Web - Rule", "ESCU - Splunk Enterprise Information Disclosure - Rule", "ESCU - Splunk Identified SSL TLS Certificates - Rule"]
description = Keeping your Splunk Enterprise deployment up to date is critical and will help you reduce the risk associated with vulnerabilities in the product.
narrative = This analytic story includes detections that focus on attacker behavior targeted at your Splunk environment directly.

[analytic_story://Spring4Shell CVE-2022-22965]
category = Adversary Tactics
last_updated = 2022-04-05
version = 1
references = ["https://www.tenable.com/blog/spring4shell-faq-spring-framework-remote-code-execution-vulnerability"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Java Writing JSP File - Rule", "ESCU - Linux Java Spawning Shell - Rule", "ESCU - Spring4Shell Payload URL Request - Rule", "ESCU - Web JSP Request via URL - Rule", "ESCU - Web Spring4Shell HTTP Request Class Module - Rule", "ESCU - Web Spring Cloud Function FunctionRouter - Rule"]
description = Spring4Shell is the nickname given to a zero-day vulnerability in the Spring Core Framework, a programming and configuration model for Java-based enterprise applications.
narrative = An attacker could exploit Spring4Shell by sending a specially crafted request to a vulnerable server. However, exploitation of Spring4Shell requires certain prerequisites, whereas the original Log4Shell vulnerability affected all versions of Log4j 2 using the default configuration. \
According to Spring, the following requirements were included in the vulnerability report, however the post cautions that there may be other ways in which this can be exploited so this may not be a complete list of requirements at this time: \
- Java Development Kit (JDK) 9 or greater \
- Apache Tomcat as the Servlet container \
- Packaged as a WAR \
- spring-webmvc or spring-webflux dependency \


[analytic_story://SQL Injection]
category = Adversary Tactics
last_updated = 2017-09-19
version = 1
references = ["https://capec.mitre.org/data/definitions/66.html", "https://www.incapsula.com/web-application-security/sql-injection.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - SQL Injection with Long URLs - Rule", "ESCU - Get Notable History - Response Task"]
description = Use the searches in this Analytic Story to help you detect structured query language (SQL) injection attempts characterized by long URLs that contain malicious parameters.
narrative = It is very common for attackers to inject SQL parameters into vulnerable web applications, which then interpret the malicious SQL statements.\
This Analytic Story contains a search designed to identify attempts by attackers to leverage this technique to compromise a host and gain a foothold in the target environment.

[analytic_story://Subvert Trust Controls SIP and Trust Provider Hijacking]
category = Adversary Tactics
last_updated = 2023-10-10
version = 1
references = ["https://attack.mitre.org/techniques/T1553/003/", "https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_sip_persistence.yml", "https://specterops.io/wp-content/uploads/sites/3/2022/06/SpecterOps_Subverting_Trust_in_Windows.pdf", "https://github.com/gtworek/PSBits/tree/master/SIP", "https://github.com/mattifestation/PoCSubjectInterfacePackage", "https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Registry SIP Provider Modification - Rule", "ESCU - Windows SIP Provider Inventory - Rule", "ESCU - Windows SIP WinVerifyTrust Failed Trust Validation - Rule"]
description = Adversaries may tamper with SIP and trust provider components to mislead the operating system and application control tools when conducting signature validation checks. This technique involves modifying the Dll and FuncName Registry values that point to the dynamic link library (DLL) providing a SIP's function, which retrieves an encoded digital certificate from a signed file. By pointing to a maliciously-crafted DLL with an exported function that always returns a known good signature value, an adversary can apply an acceptable signature value to all files using that SIP. This can also enable persistent code execution, since these malicious components may be invoked by any application that performs code signing or signature validation.
narrative = In user mode, Windows Authenticode digital signatures are used to verify a file's origin and integrity, variables that may be used to establish trust in signed code. The signature validation process is handled via the WinVerifyTrust application programming interface (API) function, which accepts an inquiry and coordinates with the appropriate trust provider, which is responsible for validating parameters of a signature. Because of the varying executable file types and corresponding signature formats, Microsoft created software components called Subject Interface Packages (SIPs) to provide a layer of abstraction between API functions and files. SIPs are responsible for enabling API functions to create, retrieve, calculate, and verify signatures. Unique SIPs exist for most file formats and are identified by globally unique identifiers (GUIDs). Adversaries may hijack SIP and trust provider components to mislead operating system and application control tools to classify malicious (or any) code as signed.

[analytic_story://Suspicious AWS Login Activities]
category = Cloud Security
last_updated = 2019-05-01
version = 1
references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - AWS Successful Console Authentication From Multiple IPs - Rule", "ESCU - Detect AWS Console Login by User from New City - Rule", "ESCU - Detect AWS Console Login by User from New Country - Rule", "ESCU - Detect AWS Console Login by User from New Region - Rule", "ESCU - Detect new user AWS Console Login - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task"]
description = Monitor your AWS authentication events using your CloudTrail logs. Searches within this Analytic Story will help you stay aware of and investigate suspicious logins. 
narrative = It is important to monitor and control who has access to your AWS infrastructure. Detecting suspicious logins to your AWS infrastructure will provide good starting points for investigations. Abusive behaviors caused by compromised credentials can lead to direct monetary costs, as you will be billed for any EC2 instances created by the attacker.

[analytic_story://Suspicious AWS S3 Activities]
category = Cloud Security
last_updated = 2023-04-24
version = 3
references = ["https://github.com/nagwww/s3-leaks", "https://www.tripwire.com/state-of-security/security-data-protection/cloud/public-aws-s3-buckets-writable/", null]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - AWS Disable Bucket Versioning - Rule", "ESCU - AWS Exfiltration via Bucket Replication - Rule", "ESCU - AWS Exfiltration via DataSync Task - Rule", "ESCU - Detect New Open S3 buckets - Rule", "ESCU - Detect New Open S3 Buckets over AWS CLI - Rule", "ESCU - Detect S3 access from a new IP - Rule", "ESCU - Detect Spike in S3 Bucket deletion - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - AWS S3 Bucket details via bucketName - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Investigate AWS activities via region name - Response Task"]
description = Use the searches in this Analytic Story using Cloudtrail logs to to monitor your AWS S3 buckets for evidence of anomalous activity and suspicious behaviors, such as detecting open S3 buckets and buckets being accessed from a new IP, permission and policy updates to the bucket, potential misuse of other services leading to data being leaked.
narrative = One of the most common ways that attackers attempt to steal data from S3 is by gaining unauthorized access to S3 buckets and copying or exfiltrating data to external locations.\
However, suspicious S3 activities can refer to any unusual behavior detected within an Amazon Web Services (AWS) Simple Storage Service (S3) bucket, including unauthorized access, unusual data transfer patterns, and access attempts from unknown IP addresses. \
It is important for organizations to regularly monitor S3 activities for suspicious behavior and implement security best practices, such as using access controls, encryption, and strong authentication mechanisms, to protect sensitive data stored within S3 buckets. By staying vigilant and taking proactive measures, organizations can help prevent potential security breaches and minimize the impact of attacks if they do occur.

[analytic_story://Suspicious AWS Traffic]
category = Cloud Security
last_updated = 2018-05-07
version = 1
references = ["https://rhinosecuritylabs.com/aws/hiding-cloudcobalt-strike-beacon-c2-using-amazon-apis/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect Spike in blocked Outbound Traffic from your AWS - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - AWS Network ACL Details from ID - Response Task", "ESCU - AWS Network Interface details via resourceId - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Information For Port Activity - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Leverage these searches to monitor your AWS network traffic for evidence of anomalous activity and suspicious behaviors, such as a spike in blocked outbound traffic in your virtual private cloud (VPC).
narrative = A virtual private cloud (VPC) is an on-demand managed cloud-computing service that isolates computing resources for each client. Inside the VPC container, the environment resembles a physical network. \
Amazon's VPC service enables you to launch EC2 instances and leverage other Amazon resources. The traffic that flows in and out of this VPC can be controlled via network access-control rules and security groups. Amazon also has a feature called VPC Flow Logs that enables you to log IP traffic going to and from the network interfaces in your VPC. This data is stored using Amazon CloudWatch Logs.\
 Attackers may abuse the AWS infrastructure with insecure VPCs so they can co-opt AWS resources for command-and-control nodes, data exfiltration, and more. Once an EC2 instance is compromised, an attacker may initiate outbound network connections for malicious reasons. Monitoring these network traffic behaviors is crucial for understanding the type of traffic flowing in and out of your network and to alert you to suspicious activities.\
The searches in this Analytic Story will monitor your AWS network traffic for evidence of anomalous activity and suspicious behaviors.

[analytic_story://Suspicious Cloud Authentication Activities]
category = Cloud Security
last_updated = 2020-06-04
version = 1
references = ["https://aws.amazon.com/blogs/security/aws-cloudtrail-now-tracks-cross-account-activity-to-its-origin/", "https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - AWS Cross Account Activity From Previously Unseen Account - Rule", "ESCU - Detect AWS Console Login by New User - Rule", "ESCU - Detect AWS Console Login by User from New City - Rule", "ESCU - Detect AWS Console Login by User from New Country - Rule", "ESCU - Detect AWS Console Login by User from New Region - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Investigate AWS User Activities by user field - Response Task"]
description = Monitor your cloud authentication events. Searches within this Analytic Story leverage the recent cloud updates to the Authentication data model to help you stay aware of and investigate suspicious login activity. 
narrative = It is important to monitor and control who has access to your cloud infrastructure. Detecting suspicious logins will provide good starting points for investigations. Abusive behaviors caused by compromised credentials can lead to direct monetary costs, as you will be billed for any compute activity whether legitimate or otherwise.\
This Analytic Story has data model versions of cloud searches leveraging Authentication data, including those looking for suspicious login activity, and cross-account activity for AWS.

[analytic_story://Suspicious Cloud Instance Activities]
category = Cloud Security
last_updated = 2020-08-25
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Abnormally High Number Of Cloud Instances Destroyed - Rule", "ESCU - Abnormally High Number Of Cloud Instances Launched - Rule", "ESCU - AWS AMI Attribute Modification for Exfiltration - Rule", "ESCU - AWS EC2 Snapshot Shared Externally - Rule", "ESCU - AWS Exfiltration via EC2 Snapshot - Rule", "ESCU - AWS S3 Exfiltration Behavior Identified - Rule", "ESCU - Cloud Instance Modified By Previously Unseen User - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task", "ESCU - Get All AWS Activity From IP Address - Response Task"]
description = Monitor your cloud infrastructure provisioning activities for behaviors originating from unfamiliar or unusual locations. These behaviors may indicate that malicious activities are occurring somewhere within your cloud environment.
narrative = Monitoring your cloud infrastructure logs allows you enable governance, compliance, and risk auditing. It is crucial for a company to monitor events and actions taken in the their cloud environments to ensure that your instances are not vulnerable to attacks. This Analytic Story identifies suspicious activities in your cloud compute instances and helps you respond and investigate those activities.

[analytic_story://Suspicious Cloud Provisioning Activities]
category = Cloud Security
last_updated = 2018-08-20
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Cloud Provisioning Activity From Previously Unseen City - Rule", "ESCU - Cloud Provisioning Activity From Previously Unseen Country - Rule", "ESCU - Cloud Provisioning Activity From Previously Unseen IP Address - Rule", "ESCU - Cloud Provisioning Activity From Previously Unseen Region - Rule", "ESCU - Get Notable History - Response Task"]
description = Monitor your cloud infrastructure provisioning activities for behaviors originating from unfamiliar or unusual locations. These behaviors may indicate that malicious activities are occurring somewhere within your cloud environment.
narrative = Because most enterprise cloud infrastructure activities originate from familiar geographic locations, monitoring for activity from unknown or unusual regions is an important security measure. This indicator can be especially useful in environments where it is impossible to add specific IPs to an allow list because they vary.\
This Analytic Story was designed to provide you with flexibility in the precision you employ in specifying legitimate geographic regions. It can be as specific as an IP address or a city, or as broad as a region (think state) or an entire country. By determining how precise you want your geographical locations to be and monitoring for new locations that haven't previously accessed your environment, you can detect adversaries as they begin to probe your environment. Since there are legitimate reasons for activities from unfamiliar locations, this is not a standalone indicator. Nevertheless, location can be a relevant piece of information that you may wish to investigate further.

[analytic_story://Suspicious Cloud User Activities]
category = Cloud Security
last_updated = 2020-09-04
version = 1
references = ["https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf", "https://redlock.io/blog/cryptojacking-tesla"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Abnormally High Number Of Cloud Infrastructure API Calls - Rule", "ESCU - Abnormally High Number Of Cloud Security Group API Calls - Rule", "ESCU - AWS IAM AccessDenied Discovery Events - Rule", "ESCU - AWS Lambda UpdateFunctionCode - Rule", "ESCU - Cloud API Calls From Previously Unseen User Roles - Rule", "ESCU - Cloud Security Groups Modifications by User - Rule", "ESCU - AWS Investigate User Activities By ARN - Response Task"]
description = Detect and investigate suspicious activities by users and roles in your cloud environments.
narrative = It seems obvious that it is critical to monitor and control the users who have access to your cloud infrastructure. Nevertheless, it's all too common for enterprises to lose track of ad-hoc accounts, leaving their servers vulnerable to attack. In fact, this was the very oversight that led to Tesla's cryptojacking attack in February, 2018.\
In addition to compromising the security of your data, when bad actors leverage your compute resources, it can incur monumental costs, since you will be billed for any new instances and increased bandwidth usage.

[analytic_story://Suspicious Command-Line Executions]
category = Adversary Tactics
last_updated = 2020-02-03
version = 2
references = ["https://attack.mitre.org/wiki/Technique/T1059", "https://www.microsoft.com/en-us/wdsi/threats/macro-malware", "https://www.fireeye.com/content/dam/fireeye-www/services/pdfs/mandiant-apt1-report.pdf"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - First time seen command line argument - Rule", "ESCU - Detect Prohibited Applications Spawning cmd exe - Rule", "ESCU - Detect suspicious processnames using pretrained model in DSDL - Rule", "ESCU - Detect Use of cmd exe to Launch Script Interpreters - Rule", "ESCU - Potentially malicious code on commandline - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Unusually Long Command Line - Rule", "ESCU - Unusually Long Command Line - MLTK - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Leveraging the Windows command-line interface (CLI) is one of the most common attack techniques--one that is also detailed in the MITRE ATT&CK framework. Use this Analytic Story to help you identify unusual or suspicious use of the CLI on Windows systems.
narrative = The ability to execute arbitrary commands via the Windows CLI is a primary goal for the adversary. With access to the shell, an attacker can easily run scripts and interact with the target system. Often, attackers may only have limited access to the shell or may obtain access in unusual ways. In addition, malware may execute and interact with the CLI in ways that would be considered unusual and inconsistent with typical user activity. This provides defenders with opportunities to identify suspicious use and investigate, as appropriate. This Analytic Story contains various searches to help identify this suspicious activity, as well as others to aid you in deeper investigation.

[analytic_story://Suspicious Compiled HTML Activity]
category = Adversary Tactics
last_updated = 2021-02-11
version = 1
references = ["https://redcanary.com/blog/introducing-atomictestharnesses/", "https://attack.mitre.org/techniques/T1218/001/", "https://docs.microsoft.com/en-us/windows/win32/api/htmlhelp/nf-htmlhelp-htmlhelpa"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect HTML Help Renamed - Rule", "ESCU - Detect HTML Help Spawn Child Process - Rule", "ESCU - Detect HTML Help URL in Command Line - Rule", "ESCU - Detect HTML Help Using InfoTech Storage Handlers - Rule", "ESCU - Windows System Binary Proxy Execution Compiled HTML File Decompile - Rule"]
description = Monitor and detect techniques used by attackers who leverage the mshta.exe process to execute malicious code.
narrative = Adversaries may abuse Compiled HTML files (.chm) to conceal malicious code. CHM files are commonly distributed as part of the Microsoft HTML Help system. CHM files are compressed compilations of various content such as HTML documents, images, and scripting/web related programming languages such VBA, JScript, Java, and ActiveX. CHM content is displayed using underlying components of the Internet Explorer browser loaded by the HTML Help executable program (hh.exe). \
HH.exe relies upon hhctrl.ocx to load CHM topics.This will load upon execution of a chm file. \
During investigation, review all parallel processes and child processes. It is possible for file modification events to occur and it is best to capture the CHM file and decompile it for further analysis. \
Upon usage of InfoTech Storage Handlers, ms-its, its, mk, itss.dll will load.

[analytic_story://Suspicious DNS Traffic]
category = Adversary Tactics
last_updated = 2017-09-18
version = 1
references = ["http://blogs.splunk.com/2015/10/01/random-words-on-entropy-and-dns/", "http://www.darkreading.com/analytics/security-monitoring/got-malware-three-signs-revealed-in-dns-traffic/d/d-id/1139680", "https://live.paloaltonetworks.com/t5/Threat-Vulnerability-Articles/What-are-suspicious-DNS-queries/ta-p/71454"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Clients Connecting to Multiple DNS Servers - Rule", "ESCU - Detect Long DNS TXT Record Response - Rule", "ESCU - Detection of DNS Tunnels - Rule", "ESCU - DNS Query Requests Resolved by Unauthorized DNS Servers - Rule", "ESCU - DNS Exfiltration Using Nslookup App - Rule", "ESCU - Excessive Usage of NSLOOKUP App - Rule", "ESCU - Detect DGA domains using pretrained model in DSDL - Rule", "ESCU - Detect DNS Data Exfiltration using pretrained model in DSDL - Rule", "ESCU - Detect hosts connecting to dynamic domain providers - Rule", "ESCU - Detect suspicious DNS TXT records using pretrained model in DSDL - Rule", "ESCU - DNS Query Length Outliers - MLTK - Rule", "ESCU - DNS Query Length With High Standard Deviation - Rule", "ESCU - Excessive DNS Failures - Rule", "ESCU - Get DNS Server History for a host - Response Task", "ESCU - Get DNS traffic ratio - Response Task", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Process Responsible For The DNS Traffic - Response Task"]
description = Attackers often attempt to hide within or otherwise abuse the domain name system (DNS). You can thwart attempts to manipulate this omnipresent protocol by monitoring for these types of abuses.
narrative = Although DNS is one of the fundamental underlying protocols that make the Internet work, it is often ignored (perhaps because of its complexity and effectiveness).  However, attackers have discovered ways to abuse the protocol to meet their objectives. One potential abuse involves manipulating DNS to hijack traffic and redirect it to an IP address under the attacker's control. This could inadvertently send users intending to visit google.com, for example, to an unrelated malicious website. Another technique involves using the DNS protocol for command-and-control activities with the attacker's malicious code or to covertly exfiltrate data. The searches within this Analytic Story look for these types of abuses.

[analytic_story://Suspicious Emails]
category = Adversary Tactics
last_updated = 2020-01-27
version = 1
references = ["https://www.splunk.com/blog/2015/06/26/phishing-hits-a-new-level-of-quality/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Email Attachments With Lots Of Spaces - Rule", "ESCU - Monitor Email For Brand Abuse - Rule", "ESCU - Suspicious Email Attachment Extensions - Rule", "ESCU - Suspicious Email - UBA Anomaly - Rule", "ESCU - Get Email Info - Response Task", "ESCU - Get Emails From Specific Sender - Response Task", "ESCU - Get Notable History - Response Task"]
description = Email remains one of the primary means for attackers to gain an initial foothold within the modern enterprise. Detect and investigate suspicious emails in your environment with the help of the searches in this Analytic Story.
narrative = It is a common practice for attackers of all types to leverage targeted spearphishing campaigns and mass mailers to deliver weaponized email messages and attachments. Fortunately, there are a number of ways to monitor email data in Splunk to detect suspicious content.\
Once a phishing message has been detected, the next steps are to answer the following questions: \
1. Which users have received this or a similar message in the past?\
1. When did the targeted campaign begin?\
1. Have any users interacted with the content of the messages (by downloading an attachment or clicking on a malicious URL)?This Analytic Story provides detection searches to identify suspicious emails, as well as contextual and investigative searches to help answer some of these questions.

[analytic_story://Suspicious GCP Storage Activities]
category = Cloud Security
last_updated = 2020-08-05
version = 1
references = ["https://cloud.google.com/blog/products/gcp/4-steps-for-hardening-your-cloud-storage-buckets-taking-charge-of-your-security", "https://rhinosecuritylabs.com/gcp/google-cloud-platform-gcp-bucket-enumeration/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Shannon Davis"}]
spec_version = 3
searches = ["ESCU - Detect GCP Storage access from a new IP - Rule", "ESCU - Detect New Open GCP Storage Buckets - Rule", "ESCU - Get Notable History - Response Task"]
description = Use the searches in this Analytic Story to monitor your GCP Storage buckets for evidence of anomalous activity and suspicious behaviors, such as detecting open storage buckets and buckets being accessed from a new IP. The contextual and investigative searches will give you more information, when required.
narrative = Similar to other cloud providers, GCP operates on a shared responsibility model. This means the end user, you, are responsible for setting appropriate access control lists and permissions on your GCP resources.\ This Analytics Story concentrates on detecting things like open storage buckets (both read and write) along with storage bucket access from unfamiliar users and IP addresses.

[analytic_story://Suspicious MSHTA Activity]
category = Adversary Tactics
last_updated = 2021-01-20
version = 2
references = ["https://redcanary.com/blog/introducing-atomictestharnesses/", "https://redcanary.com/blog/windows-registry-attacks-threat-detection/", "https://attack.mitre.org/techniques/T1218/005/", "https://medium.com/@mbromileyDFIR/malware-monday-aebb456356c5"]
maintainers = [{"company": "Michael Haag, Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Detect mshta inline hta execution - Rule", "ESCU - Detect mshta renamed - Rule", "ESCU - Detect MSHTA Url in Command Line - Rule", "ESCU - Detect Prohibited Applications Spawning cmd exe - Rule", "ESCU - Detect Rundll32 Inline HTA Execution - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Suspicious mshta child process - Rule", "ESCU - Suspicious mshta spawn - Rule", "ESCU - Windows MSHTA Writing to World Writable Path - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Monitor and detect techniques used by attackers who leverage the mshta.exe process to execute malicious code.
narrative = One common adversary tactic is to bypass application control solutions via the mshta.exe process, which loads Microsoft HTML applications (mshtml.dll) with the .hta suffix. In these cases, attackers use the trusted Windows utility to proxy execution of malicious files, whether an .hta application, javascript, or VBScript.\
The searches in this story help you detect and investigate suspicious activity that may indicate that an attacker is leveraging mshta.exe to execute malicious code.\
Triage\
Validate execution \
1. Determine if MSHTA.exe executed. Validate the OriginalFileName of MSHTA.exe and further PE metadata. If executed outside of c:\windows\system32 or c:\windows\syswow64, it should be highly suspect.\
1. Determine if script code was executed with MSHTA.\
Situational Awareness\
The objective of this step is meant to identify suspicious behavioral indicators related to executed of Script code by MSHTA.exe.\
1. Parent process. Is the parent process a known LOLBin? Is the parent process an Office Application?\
1. Module loads. Are the known MSHTA.exe modules being loaded by a non-standard application? Is MSHTA loading any suspicious .DLLs?\
1. Network connections. Any network connections? Review the reputation of the remote IP or domain.\
Retrieval of script code\
The objective of this step is to confirm the executed script code is benign or malicious.

[analytic_story://Suspicious Okta Activity]
category = Adversary Tactics
last_updated = 2020-04-02
version = 1
references = ["https://attack.mitre.org/wiki/Technique/T1078", "https://owasp.org/www-community/attacks/Credential_stuffing", "https://searchsecurity.techtarget.com/answer/What-is-a-password-spraying-attack-and-how-does-it-work"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Okta IDP Lifecycle Modifications - Rule", "ESCU - Okta Risk Threshold Exceeded - Rule", "ESCU - Okta Suspicious Use of a Session Cookie - Rule", "ESCU - Multiple Okta Users With Invalid Credentials From The Same IP - Rule", "ESCU - Okta Account Locked Out - Rule", "ESCU - Okta Account Lockout Events - Rule", "ESCU - Okta Failed SSO Attempts - Rule", "ESCU - Okta ThreatInsight Login Failure with High Unknown users - Rule", "ESCU - Okta ThreatInsight Suspected PasswordSpray Attack - Rule", "ESCU - Okta Two or More Rejected Okta Pushes - Rule", "ESCU - Investigate Okta Activity by app - Response Task", "ESCU - Investigate Okta Activity by IP Address - Response Task", "ESCU - Investigate User Activities In Okta - Response Task"]
description = Monitor your Okta environment for suspicious activities. Due to the Covid outbreak, many users are migrating over to leverage cloud services more and more. Okta is a popular tool to manage multiple users and the web-based applications they need to stay productive. The searches in this story will help monitor your Okta environment for suspicious activities and associated user behaviors.
narrative = Okta is the leading single sign on (SSO) provider, allowing users to authenticate once to Okta, and from there access a variety of web-based applications. These applications are assigned to users and allow administrators to centrally manage which users are allowed to access which applications. It also provides centralized logging to help understand how the applications are used and by whom. \
While SSO is a major convenience for users, it also provides attackers with an opportunity. If the attacker can gain access to Okta, they can access a variety of applications. As such monitoring the environment is important. \
With people moving quickly to adopt web-based applications and ways to manage them, many are still struggling to understand how best to monitor these environments. This analytic story provides searches to help monitor this environment, and identify events and activity that warrant further investigation such as credential stuffing or password spraying attacks, and users logging in from multiple locations when travel is disallowed.

[analytic_story://Suspicious Regsvcs Regasm Activity]
category = Adversary Tactics
last_updated = 2021-02-11
version = 1
references = ["https://attack.mitre.org/techniques/T1218/009/", "https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/evasion/windows/applocker_evasion_regasm_regsvcs.md", "https://oddvar.moe/2017/12/13/applocker-case-study-how-insecure-is-it-really-part-1/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Regasm Spawning a Process - Rule", "ESCU - Detect Regasm with Network Connection - Rule", "ESCU - Detect Regasm with no Command Line Arguments - Rule", "ESCU - Detect Regsvcs Spawning a Process - Rule", "ESCU - Detect Regsvcs with Network Connection - Rule", "ESCU - Detect Regsvcs with No Command Line Arguments - Rule"]
description = Monitor and detect techniques used by attackers who leverage the mshta.exe process to execute malicious code.
narrative =  Adversaries may abuse Regsvcs and Regasm to proxy execution of code through a trusted Windows utility. Regsvcs and Regasm are Windows command-line utilities that are used to register .NET Component Object Model (COM) assemblies. Both are digitally signed by Microsoft. The following queries assist with detecting suspicious and malicious usage of Regasm.exe and Regsvcs.exe. Upon reviewing usage of Regasm.exe Regsvcs.exe, review file modification events for possible script code written. Review parallel process events for csc.exe being utilized to compile script code.

[analytic_story://Suspicious Regsvr32 Activity]
category = Adversary Tactics
last_updated = 2021-01-29
version = 1
references = ["https://attack.mitre.org/techniques/T1218/010/", "https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1218.010/T1218.010.md", "https://lolbas-project.github.io/lolbas/Binaries/Regsvr32/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Regsvr32 Application Control Bypass - Rule", "ESCU - Malicious InProcServer32 Modification - Rule", "ESCU - Regsvr32 Silent and Install Param Dll Loading - Rule", "ESCU - Regsvr32 with Known Silent Switch Cmdline - Rule", "ESCU - Suspicious Regsvr32 Register Suspicious Path - Rule"]
description = Monitor and detect techniques used by attackers who leverage the regsvr32.exe process to execute malicious code.
narrative = One common adversary tactic is to bypass application control solutions via the regsvr32.exe process. This particular bypass was popularized with "SquiblyDoo" using the "scrobj.dll" dll to load .sct scriptlets. This technique is still widely used by adversaries to bypass detection and prevention controls. The file extension of the DLL is irrelevant (it may load a .txt file extension for example). The searches in this story help you detect and investigate suspicious activity that may indicate that an adversary is leveraging regsvr32.exe to execute malicious code. Validate execution Determine if regsvr32.exe executed. Validate the OriginalFileName of regsvr32.exe and further PE metadata. If executed outside of c:\windows\system32 or c:\windows\syswow64, it should be highly suspect. Determine if script code was executed with regsvr32. Situational Awareness - The objective of this step is meant to identify suspicious behavioral indicators related to executed of Script code by regsvr32.exe. Parent process. Is the parent process a known LOLBin? Is the parent process an Office Application? Module loads.  Is regsvr32 loading any suspicious .DLLs? Unsigned or signed from non-standard paths. Network connections. Any network connections? Review the reputation of the remote IP or domain. Retrieval of Script Code - confirm the executed script code is benign or malicious.

[analytic_story://Suspicious Rundll32 Activity]
category = Adversary Tactics
last_updated = 2021-02-03
version = 1
references = ["https://attack.mitre.org/techniques/T1218/011/", "https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1218.011/T1218.011.md", "https://lolbas-project.github.io/lolbas/Binaries/Rundll32"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Suspicious Rundll32 Rename - Rule", "ESCU - Detect Rundll32 Application Control Bypass - advpack - Rule", "ESCU - Detect Rundll32 Application Control Bypass - setupapi - Rule", "ESCU - Detect Rundll32 Application Control Bypass - syssetup - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Rundll32 Control RunDLL Hunt - Rule", "ESCU - Rundll32 Control RunDLL World Writable Directory - Rule", "ESCU - Rundll32 with no Command Line Arguments with Network - Rule", "ESCU - RunDLL Loading DLL By Ordinal - Rule", "ESCU - Suspicious Rundll32 dllregisterserver - Rule", "ESCU - Suspicious Rundll32 no Command Line Arguments - Rule", "ESCU - Suspicious Rundll32 StartW - Rule"]
description = Monitor and detect techniques used by attackers who leverage rundll32.exe to execute arbitrary malicious code.
narrative = One common adversary tactic is to bypass application control solutions via the rundll32.exe process. Natively, rundll32.exe will load DLLs and is a great example of a Living off the Land Binary. Rundll32.exe may load malicious DLLs by ordinals, function names or directly. The queries in this story focus on loading default DLLs, syssetup.dll, ieadvpack.dll, advpack.dll and setupapi.dll from disk that may be abused by adversaries. Additionally, two analytics developed to assist with identifying DLLRegisterServer, Start and StartW functions being called. The searches in this story help you detect and investigate suspicious activity that may indicate that an adversary is leveraging rundll32.exe to execute malicious code.

[analytic_story://Suspicious Windows Registry Activities]
category = Adversary Tactics
last_updated = 2018-05-31
version = 1
references = ["https://redcanary.com/blog/windows-registry-attacks-threat-detection/", "https://attack.mitre.org/wiki/Technique/T1112"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Reg exe used to hide files directories via registry keys - Rule", "ESCU - Remote Registry Key modifications - Rule", "ESCU - Suspicious Changes to File Associations - Rule", "ESCU - Disable UAC Remote Restriction - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Monitor Registry Keys for Print Monitors - Rule", "ESCU - Registry Keys for Creating SHIM Databases - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Registry Keys Used For Privilege Escalation - Rule", "ESCU - Windows Mshta Execution In Registry - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Monitor and detect registry changes initiated from remote locations, which can be a sign that an attacker has infiltrated your system.
narrative = Attackers are developing increasingly sophisticated techniques for hijacking target servers, while evading detection. One such technique that has become progressively more common is registry modification.\
 The registry is a key component of the Windows operating system. It has a hierarchical database called "registry" that contains settings, options, and values for executables. Once the threat actor gains access to a machine, they can use reg.exe to modify their account to obtain administrator-level privileges, maintain persistence, and move laterally within the environment.\
 The searches in this story are designed to help you detect behaviors associated with manipulation of the Windows registry.

[analytic_story://Suspicious WMI Use]
category = Adversary Tactics
last_updated = 2018-10-23
version = 2
references = ["https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf", "https://web.archive.org/web/20210921091529/https://www.fireeye.com/blog/threat-research/2017/03/wmimplant_a_wmi_ba.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Detect WMI Event Subscription Persistence - Rule", "ESCU - PowerShell Invoke WmiExec Usage - Rule", "ESCU - Process Execution via WMI - Rule", "ESCU - Remote Process Instantiation via WMI - Rule", "ESCU - Remote WMI Command Attempt - Rule", "ESCU - Script Execution via WMI - Rule", "ESCU - Windows WMI Process Call Create - Rule", "ESCU - WMI Permanent Event Subscription - Rule", "ESCU - WMI Permanent Event Subscription - Sysmon - Rule", "ESCU - WMI Temporary Event Subscription - Rule", "ESCU - WMIC XSL Execution via URL - Rule", "ESCU - XSL Script Execution With WMIC - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task", "ESCU - Get Sysmon WMI Activity for Host - Response Task"]
description = Attackers are increasingly abusing Windows Management Instrumentation (WMI), a framework and associated utilities available on all modern Windows operating systems. Because WMI can be leveraged to manage both local and remote systems, it is important to identify the processes executed and the user context within which the activity occurred.
narrative = WMI is a Microsoft infrastructure for management data and operations on Windows operating systems. It includes of a set of utilities that can be leveraged to manage both local and remote Windows systems. Attackers are increasingly turning to WMI abuse in their efforts to conduct nefarious tasks, such as reconnaissance, detection of antivirus and virtual machines, code execution, lateral movement, persistence, and data exfiltration. The detection searches included in this Analytic Story are used to look for suspicious use of WMI commands that attackers may leverage to interact with remote systems. The searches specifically look for the use of WMI to run processes on remote systems. In the event that unauthorized WMI execution occurs, it will be important for analysts and investigators to determine the context of the event. These details may provide insights related to how WMI was used and to what end.

[analytic_story://Suspicious Zoom Child Processes]
category = Adversary Tactics
last_updated = 2020-04-13
version = 1
references = ["https://blog.rapid7.com/2020/04/02/dispelling-zoom-bugbears-what-you-need-to-know-about-the-latest-zoom-vulnerabilities/", "https://threatpost.com/two-zoom-zero-day-flaws-uncovered/154337/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Detect Prohibited Applications Spawning cmd exe - Rule", "ESCU - First Time Seen Child Process of Zoom - Rule", "ESCU - Get Process File Activity - Response Task"]
description = Attackers are using Zoom as an vector to increase privileges on a sytems. This story detects new child processes of zoom and provides investigative actions for this detection.
narrative = Zoom is a leader in modern enterprise video communications and its usage has increased dramatically with a large amount of the population under stay-at-home orders due to the COVID-19 pandemic. With increased usage has come increased scrutiny and several security flaws have been found with this application on both Windows and macOS systems.\
Current detections focus on finding new child processes of this application on a per host basis. Investigative searches are included to gather information needed during an investigation.

[analytic_story://Swift Slicer]
category = Data Destruction
last_updated = 2023-02-01
version = 1
references = ["https://twitter.com/ESETresearch/status/1618960022150729728", "https://www.welivesecurity.com/2023/01/27/swiftslicer-new-destructive-wiper-malware-ukraine/"]
maintainers = [{"company": "Rod Soto, Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Data Destruction Recursive Exec Files Deletion - Rule", "ESCU - Windows High File Deletion Frequency - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the swift slicer malware including overwriting of files and etc.
narrative = Swift Slicer is one of Windows destructive malware found by ESET that was used in a targeted organizarion to wipe critical files like windows drivers and other files to destroy and left the machine inoperable. This malware like Caddy Wiper was deliver through GPO which suggests that the attacker had taken control of the victims active directory environment.

[analytic_story://SysAid On-Prem Software CVE-2023-47246 Vulnerability]
category = Malware
last_updated = 2023-11-09
version = 1
references = ["https://www.sysaid.com/blog/service-desk/on-premise-software-security-vulnerability-notification"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Any Powershell DownloadString - Rule", "ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - Java Writing JSP File - Rule", "ESCU - Windows Java Spawning Shells - Rule"]
description = A zero-day vulnerability was discovered in SysAid's on-premise software, exploited by the group DEV-0950 (Lace Tempest). The attackers uploaded a WebShell and other payloads, gaining unauthorized access and control. SysAid has released a patch (version 23.3.36) to remediate the vulnerability and urges customers to conduct a comprehensive compromise assessment.
narrative = The analytics tagged to this analytic story will aid in capturing initial access and some post-exploitation activities. In addition to the application spawning a shell, consider reviewing STRT's Cobalt Strike and PowerShell script block logging analytic stories. On November 2nd, SysAid's security team identified a potential vulnerability in their on-premise software. The investigation revealed a zero-day vulnerability exploited by the group known as DEV-0950 (Lace Tempest). The attackers uploaded a WebShell and other payloads into the webroot of the SysAid Tomcat web service, thereby gaining unauthorized access and control over the affected system. SysAid promptly initiated their incident response protocol and began proactive communication with their on-premise customers to implement a mitigation solution. SysAid has released a patch (version 23.3.36) to remediate the vulnerability and strongly recommends all customers to conduct a comprehensive compromise assessment of their network.

[analytic_story://Text4Shell CVE-2022-42889]
category = Adversary Tactics
last_updated = 2022-10-26
version = 1
references = ["https://sysdig.com/blog/cve-2022-42889-text4shell/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Exploit Public Facing Application via Apache Commons Text - Rule"]
description = A new critical vulnerability CVE-2022-42889 a.k.a. Text4shell, similar to the old Spring4Shell and Log4Shell, was originally reported by Alvaro Munoz on the very popular Apache Commons Text library.
narrative = Apache Commons Text is a Java library described as "a library focused on algorithms working on strings." We can see it as a general-purpose text manipulation toolkit. This vulnerability affects the StringSubstitutor interpolator class, which is included in the Commons Text library. A default interpolator allows for string lookups that can lead to Remote Code Execution. This is due to a logic flaw that makes the "script," "dns," and "url" lookup keys interpolated by default, as opposed to what it should be, according to the documentation of the StringLookupFactory class. Those keys allow an attacker to execute arbitrary code via lookups. In order to exploit the vulnerabilities, the following requirements must be met - Run a version of Apache Commons Text from version 1.5 to 1.9 and use the StringSubstitutor interpolator. It is important to specify that the StringSubstitutor interpolator is not as widely used as the string substitution in Log4j, which led to Log4Shell. According to the CVSSv3 system, it scores 9.8 as CRITICAL severity. The severity is Critical due to the easy exploitability and huge potential impact in terms of confidentiality, integrity, and availability. As we showed in the previous section, you can take full control over the vulnerable system with a crafted request. However, it is not likely the vulnerabilities will have the same impacts as the previous Log4Shell and Spring4Shell.

[analytic_story://Trickbot]
category = Malware
last_updated = 2021-04-20
version = 1
references = ["https://en.wikipedia.org/wiki/Trickbot", "https://blog.checkpoint.com/2021/03/11/february-2021s-most-wanted-malware-trickbot-takes-over-following-emotet-shutdown/"]
maintainers = [{"company": "Teoderick Contreras, Splunk", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Account Discovery With Net App - Rule", "ESCU - Attempt To Stop Security Service - Rule", "ESCU - Cobalt Strike Named Pipes - Rule", "ESCU - Executable File Written in Administrative SMB Share - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Mshta spawning Rundll32 OR Regsvr32 Process - Rule", "ESCU - Office Application Spawn rundll32 process - Rule", "ESCU - Office Document Executing Macro Code - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Office Product Spawning CertUtil - Rule", "ESCU - Powershell Remote Thread To Known Windows Process - Rule", "ESCU - Schedule Task with Rundll32 Command Trigger - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Rundll32 StartW - Rule", "ESCU - Trickbot Named Pipe - Rule", "ESCU - Wermgr Process Connecting To IP Check Web Services - Rule", "ESCU - Wermgr Process Create Executable File - Rule", "ESCU - Wermgr Process Spawned CMD Or Powershell Process - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the trickbot banking trojan, including looking for file writes associated with its payload, process injection, shellcode execution and data collection even in LDAP environment.
narrative = trickbot banking trojan campaigns targeting banks and other vertical sectors.This malware is known in Microsoft Windows OS where target security Microsoft Defender to prevent its detection and removal. steal Verizon credentials and targeting banks using its multi component modules that collect and exfiltrate data.

[analytic_story://Trusted Developer Utilities Proxy Execution]
category = Adversary Tactics
last_updated = 2021-01-12
version = 1
references = ["https://attack.mitre.org/techniques/T1127/", "https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1218/T1218.md", "https://lolbas-project.github.io/lolbas/Binaries/Microsoft.Workflow.Compiler/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Suspicious microsoft workflow compiler rename - Rule", "ESCU - Suspicious microsoft workflow compiler usage - Rule"]
description = Monitor and detect behaviors used by attackers who leverage trusted developer utilities to execute malicious code.
narrative = Adversaries may take advantage of trusted developer utilities to proxy execution of malicious payloads. There are many utilities used for software development related tasks that can be used to execute code in various forms to assist in development, debugging, and reverse engineering. These utilities may often be signed with legitimate certificates that allow them to execute on a system and proxy execution of malicious code through a trusted process that effectively bypasses application control solutions.\
The searches in this story help you detect and investigate suspicious activity that may indicate that an adversary is leveraging microsoft.workflow.compiler.exe to execute malicious code.

[analytic_story://Trusted Developer Utilities Proxy Execution MSBuild]
category = Adversary Tactics
last_updated = 2021-01-21
version = 1
references = ["https://attack.mitre.org/techniques/T1127/001/", "https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1127.001/T1127.001.md", "https://github.com/infosecn1nja/MaliciousMacroMSBuild", "https://github.com/xorrior/RandomPS-Scripts/blob/master/Invoke-ExecuteMSBuild.ps1", "https://lolbas-project.github.io/lolbas/Binaries/Msbuild/", "https://github.com/MHaggis/CBR-Queries/blob/master/msbuild.md"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - MSBuild Suspicious Spawned By Script Process - Rule", "ESCU - Suspicious msbuild path - Rule", "ESCU - Suspicious MSBuild Rename - Rule", "ESCU - Suspicious MSBuild Spawn - Rule"]
description = Monitor and detect techniques used by attackers who leverage the msbuild.exe process to execute malicious code.
narrative = Adversaries may use MSBuild to proxy execution of code through a trusted Windows utility. MSBuild.exe (Microsoft Build Engine) is a software build platform used by Visual Studio and is native to Windows. It handles XML formatted project files that define requirements for loading and building various platforms and configurations.\
The inline task capability of MSBuild that was introduced in .NET version 4 allows for C# code to be inserted into an XML project file. MSBuild will compile and execute the inline task. MSBuild.exe is a signed Microsoft binary, so when it is used this way it can execute arbitrary code and bypass application control defenses that are configured to allow MSBuild.exe execution.\
The searches in this story help you detect and investigate suspicious activity that may indicate that an adversary is leveraging msbuild.exe to execute malicious code.\
Triage\
Validate execution\
1. Determine if MSBuild.exe executed. Validate the OriginalFileName of MSBuild.exe and further PE metadata.\
1. Determine if script code was executed with MSBuild.\
Situational Awareness\
The objective of this step is meant to identify suspicious behavioral indicators related to executed of Script code by MSBuild.exe.\
1. Parent process. Is the parent process a known LOLBin? Is the parent process an Office Application?\
1. Module loads. Are the known MSBuild.exe modules being loaded by a non-standard application? Is MSbuild loading any suspicious .DLLs?\
1. Network connections. Any network connections? Review the reputation of the remote IP or domain.\
Retrieval of script code\
The objective of this step is to confirm the executed script code is benign or malicious.

[analytic_story://Unusual Processes]
category = Malware
last_updated = 2020-02-04
version = 2
references = ["https://web.archive.org/web/20210921093439/https://www.fireeye.com/blog/threat-research/2017/08/monitoring-windows-console-activity-part-two.html", "https://www.splunk.com/pdfs/technical-briefs/advanced-threat-detection-and-response-tech-brief.pdf", "https://www.sans.org/reading-room/whitepapers/logging/detecting-security-incidents-windows-workstation-event-logs-34262"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Uncommon Processes On Endpoint - Rule", "ESCU - Attacker Tools On Endpoint - Rule", "ESCU - Detect processes used for System Network Configuration Discovery - Rule", "ESCU - Detect Rare Executables - Rule", "ESCU - Rundll32 Shimcache Flush - Rule", "ESCU - RunDLL Loading DLL By Ordinal - Rule", "ESCU - Suspicious Copy on System32 - Rule", "ESCU - Suspicious Process Executed From Container File - Rule", "ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Unusually Long Command Line - Rule", "ESCU - Unusually Long Command Line - MLTK - Rule", "ESCU - Verclsid CLSID Execution - Rule", "ESCU - Windows DotNet Binary in Non Standard Path - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule", "ESCU - Windows NirSoft AdvancedRun - Rule", "ESCU - Windows Registry Payload Injection - Rule", "ESCU - Windows Remote Assistance Spawning Process - Rule", "ESCU - WinRM Spawning a Process - Rule", "ESCU - Wscript Or Cscript Suspicious Child Process - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Quickly identify systems running new or unusual processes in your environment that could be indicators of suspicious activity. Processes run from unusual locations, those with conspicuously long command lines, and rare executables are all examples of activities that may warrant deeper investigation.
narrative = Being able to profile a host's processes within your environment can help you more quickly identify processes that seem out of place when compared to the rest of the population of hosts or asset types.\
This Analytic Story lets you identify processes that are either a) not typically seen running or b) have some sort of suspicious command-line arguments associated with them. This Analytic Story will also help you identify the user running these processes and the associated process activity on the host.\
In the event an unusual process is identified, it is imperative to better understand how that process was able to execute on the host, when it first executed, and whether other hosts are affected. This extra information may provide clues that can help the analyst further investigate any suspicious activity.

[analytic_story://Use of Cleartext Protocols]
category = Best Practices
last_updated = 2017-09-15
version = 1
references = ["https://www.monkey.org/~dugsong/dsniff/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Protocols passing authentication in cleartext - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Process Information For Port Activity - Response Task"]
description = Leverage searches that detect cleartext network protocols that may leak credentials or should otherwise be encrypted.
narrative = Various legacy protocols operate by default in the clear, without the protections of encryption. This potentially leaks sensitive information that can be exploited by passively sniffing network traffic. Depending on the protocol, this information could be highly sensitive, or could allow for session hijacking. In addition, these protocols send authentication information, which would allow for the harvesting of usernames and passwords that could potentially be used to authenticate and compromise secondary systems.

[analytic_story://VMware Aria Operations vRealize CVE-2023-20887]
category = Adversary Tactics
last_updated = 2023-06-21
version = 1
references = ["https://nvd.nist.gov/vuln/detail/CVE-2023-20887", "https://summoning.team/blog/vmware-vrealize-network-insight-rce-cve-2023-20887/", "https://viz.greynoise.io/tag/VMware-aria-operations-for-networks-rce-attempt?days=30", "https://github.com/sinsinology/CVE-2023-20887"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - VMWare Aria Operations Exploit Attempt - Rule"]
description = CVE-2023-20887 is a critical vulnerability affecting VMware's vRealize Network Insight (also known as VMware Aria Operations for Networks). It allows a remote, unauthenticated attacker to execute arbitrary commands with root privileges via the Apache Thrift RPC interface. The exploit, which has a severity score of 9.8, targets an endpoint ("/saas./resttosaasservlet") in the application and delivers a malicious payload designed to create a reverse shell, granting the attacker control over the system. VMware has released an advisory recommending users to update to the latest version to mitigate this threat.
narrative = CVE-2023-20887 is a highly critical vulnerability found in VMware's vRealize Network Insight. This software is widely used for intelligent operations management across physical, virtual, and cloud environments, so a vulnerability in it poses a significant risk to many organizations.\
This particular vulnerability lies in the application's Apache Thrift RPC interface. The exploit allows an attacker to inject commands that are executed with root privileges, leading to a potential total compromise of the system. The attacker does not need to be authenticated, which further increases the risk posed by this vulnerability.\
The exploit operates by sending a specially crafted payload to the "/saas./resttosaasservlet" endpoint. This payload contains a reverse shell command, which, when executed, allows the attacker to remotely control the victim's system. This control is obtained at the root level, providing the attacker with the ability to perform any action on the system.\
What makes this vulnerability particularly dangerous is its high severity score of 9.8, indicating it is a critical threat. It's also noteworthy that the exploitation of this vulnerability leaves specific indicators such as abnormal traffic to the "/saas./resttosaasservlet" endpoint and suspicious ncat commands in network traffic, which can help in its detection.\
VMware has acknowledged the vulnerability and has published a security advisory recommending that users update to the latest version of the software. This update effectively patches the vulnerability and protects systems from this exploit. It's crucial that all users of the affected versions of VMware's vRealize Network Insight promptly apply the update to mitigate the risk posed by CVE-2023-20887.

[analytic_story://VMware Server Side Injection and Privilege Escalation]
category = Adversary Tactics
last_updated = 2022-05-19
version = 1
references = ["https://attackerkb.com/topics/BDXyTqY1ld/cve-2022-22954/rapid7-analysis", "https://www.cisa.gov/uscert/ncas/alerts/aa22-138b"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - VMware Server Side Template Injection Hunt - Rule", "ESCU - VMware Workspace ONE Freemarker Server-side Template Injection - Rule"]
description = Recently disclosed CVE-2022-22954 and CVE-2022-22960 have been identified in the wild abusing VMware products to compromise internet faced devices and escalate privileges.
narrative = On April 6, 2022, VMware published VMSA-2022-0011, which discloses multiple vulnerabilities discovered by Steven Seeley (mr_me) of Qihoo 360 Vulnerability Research Institute. The most critical of the CVEs published in VMSA-2022-0011 is CVE-2022-22954, which is a server-side template injection issue with a CVSSv3 base score of 9.8. The vulnerability allows an unauthenticated user with network access to the web interface to execute an arbitrary shell command as the VMware user. To further exacerbate this issue, VMware also disclosed a local privilege escalation issue, CVE-2022-22960, which permits the attacker to gain root after exploiting CVE-2022-22954. Products affected include - VMware Workspace ONE Access (Access) 20.10.0.0 - 20.10.0.1, 21.08.0.0 - 21.08.0.1 and VMware Identity Manager (vIDM) 3.3.3 - 3.3.6.

[analytic_story://Volt Typhoon]
category = Data Destruction
last_updated = 2023-05-25
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Cmdline Tool Not Executed In CMD Shell - Rule", "ESCU - Creation of Shadow Copy - Rule", "ESCU - Creation of Shadow Copy with wmic and powershell - Rule", "ESCU - Detect PsExec With accepteula Flag - Rule", "ESCU - Dump LSASS via comsvcs DLL - Rule", "ESCU - Elevated Group Discovery With Net - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Extraction of Registry Hives - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Malicious PowerShell Process - Execution Policy Bypass - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Connection Discovery With Arp - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Ntdsutil Export NTDS - Rule", "ESCU - Processes launching netsh - Rule", "ESCU - Remote WMI Command Attempt - Rule", "ESCU - Suspicious Copy on System32 - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows DNS Gather Network Info - Rule", "ESCU - Windows Ldifde Directory Object Behavior - Rule", "ESCU - Windows Mimikatz Binary Execution - Rule", "ESCU - Windows Multiple Disabled Users Failed To Authenticate Wth Kerberos - Rule", "ESCU - Windows Multiple Invalid Users Fail To Authenticate Using Kerberos - Rule", "ESCU - Windows Multiple Invalid Users Failed To Authenticate Using NTLM - Rule", "ESCU - Windows Multiple Users Fail To Authenticate Wth ExplicitCredentials - Rule", "ESCU - Windows Multiple Users Failed To Authenticate From Host Using NTLM - Rule", "ESCU - Windows Multiple Users Failed To Authenticate From Process - Rule", "ESCU - Windows Multiple Users Failed To Authenticate Using Kerberos - Rule", "ESCU - Windows Multiple Users Remotely Failed To Authenticate From Host - Rule", "ESCU - Windows Proxy Via Netsh - Rule", "ESCU - Windows Proxy Via Registry - Rule", "ESCU - Windows Unusual Count Of Disabled Users Failed Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Invalid Users Fail To Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Invalid Users Failed To Auth Using NTLM - Rule", "ESCU - Windows Unusual Count Of Users Fail To Auth Wth ExplicitCredentials - Rule", "ESCU - Windows Unusual Count Of Users Failed To Auth Using Kerberos - Rule", "ESCU - Windows Unusual Count Of Users Failed To Authenticate From Process - Rule", "ESCU - Windows Unusual Count Of Users Failed To Authenticate Using NTLM - Rule", "ESCU - Windows Unusual Count Of Users Remotely Failed To Auth From Host - Rule", "ESCU - Windows WMI Process Call Create - Rule"]
description = This analytic story contains detections that allow security analysts to detect and investigate unusual activities that might relate to the "Volt Typhoon" group targeting critical infrastructure organizations in United States and Guam. The affected organizations include the communications, manufacturing, utility, transportation, construction, maritime, government, information technology, and education sectors. This Analytic story looks for suspicious process execution, lolbin execution, command-line activity, lsass dump and many more.
narrative = Volt Typhoon is a state sponsored group typically focuses on espionage and information gathering.\ Based on Microsoft Threat Intelligence, This threat actor group puts strong emphasis on stealth in this campaign by relying almost exclusively on living-off-the-land techniques and hands-on-keyboard activity. \ They issue commands via the command line to :\ (1) collect data, including credentials from local and network systems, \ (2) put the data into an archive file to stage it for exfiltration, and then \ (3) use the stolen valid credentials to maintain persistence. \ In addition, Volt Typhoon tries to blend into normal network activity by routing traffic through compromised small office and home office (SOHO) network equipment, including routers, firewalls, and VPN hardware. They have also been observed using custom versions of open-source tools to establish a command and control (C2) channel over proxy to further stay under the radar.

[analytic_story://Warzone RAT]
category = Malware
last_updated = 2023-07-26
version = 1
references = ["https://www.blackberry.com/us/en/solutions/endpoint-security/ransomware-protection/warzone#:~:text=Warzone%20RAT%20(AKA%20Ave%20Maria)%20is%20a%20remote%20access%20trojan,is%20as%20an%20information%20stealer.", "https://tccontre.blogspot.com/2020/02/2-birds-in-one-stone-ave-maria-wshrat.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Create Remote Thread In Shell Application - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Hide User Account From Sign-In Screen - Rule", "ESCU - Non Chrome Process Accessing Chrome Default Dir - Rule", "ESCU - Non Firefox Process Access Firefox Profile Dir - Rule", "ESCU - Office Application Drop Executable - Rule", "ESCU - Office Product Spawn CMD Process - Rule", "ESCU - Ping Sleep Batch Command - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Windows Bypass UAC via Pkgmgr Tool - Rule", "ESCU - Windows Credentials from Password Stores Chrome LocalState Access - Rule", "ESCU - Windows Credentials from Password Stores Chrome Login Data Access - Rule", "ESCU - Windows Defender Exclusion Registry Entry - Rule", "ESCU - Windows ISO LNK File Creation - Rule", "ESCU - Windows Mark Of The Web Bypass - Rule", "ESCU - Windows Modify Registry MaxConnectionPerServer - Rule", "ESCU - Windows Phishing Recent ISO Exec Registry - Rule", "ESCU - Windows Process Injection Remote Thread - Rule", "ESCU - Windows Unsigned DLL Side-Loading - Rule"]
description = This analytic story contains detections that allow security analysts to detect and investigate unusual activities that might related to warzone (Ave maria) RAT. This analytic story looks for suspicious process execution, command-line activity, downloads, persistence, defense evasion and more.
narrative = Warzone RAT, also known as Ave Maria, is a sophisticated remote access trojan (RAT) that surfaced in January 2019. Originally offered as malware-as-a-service (MaaS), it rapidly gained notoriety and became one of the most prominent malware strains by 2020. Its exceptional capabilities in stealth and anti-analysis techniques make it a formidable threat in various campaigns, including those targeting sensitive geopolitical entities. The malware's impact is particularly concerning as it has been associated with attacks aimed at compromising government employees and military personnel, notably within India's National Informatics Centre (NIC). Its deployment by several advanced persistent threat (APT) groups further underlines its potency and adaptability in the hands of skilled threat actors. Warzone RAT's capabilities enable attackers to gain unauthorized access to targeted systems, facilitating data theft, surveillance, and the potential to wreak havoc on critical infrastructures. As the threat landscape continues to evolve, vigilance and robust cybersecurity measures are crucial in defending against such malicious tools." This version provides more context and elaborates on the malware's capabilities and potential impact. Additionally, it emphasizes the importance of cybersecurity measures to combat such threats effectively.

[analytic_story://WhisperGate]
category = Data Destruction
last_updated = 2022-01-19
version = 1
references = ["https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/", "https://medium.com/s2wblog/analysis-of-destructive-malware-whispergate-targeting-ukraine-9d5d158f19f3"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Add or Set Windows Defender Exclusion - Rule", "ESCU - Attempt To Stop Security Service - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - Excessive File Deletion In WinDefender Folder - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Impacket Lateral Movement Commandline Parameters - Rule", "ESCU - Impacket Lateral Movement smbexec CommandLine Parameters - Rule", "ESCU - Impacket Lateral Movement WMIExec Commandline Parameters - Rule", "ESCU - Malicious PowerShell Process - Encoded Command - Rule", "ESCU - Ping Sleep Batch Command - Rule", "ESCU - Powershell Remove Windows Defender Directory - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Process Deleting Its Process File Path - Rule", "ESCU - Suspicious Process DNS Query Known Abuse Web Services - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - Suspicious Process With Discord DNS Query - Rule", "ESCU - Windows DotNet Binary in Non Standard Path - Rule", "ESCU - Windows High File Deletion Frequency - Rule", "ESCU - Windows InstallUtil in Non Standard Path - Rule", "ESCU - Windows NirSoft AdvancedRun - Rule", "ESCU - Windows NirSoft Utilities - Rule", "ESCU - Windows Raw Access To Master Boot Record Drive - Rule", "ESCU - Wscript Or Cscript Suspicious Child Process - Rule"]
description = This analytic story contains detections that allow security analysts to detect and investigate unusual activities that might relate to the destructive malware targeting Ukrainian organizations also known as "WhisperGate". This analytic story looks for suspicious process execution, command-line activity, downloads, DNS queries and more.
narrative = WhisperGate/DEV-0586 is destructive malware operation found by MSTIC (Microsoft Threat Inteligence Center) targeting multiple organizations in Ukraine. This operation campaign consist of several malware component like the downloader that abuses discord platform, overwrite or destroy master boot record (MBR) of the targeted host, wiper and also windows defender evasion techniques.

[analytic_story://Windows AppLocker]
category = Unauthorized Software
last_updated = 2024-03-21
version = 1
references = []
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows AppLocker Block Events - Rule", "ESCU - Windows AppLocker Execution from Uncommon Locations - Rule", "ESCU - Windows AppLocker Privilege Escalation via Unauthorized Bypass - Rule", "ESCU - Windows AppLocker Rare Application Launch Detection - Rule"]
description = Windows AppLocker is a feature that enhances security by allowing administrators to specify which users or groups can run particular applications in their organization based on unique identities of files. This story covers various aspects of monitoring and managing AppLocker policies, including detecting unauthorized software installations, enforcing best practices for software usage, and identifying potential security breaches through advanced threat detection techniques. Through the use of Splunk Enterprise, Splunk Enterprise Security, and Splunk Cloud, organizations can gain insights into AppLocker events, ensuring compliance with corporate security policies and mitigating risks associated with unauthorized applications.
narrative = AppLocker, a built-in Windows security feature, provides organizations with the ability to control application usage across their networks. It enables administrators to define rules based on file names, publishers, and file hashes to allow or deny the execution of applications. This level of control helps in preventing malware and unlicensed software from running, thereby enhancing the security posture of an organization. \
Organizations should leverage AppLocker for several reasons. Firstly, it aids in the enforcement of software compliance policies by ensuring that only licensed and approved applications are run on the network. Secondly, by restricting the execution of unauthorized applications, AppLocker significantly reduces the attack surface, making it harder for attackers to exploit vulnerabilities in unapproved software. Thirdly, AppLocker's ability to log attempts to run unauthorized applications provides valuable insights for security monitoring and incident response activities. This logging capability enables organizations to detect and respond to potential security threats in real time. \
In summary, AppLocker is a critical security tool that helps organizations manage application usage, enforce compliance policies, and mitigate security risks. By implementing AppLocker policies, organizations can achieve a robust security posture, protecting their assets from unauthorized software and potential cyber threats.

[analytic_story://Windows Attack Surface Reduction]
category = Best Practices
last_updated = 2023-11-27
version = 1
references = ["https://asrgen.streamlit.app/", "https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction?view=o365-worldwide"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows Defender ASR Audit Events - Rule", "ESCU - Windows Defender ASR Block Events - Rule", "ESCU - Windows Defender ASR Registry Modification - Rule", "ESCU - Windows Defender ASR Rule Disabled - Rule", "ESCU - Windows Defender ASR Rules Stacking - Rule"]
description = This story contains detections for Windows Attack Surface Reduction (ASR) events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This story contains detections for ASR events that are generated when a process or application attempts to perform an action that is blocked by an ASR rule.
narrative = This story contains detections for Windows Attack Surface Reduction (ASR) events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This story contains detections for ASR events that are generated when a process or application attempts to perform an action that is blocked by an ASR rule. It includes detections for both block and audit event IDs. Block event IDs are generated when an action is blocked by an ASR rule, while audit event IDs are generated when an action that would be blocked by an ASR rule is allowed to proceed for auditing purposes.

[analytic_story://Windows BootKits]
category = Adversary Tactics
last_updated = 2023-05-03
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2023/04/11/guidance-for-investigating-attacks-using-cve-2022-21894-the-blacklotus-campaign/", "https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows BootLoader Inventory - Rule", "ESCU - Windows Registry BootExecute Modification - Rule"]
description = Adversaries may use bootkits to persist on systems. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
narrative = A bootkit is a sophisticated type of malware that targets the boot sectors of a hard drive, specifically the Master Boot Record (MBR) and Volume Boot Record (VBR). The MBR is the initial section of the disk that is loaded following the hardware initialization process executed by the Basic Input/Output System (BIOS). It houses the boot loader, which is responsible for loading the operating system. In contrast, the VBR is located at the beginning of each partition and contains the boot code for that specific partition. When an adversary gains raw access to the boot drive, they can overwrite the MBR or VBR, effectively diverting the execution during startup from the standard boot loader to the malicious code injected by the attacker. This tampering allows the malware to load before the operating system, enabling it to execute malicious activities stealthily and maintain persistence on the compromised system. Bootkits are particularly dangerous because they can bypass security measures implemented by the operating system and antivirus software. Since they load before the operating system, they can easily evade detection and manipulate the system's behavior from the earliest stages of the boot process. This capability makes bootkits a potent tool in an attacker's arsenal for gaining unauthorized access, stealing sensitive information, or launching further attacks on other systems. To defend against bootkit attacks, organizations should implement multiple layers of security, including strong endpoint protection, regular software updates, user awareness training, and monitoring for unusual system behavior. Additionally, hardware-based security features, such as Unified Extensible Firmware Interface (UEFI) Secure Boot and Trusted Platform Module (TPM), can help protect the integrity of the boot process and reduce the risk of bootkit infections.

[analytic_story://Windows Certificate Services]
category = Adversary Tactics
last_updated = 2023-02-01
version = 1
references = ["https://attack.mitre.org/techniques/T1649/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Certutil exe certificate extraction - Rule", "ESCU - Detect Certify Command Line Arguments - Rule", "ESCU - Detect Certify With PowerShell Script Block Logging - Rule", "ESCU - Detect Certipy File Modifications - Rule", "ESCU - Steal or Forge Authentication Certificates Behavior Identified - Rule", "ESCU - Windows Export Certificate - Rule", "ESCU - Windows Mimikatz Crypto Export File Extensions - Rule", "ESCU - Windows PowerShell Export Certificate - Rule", "ESCU - Windows PowerShell Export PfxCertificate - Rule", "ESCU - Windows Steal Authentication Certificates - ESC1 Abuse - Rule", "ESCU - Windows Steal Authentication Certificates - ESC1 Authentication - Rule", "ESCU - Windows Steal Authentication Certificates Certificate Issued - Rule", "ESCU - Windows Steal Authentication Certificates Certificate Request - Rule", "ESCU - Windows Steal Authentication Certificates CertUtil Backup - Rule", "ESCU - Windows Steal Authentication Certificates CryptoAPI - Rule", "ESCU - Windows Steal Authentication Certificates CS Backup - Rule", "ESCU - Windows Steal Authentication Certificates Export Certificate - Rule", "ESCU - Windows Steal Authentication Certificates Export PfxCertificate - Rule"]
description = Adversaries may steal or forge certificates used for authentication to access remote systems or resources. Digital certificates are often used to sign and encrypt messages and/or files. Certificates are also used as authentication material.
narrative = The following analytic story focuses on remote and local endpoint certificate theft and abuse. Authentication certificates can be both stolen and forged. For example, AD CS certificates can be stolen from encrypted storage (in the Registry or files), misplaced certificate files (i.e. Unsecured Credentials), or directly from the Windows certificate store via various crypto APIs.With appropriate enrollment rights, users and/or machines within a domain can also request and/or manually renew certificates from enterprise certificate authorities (CA). This enrollment process defines various settings and permissions associated with the certificate. Abusing certificates for authentication credentials may enable other behaviors such as Lateral Movement. Certificate-related misconfigurations may also enable opportunities for Privilege Escalation, by way of allowing users to impersonate or assume privileged accounts or permissions via the identities (SANs) associated with a certificate. These abuses may also enable Persistence via stealing or forging certificates that can be used as Valid Accounts for the duration of the certificate's validity, despite user password resets. Authentication certificates can also be stolen and forged for machine accounts. (MITRE ATT&CK)

[analytic_story://Windows Defense Evasion Tactics]
category = Adversary Tactics
last_updated = 2018-05-31
version = 1
references = ["https://attack.mitre.org/wiki/Defense_Evasion"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Reg exe used to hide files directories via registry keys - Rule", "ESCU - Remote Registry Key modifications - Rule", "ESCU - Add or Set Windows Defender Exclusion - Rule", "ESCU - CSC Net On The Fly Compilation - Rule", "ESCU - Disable Registry Tool - Rule", "ESCU - Disable Security Logs Using MiniNt Registry - Rule", "ESCU - Disable Show Hidden Files - Rule", "ESCU - Disable UAC Remote Restriction - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Disable Windows SmartScreen Protection - Rule", "ESCU - Disabling CMD Application - Rule", "ESCU - Disabling ControlPanel - Rule", "ESCU - Disabling Firewall with Netsh - Rule", "ESCU - Disabling FolderOptions Windows Feature - Rule", "ESCU - Disabling NoRun Windows App - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Disabling SystemRestore In Registry - Rule", "ESCU - Disabling Task Manager - Rule", "ESCU - Disabling Windows Local Security Authority Defences via Registry - Rule", "ESCU - Eventvwr UAC Bypass - Rule", "ESCU - Excessive number of service control start as disabled - Rule", "ESCU - Firewall Allowed Program Enable - Rule", "ESCU - FodHelper UAC Bypass - Rule", "ESCU - Hiding Files And Directories With Attrib exe - Rule", "ESCU - NET Profiler UAC bypass - Rule", "ESCU - Powershell Windows Defender Exclusion Commands - Rule", "ESCU - Sdclt UAC Bypass - Rule", "ESCU - SilentCleanup UAC Bypass - Rule", "ESCU - SLUI RunAs Elevated - Rule", "ESCU - SLUI Spawning a Process - Rule", "ESCU - Suspicious Reg exe Process - Rule", "ESCU - UAC Bypass MMC Load Unsigned Dll - Rule", "ESCU - Windows Alternate DataStream - Base64 Content - Rule", "ESCU - Windows Alternate DataStream - Executable Content - Rule", "ESCU - Windows Alternate DataStream - Process Execution - Rule", "ESCU - Windows Command and Scripting Interpreter Hunting Path Traversal - Rule", "ESCU - Windows Command and Scripting Interpreter Path Traversal Exec - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows Defender Exclusion Registry Entry - Rule", "ESCU - Windows Disable Change Password Through Registry - Rule", "ESCU - Windows Disable Lock Workstation Feature Through Registry - Rule", "ESCU - Windows Disable Notification Center - Rule", "ESCU - Windows Disable Windows Event Logging Disable HTTP Logging - Rule", "ESCU - Windows Disable Windows Group Policy Features Through Registry - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows DISM Remove Defender - Rule", "ESCU - Windows DLL Search Order Hijacking Hunt - Rule", "ESCU - Windows DLL Search Order Hijacking Hunt with Sysmon - Rule", "ESCU - Windows DLL Search Order Hijacking with iscsicpl - Rule", "ESCU - Windows Event For Service Disabled - Rule", "ESCU - Windows Excessive Disabled Services Event - Rule", "ESCU - Windows Hide Notification Features Through Registry - Rule", "ESCU - Windows Impair Defense Change Win Defender Health Check Intervals - Rule", "ESCU - Windows Impair Defense Change Win Defender Quick Scan Interval - Rule", "ESCU - Windows Impair Defense Change Win Defender Throttle Rate - Rule", "ESCU - Windows Impair Defense Change Win Defender Tracing Level - Rule", "ESCU - Windows Impair Defense Configure App Install Control - Rule", "ESCU - Windows Impair Defense Define Win Defender Threat Action - Rule", "ESCU - Windows Impair Defense Delete Win Defender Context Menu - Rule", "ESCU - Windows Impair Defense Delete Win Defender Profile Registry - Rule", "ESCU - Windows Impair Defense Disable Controlled Folder Access - Rule", "ESCU - Windows Impair Defense Disable Defender Firewall And Network - Rule", "ESCU - Windows Impair Defense Disable Defender Protocol Recognition - Rule", "ESCU - Windows Impair Defense Disable PUA Protection - Rule", "ESCU - Windows Impair Defense Disable Realtime Signature Delivery - Rule", "ESCU - Windows Impair Defense Disable Web Evaluation - Rule", "ESCU - Windows Impair Defense Disable Win Defender App Guard - Rule", "ESCU - Windows Impair Defense Disable Win Defender Compute File Hashes - Rule", "ESCU - Windows Impair Defense Disable Win Defender Gen reports - Rule", "ESCU - Windows Impair Defense Disable Win Defender Network Protection - Rule", "ESCU - Windows Impair Defense Disable Win Defender Report Infection - Rule", "ESCU - Windows Impair Defense Disable Win Defender Scan On Update - Rule", "ESCU - Windows Impair Defense Disable Win Defender Signature Retirement - Rule", "ESCU - Windows Impair Defense Overide Win Defender Phishing Filter - Rule", "ESCU - Windows Impair Defense Override SmartScreen Prompt - Rule", "ESCU - Windows Impair Defense Set Win Defender Smart Screen Level To Warn - Rule", "ESCU - Windows Impair Defenses Disable HVCI - Rule", "ESCU - Windows Impair Defenses Disable Win Defender Auto Logging - Rule", "ESCU - Windows Known Abused DLL Created - Rule", "ESCU - Windows Modify Show Compress Color And Info Tip Registry - Rule", "ESCU - Windows Parent PID Spoofing with Explorer - Rule", "ESCU - Windows PowerShell Disable HTTP Logging - Rule", "ESCU - Windows Process With NamedPipe CommandLine - Rule", "ESCU - Windows Rasautou DLL Execution - Rule", "ESCU - Windows UAC Bypass Suspicious Child Process - Rule", "ESCU - Windows UAC Bypass Suspicious Escalation Behavior - Rule", "ESCU - WSReset UAC Bypass - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Detect tactics used by malware to evade defenses on Windows endpoints. A few of these include suspicious `reg.exe` processes, files hidden with `attrib.exe` and disabling user-account control, among many others 
narrative = Defense evasion is a tactic--identified in the MITRE ATT&CK framework--that adversaries employ in a variety of ways to bypass or defeat defensive security measures. There are many techniques enumerated by the MITRE ATT&CK framework that are applicable in this context. This Analytic Story includes searches designed to identify the use of such techniques on Windows platforms.

[analytic_story://Windows Discovery Techniques]
category = Adversary Tactics
last_updated = 2021-03-04
version = 1
references = ["https://attack.mitre.org/tactics/TA0007/", "https://cyberd.us/penetration-testing", "https://attack.mitre.org/software/S0521/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Hart"}]
spec_version = 3
searches = ["ESCU - Detect AzureHound Command-Line Arguments - Rule", "ESCU - Detect AzureHound File Modifications - Rule", "ESCU - Detect SharpHound Command-Line Arguments - Rule", "ESCU - Detect SharpHound File Modifications - Rule", "ESCU - Detect SharpHound Usage - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Traffic to Active Directory Web Services Protocol - Rule", "ESCU - System Information Discovery Detection - Rule", "ESCU - Windows SOAPHound Binary Execution - Rule"]
description = Monitors for behaviors associated with adversaries discovering objects in the environment that can be leveraged in the progression of the attack.
narrative = Attackers may not have much if any insight into their target's environment before the initial compromise.  Once a foothold has been established, attackers will start enumerating objects in the environment (accounts, services, network shares, etc.) that can be used to achieve their objectives.  This Analytic Story provides searches to help identify activities consistent with adversaries gaining knowledge of compromised Windows environments.

[analytic_story://Windows DNS SIGRed CVE-2020-1350]
category = Adversary Tactics
last_updated = 2020-07-28
version = 1
references = ["https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/", "https://support.microsoft.com/en-au/help/4569509/windows-dns-server-remote-code-execution-vulnerability"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Shannon Davis"}]
spec_version = 3
searches = ["ESCU - Detect Windows DNS SIGRed via Splunk Stream - Rule", "ESCU - Detect Windows DNS SIGRed via Zeek - Rule", "ESCU - Get Notable History - Response Task"]
description = Uncover activity consistent with CVE-2020-1350, or SIGRed. Discovered by Checkpoint researchers, this vulnerability affects Windows 2003 to 2019, and is triggered by a malicious DNS response (only affects DNS over TCP). An attacker can use the malicious payload to cause a buffer overflow on the vulnerable system, leading to compromise.  The included searches in this Analytic Story are designed to identify the large response payload for SIG and KEY DNS records which can be used for the exploit.
narrative = When a client requests a DNS record for a particular domain, that request gets routed first through the client's locally configured DNS server, then to any DNS server(s) configured as forwarders, and then onto the target domain's own DNS server(s).  If a attacker wanted to, they could host a malicious DNS server that responds to the initial request with a specially crafted large response (~65KB).  This response would flow through to the client's local DNS server, which if not patched for CVE-2020-1350, would cause the buffer overflow. The detection searches in this Analytic Story use wire data to detect the malicious behavior. Searches for Splunk Stream and Zeek are included.  The Splunk Stream search correlates across stream:dns and stream:tcp, while the Zeek search correlates across bro:dns:json and bro:conn:json.  These correlations are required to pick up both the DNS record types (SIG and KEY) along with the payload size (>65KB).

[analytic_story://Windows Drivers]
category = Adversary Tactics
last_updated = 2022-03-30
version = 1
references = ["https://redcanary.com/blog/tracking-driver-inventory-to-expose-rootkits/", "https://www.trendmicro.com/en_us/research/22/e/avoslocker-ransomware-variant-abuses-driver-file-to-disable-anti-Virus-scans-log4shell.html", "https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/daxin-backdoor-espionage", "https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/08064459/Equation_group_questions_and_answers.pdf", "https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Windows Driver Inventory - Rule", "ESCU - Windows Driver Load Non-Standard Path - Rule", "ESCU - Windows Drivers Loaded by Signature - Rule", "ESCU - Windows Registry Certificate Added - Rule", "ESCU - Windows Registry Modification for Safe Mode Persistence - Rule", "ESCU - Windows Service Create Kernel Mode Driver - Rule", "ESCU - Windows System File on Disk - Rule", "ESCU - Windows Vulnerable Driver Loaded - Rule"]
description = Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components.
narrative = A rootkit on Windows may sometimes be in the form of a Windows Driver. A driver typically has a file extension of .sys, however the internals of a sys file is similar to a Windows DLL. For Microsoft Windows to load a driver, a few requirements are needed. First, it must have a valid signature. Second, typically it should load from the windows\system32\drivers path. There are a few methods to investigate drivers in the environment. Drivers are noisy. An inventory of all drivers is important to understand prevalence. A driver location (Path) is also important when attempting to baseline. Looking at a driver name and path is not enough, we must also explore the signing information. Product, description, company name, signer and signing result are all items to take into account when reviewing drivers. What makes a driver malicious? Depending if a driver was dropped during a campaign or you are baselining drivers after, triaging a driver to determine maliciousness may be tough. We break this into two categories - 1. vulnerable drivers 2. driver rootkits. Attempt to identify prevelance of the driver. Is it on one or many? Review the signing information if it is present. Is it common? A lot of driver hunting will lead down rabbit holes, but we hope to help lead the way.

[analytic_story://Windows Error Reporting Service Elevation of Privilege Vulnerability]
category = Adversary Tactics
last_updated = 2023-08-24
version = 1
references = ["https://www.crowdstrike.com/blog/falcon-complete-zero-day-exploit-cve-2023-36874/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - System Processes Run From Unexpected Locations - Rule", "ESCU - Windows Process Injection Wermgr Child Process - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule"]
description = In July 2023, CrowdStrike's Falcon Complete managed detection and response (MDR) team uncovered an exploit kit using an unknown vulnerability in the Windows Error Reporting (WER) component. The vulnerability, now identified as CVE-2023-36874, was also independently discovered by Google's Threat Analysis Group. The exploit came to light when suspicious binaries were observed on a European technology system. CrowdStrike's Counter Adversary Operations' analysis revealed a zero-day exploit targeting the WER service, allowing attackers to execute unauthorized code with elevated privileges. The exploit kit seen aimed to spawn a privileged interpreter, displaying the versatility and adaptability of the threat. CrowdStrike has listed some potential indicators of compromise, but these are of low fidelity due to their mutable nature.
narrative = In June 2023, CrowdStrike's Falcon Complete team observed suspicious activities on a European technology entity's system. Multiple binaries were dropped onto the system via Remote Desktop Protocol (RDP), some of which were flagged as potential exploits for a known vulnerability. However, a string containing the Russian term for "0day" suggested an unknown vulnerability was at play. Subsequent investigations identified this as a zero-day vulnerability affecting the Windows Error Reporting (WER) component, now known as CVE-2023-36874. \
The WER service's function is to report software issues on Windows hosts. The exploit centered around manipulating the WER service by redirecting file systems to execute attacker-controlled code with elevated privileges. This was achieved by creating a symbolic link redirection from the C:\ drive to an attacker-controlled directory, and then triggering certain WER functions. Consequently, an unauthorized executable was run instead of the legitimate one, giving the attacker high-level access. \
The observed exploit kit's primary objective was to initiate a privileged interpreter, such as cmd.exe or powershell_ise.exe. If this couldn't be achieved, a privileged scheduled task was created as an alternative. The exploit kit showcased a range of binaries, some packed and others not, some in C++ and others in pure C. This diversity suggests the knowledge of the vulnerability was likely shared among different developers. \
CrowdStrike's Counter Adversary Operations, as of now, hasn't linked this activity to any specific threat actor. They've provided potential indicators of compromise, but caution that these are easily changed, indicating the advanced capabilities of the adversaries.

[analytic_story://Windows File Extension and Association Abuse]
category = Malware
last_updated = 2018-01-26
version = 1
references = ["https://blog.malwarebytes.com/cybercrime/2013/12/file-extensions-2/", "https://attack.mitre.org/wiki/Technique/T1042"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Execution of File With Spaces Before Extension - Rule", "ESCU - Suspicious Changes to File Associations - Rule", "ESCU - Execution of File with Multiple Extensions - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Detect and investigate suspected abuse of file extensions and Windows file associations. Some of the malicious behaviors involved may include inserting spaces before file extensions or prepending the file extension with a different one, among other techniques.
narrative = Attackers use a variety of techniques to entice users to run malicious code or to persist on an endpoint. One way to accomplish these goals is to leverage file extensions and the mechanism Windows uses to associate files with specific applications. \
 Since its earliest days, Windows has used extensions to identify file types. Users have become familiar with these extensions and their application associations. For example, if users see that a file ends in `.doc` or `.docx`, they will assume that it is a Microsoft Word document and expect that double-clicking will open it using `winword.exe`. The user will typically also presume that the `.docx` file is safe. \
 Attackers take advantage of this expectation by obfuscating the true file extension. They can accomplish this in a couple of ways. One technique involves inserting multiple spaces in the file name before the extension to hide the extension from the GUI, obscuring the true nature of the file. Another approach involves prepending the real extension with a different one. This is especially effective when Windows is configured to "hide extensions for known file types." In this case, the real extension is not displayed, but the prepended one is, leading end users to believe the file is a different type than it actually is.\
Changing the association between a file extension and an application can allow an attacker to execute arbitrary code. The technique typically involves changing the association for an often-launched file type to associate instead with a malicious program the attacker has dropped on the endpoint. When the end user launches a file that has been manipulated in this way, it will execute the attacker's malware. It will also execute the application the end user expected to run, cleverly obscuring the fact that something suspicious has occurred.\
Run the searches in this story to detect and investigate suspicious behavior that may indicate abuse or manipulation of Windows file extensions and/or associations.

[analytic_story://Windows Log Manipulation]
category = Adversary Tactics
last_updated = 2017-09-12
version = 2
references = ["https://www.crowdstrike.com/blog/bears-midst-intrusion-democratic-national-committee/", "https://zeltser.com/security-incident-log-review-checklist/", "http://journeyintoir.blogspot.com/2013/01/re-introducing-usnjrnl.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - Deleting Shadow Copies - Rule", "ESCU - Suspicious Event Log Service Behavior - Rule", "ESCU - Suspicious wevtutil Usage - Rule", "ESCU - USN Journal Deletion - Rule", "ESCU - Windows Event Log Cleared - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Adversaries often try to cover their tracks by manipulating Windows logs. Use these searches to help you monitor for suspicious activity surrounding log files--an essential component of an effective defense.
narrative = Because attackers often modify system logs to cover their tracks and/or to thwart the investigative process, log monitoring is an industry-recognized best practice. While there are legitimate reasons to manipulate system logs, it is still worthwhile to keep track of who manipulated the logs, when they manipulated them, and in what way they manipulated them (determining which accesses, tools, or utilities were employed). Even if no malicious activity is detected, the knowledge of an attempt to manipulate system logs may be indicative of a broader security risk that should be thoroughly investigated.\
The Analytic Story gives users two different ways to detect manipulation of Windows Event Logs and one way to detect deletion of the Update Sequence Number (USN) Change Journal. The story helps determine the history of the host and the users who have accessed it. Finally, the story aides in investigation by retrieving all the information on the process that caused these events (if the process has been identified).

[analytic_story://Windows Persistence Techniques]
category = Adversary Tactics
last_updated = 2018-05-31
version = 2
references = ["http://www.fuzzysecurity.com/tutorials/19.html", "https://www.fireeye.com/blog/threat-research/2010/07/malware-persistence-windows-registry.html", "http://resources.infosecinstitute.com/common-malware-persistence-mechanisms/", "https://www.fireeye.com/blog/threat-research/2017/05/fin7-shim-databases-persistence.html", "https://www.youtube.com/watch?v=dq2Hv7J9fvk"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Bhavin Patel"}]
spec_version = 3
searches = ["ESCU - Reg exe used to hide files directories via registry keys - Rule", "ESCU - Remote Registry Key modifications - Rule", "ESCU - Active Setup Registry Autostart - Rule", "ESCU - Certutil exe certificate extraction - Rule", "ESCU - Change Default File Association - Rule", "ESCU - Detect Path Interception By Creation Of program exe - Rule", "ESCU - ETW Registry Disabled - Rule", "ESCU - Hiding Files And Directories With Attrib exe - Rule", "ESCU - Logon Script Event Trigger Execution - Rule", "ESCU - Monitor Registry Keys for Print Monitors - Rule", "ESCU - Print Processor Registry Autostart - Rule", "ESCU - Reg exe Manipulating Windows Services Registry Keys - Rule", "ESCU - Registry Keys for Creating SHIM Databases - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Schedule Task with HTTP Command Arguments - Rule", "ESCU - Schedule Task with Rundll32 Command Trigger - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - Schtasks used for forcing a reboot - Rule", "ESCU - Screensaver Event Trigger Execution - Rule", "ESCU - Shim Database File Creation - Rule", "ESCU - Shim Database Installation With Suspicious Parameters - Rule", "ESCU - Suspicious Scheduled Task from Public Directory - Rule", "ESCU - Time Provider Persistence Registry - Rule", "ESCU - Windows AD DSRM Account Changes - Rule", "ESCU - Windows AD Same Domain SID History Addition - Rule", "ESCU - Windows Event Triggered Image File Execution Options Injection - Rule", "ESCU - Windows Mshta Execution In Registry - Rule", "ESCU - Windows Registry Delete Task SD - Rule", "ESCU - Windows Scheduled Task Service Spawned Shell - Rule", "ESCU - Windows Schtasks Create Run As System - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Monitor for activities and techniques associated with maintaining persistence on a Windows system--a sign that an adversary may have compromised your environment.
narrative = Maintaining persistence is one of the first steps taken by attackers after the initial compromise. Attackers leverage various custom and built-in tools to ensure survivability and persistent access within a compromised enterprise. This Analytic Story provides searches to help you identify various behaviors used by attackers to maintain persistent access to a Windows environment.

[analytic_story://Windows Post-Exploitation]
category = Adversary Tactics
last_updated = 2022-11-30
version = 1
references = ["https://www.microsoft.com/en-us/security/blog/2022/10/14/new-prestige-ransomware-impacts-organizations-in-ukraine-and-poland/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Create or delete windows shares using net exe - Rule", "ESCU - Domain Group Discovery With Net - Rule", "ESCU - Excessive Usage Of Cacls App - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Net Localgroup Discovery - Rule", "ESCU - Network Connection Discovery With Arp - Rule", "ESCU - Network Connection Discovery With Net - Rule", "ESCU - Network Connection Discovery With Netstat - Rule", "ESCU - Network Discovery Using Route Windows App - Rule", "ESCU - Recon AVProduct Through Pwh or WMI - Rule", "ESCU - Windows Cached Domain Credentials Reg Query - Rule", "ESCU - Windows ClipBoard Data via Get-ClipBoard - Rule", "ESCU - Windows Common Abused Cmd Shell Risk Behavior - Rule", "ESCU - Windows Credentials from Password Stores Query - Rule", "ESCU - Windows Credentials in Registry Reg Query - Rule", "ESCU - Windows Indirect Command Execution Via forfiles - Rule", "ESCU - Windows Indirect Command Execution Via Series Of Forfiles - Rule", "ESCU - Windows Information Discovery Fsutil - Rule", "ESCU - Windows Modify Registry Reg Restore - Rule", "ESCU - Windows Password Managers Discovery - Rule", "ESCU - Windows Post Exploitation Risk Behavior - Rule", "ESCU - Windows Private Keys Discovery - Rule", "ESCU - Windows Query Registry Reg Save - Rule", "ESCU - Windows Security Support Provider Reg Query - Rule", "ESCU - Windows Steal or Forge Kerberos Tickets Klist - Rule", "ESCU - Windows System Network Config Discovery Display DNS - Rule", "ESCU - Windows System Network Connections Discovery Netsh - Rule", "ESCU - Windows System User Discovery Via Quser - Rule", "ESCU - Windows WMI Process And Service List - Rule"]
description = This analytic story identifies popular Windows post exploitation tools for example winpeas.bat, winpeas.exe, WinPrivCheck.bat and many more.
narrative = These tools allow operators to find possible exploits or paths for privilege escalation and persistence on a targeted host. Ransomware operator like the "Prestige ransomware" also used or abuses these post exploitation tools such as winPEAS to scan for possible avenue to gain privileges and persistence to a targeted Windows Operating System.

[analytic_story://Windows Privilege Escalation]
category = Adversary Tactics
last_updated = 2020-02-04
version = 2
references = ["https://attack.mitre.org/tactics/TA0004/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "David Dorsey"}]
spec_version = 3
searches = ["ESCU - Uncommon Processes On Endpoint - Rule", "ESCU - Active Setup Registry Autostart - Rule", "ESCU - Change Default File Association - Rule", "ESCU - Child Processes of Spoolsv exe - Rule", "ESCU - ETW Registry Disabled - Rule", "ESCU - Kerberoasting spn request with RC4 encryption - Rule", "ESCU - Logon Script Event Trigger Execution - Rule", "ESCU - MSI Module Loaded by Non-System Binary - Rule", "ESCU - Overwriting Accessibility Binaries - Rule", "ESCU - Print Processor Registry Autostart - Rule", "ESCU - Registry Keys Used For Privilege Escalation - Rule", "ESCU - Runas Execution in CommandLine - Rule", "ESCU - Screensaver Event Trigger Execution - Rule", "ESCU - Time Provider Persistence Registry - Rule", "ESCU - Windows Privilege Escalation Suspicious Process Elevation - Rule", "ESCU - Windows Privilege Escalation System Process Without System Parent - Rule", "ESCU - Windows Privilege Escalation User Process Spawn System Process - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Monitor for and investigate activities that may be associated with a Windows privilege-escalation attack, including unusual processes running on endpoints, modified registry keys, and more.
narrative = Privilege escalation is a "land-and-expand" technique, wherein an adversary gains an initial foothold on a host and then exploits its weaknesses to increase his privileges. The motivation is simple: certain actions on a Windows machine--such as installing software--may require higher-level privileges than those the attacker initially acquired. By increasing his privilege level, the attacker can gain the control required to carry out his malicious ends. This Analytic Story provides searches to detect and investigate behaviors that attackers may use to elevate their privileges in your environment.

[analytic_story://Windows Registry Abuse]
category = Malware
last_updated = 2022-03-17
version = 1
references = ["https://attack.mitre.org/techniques/T1112/", "https://redcanary.com/blog/windows-registry-attacks-threat-detection/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Allow Inbound Traffic By Firewall Rule Registry - Rule", "ESCU - Allow Operation with Consent Admin - Rule", "ESCU - Attempted Credential Dump From Registry via Reg exe - Rule", "ESCU - Auto Admin Logon Registry Entry - Rule", "ESCU - Change Default File Association - Rule", "ESCU - Disable AMSI Through Registry - Rule", "ESCU - Disable Defender AntiVirus Registry - Rule", "ESCU - Disable Defender BlockAtFirstSeen Feature - Rule", "ESCU - Disable Defender Enhanced Notification - Rule", "ESCU - Disable Defender MpEngine Registry - Rule", "ESCU - Disable Defender Spynet Reporting - Rule", "ESCU - Disable Defender Submit Samples Consent Feature - Rule", "ESCU - Disable ETW Through Registry - Rule", "ESCU - Disable Registry Tool - Rule", "ESCU - Disable Security Logs Using MiniNt Registry - Rule", "ESCU - Disable Show Hidden Files - Rule", "ESCU - Disable UAC Remote Restriction - Rule", "ESCU - Disable Windows App Hotkeys - Rule", "ESCU - Disable Windows Behavior Monitoring - Rule", "ESCU - Disable Windows SmartScreen Protection - Rule", "ESCU - Disabling CMD Application - Rule", "ESCU - Disabling ControlPanel - Rule", "ESCU - Disabling Defender Services - Rule", "ESCU - Disabling FolderOptions Windows Feature - Rule", "ESCU - Disabling NoRun Windows App - Rule", "ESCU - Disabling Remote User Account Control - Rule", "ESCU - Disabling SystemRestore In Registry - Rule", "ESCU - Disabling Task Manager - Rule", "ESCU - Disabling Windows Local Security Authority Defences via Registry - Rule", "ESCU - Enable RDP In Other Port Number - Rule", "ESCU - Enable WDigest UseLogonCredential Registry - Rule", "ESCU - ETW Registry Disabled - Rule", "ESCU - Eventvwr UAC Bypass - Rule", "ESCU - Hide User Account From Sign-In Screen - Rule", "ESCU - Modification Of Wallpaper - Rule", "ESCU - Monitor Registry Keys for Print Monitors - Rule", "ESCU - Registry Keys for Creating SHIM Databases - Rule", "ESCU - Registry Keys Used For Persistence - Rule", "ESCU - Registry Keys Used For Privilege Escalation - Rule", "ESCU - Remcos client registry install entry - Rule", "ESCU - Revil Registry Entry - Rule", "ESCU - Screensaver Event Trigger Execution - Rule", "ESCU - Sdclt UAC Bypass - Rule", "ESCU - SilentCleanup UAC Bypass - Rule", "ESCU - Time Provider Persistence Registry - Rule", "ESCU - Windows AD DSRM Account Changes - Rule", "ESCU - Windows Autostart Execution LSASS Driver Registry Modification - Rule", "ESCU - Windows Disable Lock Workstation Feature Through Registry - Rule", "ESCU - Windows Disable LogOff Button Through Registry - Rule", "ESCU - Windows Disable Memory Crash Dump - Rule", "ESCU - Windows Disable Notification Center - Rule", "ESCU - Windows Disable Shutdown Button Through Registry - Rule", "ESCU - Windows Disable Windows Group Policy Features Through Registry - Rule", "ESCU - Windows DisableAntiSpyware Registry - Rule", "ESCU - Windows Hide Notification Features Through Registry - Rule", "ESCU - Windows Impair Defense Change Win Defender Health Check Intervals - Rule", "ESCU - Windows Impair Defense Change Win Defender Quick Scan Interval - Rule", "ESCU - Windows Impair Defense Change Win Defender Throttle Rate - Rule", "ESCU - Windows Impair Defense Change Win Defender Tracing Level - Rule", "ESCU - Windows Impair Defense Configure App Install Control - Rule", "ESCU - Windows Impair Defense Define Win Defender Threat Action - Rule", "ESCU - Windows Impair Defense Delete Win Defender Context Menu - Rule", "ESCU - Windows Impair Defense Delete Win Defender Profile Registry - Rule", "ESCU - Windows Impair Defense Disable Controlled Folder Access - Rule", "ESCU - Windows Impair Defense Disable Defender Firewall And Network - Rule", "ESCU - Windows Impair Defense Disable Defender Protocol Recognition - Rule", "ESCU - Windows Impair Defense Disable PUA Protection - Rule", "ESCU - Windows Impair Defense Disable Realtime Signature Delivery - Rule", "ESCU - Windows Impair Defense Disable Web Evaluation - Rule", "ESCU - Windows Impair Defense Disable Win Defender App Guard - Rule", "ESCU - Windows Impair Defense Disable Win Defender Compute File Hashes - Rule", "ESCU - Windows Impair Defense Disable Win Defender Gen reports - Rule", "ESCU - Windows Impair Defense Disable Win Defender Network Protection - Rule", "ESCU - Windows Impair Defense Disable Win Defender Report Infection - Rule", "ESCU - Windows Impair Defense Disable Win Defender Scan On Update - Rule", "ESCU - Windows Impair Defense Disable Win Defender Signature Retirement - Rule", "ESCU - Windows Impair Defense Overide Win Defender Phishing Filter - Rule", "ESCU - Windows Impair Defense Override SmartScreen Prompt - Rule", "ESCU - Windows Impair Defense Set Win Defender Smart Screen Level To Warn - Rule", "ESCU - Windows Impair Defenses Disable HVCI - Rule", "ESCU - Windows Impair Defenses Disable Win Defender Auto Logging - Rule", "ESCU - Windows Modify Registry Risk Behavior - Rule", "ESCU - Windows Modify Show Compress Color And Info Tip Registry - Rule", "ESCU - Windows Registry Certificate Added - Rule", "ESCU - Windows Registry Delete Task SD - Rule", "ESCU - Windows Registry Modification for Safe Mode Persistence - Rule", "ESCU - Windows Service Creation Using Registry Entry - Rule", "ESCU - WSReset UAC Bypass - Rule"]
description = Windows services are often used by attackers for persistence, privilege escalation, lateral movement, defense evasion, collection of data, a tool for recon, credential dumping and payload impact. This Analytic Story helps you monitor your environment for indications that Windows registry are being modified or created in a suspicious manner.
narrative = Windows Registry is one of the powerful and yet still mysterious Windows features that can tweak or manipulate Windows policies and low-level configuration settings. Because of this capability,  most malware, adversaries or threat actors abuse this hierarchical database to do their malicious intent on a targeted host or network environment. In these cases, attackers often use tools to create or modify registry in ways that are not typical for most environments, providing opportunities for detection.

[analytic_story://Windows Service Abuse]
category = Malware
last_updated = 2017-11-02
version = 3
references = ["https://attack.mitre.org/wiki/Technique/T1050", "https://attack.mitre.org/wiki/Technique/T1031"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Rico Valdez"}]
spec_version = 3
searches = ["ESCU - First Time Seen Running Windows Service - Rule", "ESCU - Reg exe Manipulating Windows Services Registry Keys - Rule", "ESCU - Sc exe Manipulating Windows Services - Rule", "ESCU - Get Notable History - Response Task", "ESCU - Get Parent Process Info - Response Task", "ESCU - Get Process Info - Response Task"]
description = Windows services are often used by attackers for persistence and the ability to load drivers or otherwise interact with the Windows kernel. This Analytic Story helps you monitor your environment for indications that Windows services are being modified or created in a suspicious manner.
narrative = The Windows operating system uses a services architecture to allow for running code in the background, similar to a UNIX daemon. Attackers will often leverage Windows services for persistence, hiding in plain sight, seeking the ability to run privileged code that can interact with the kernel. In many cases, attackers will create a new service to host their malicious code. Attackers have also been observed modifying unnecessary or unused services to point to their own code, as opposed to what was intended. In these cases, attackers often use tools to create or modify services in ways that are not typical for most environments, providing opportunities for detection.

[analytic_story://Windows System Binary Proxy Execution MSIExec]
category = Adversary Tactics
last_updated = 2022-06-16
version = 1
references = ["https://attack.mitre.org/techniques/T1218/007/"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Windows MSIExec DLLRegisterServer - Rule", "ESCU - Windows MSIExec Remote Download - Rule", "ESCU - Windows MSIExec Spawn Discovery Command - Rule", "ESCU - Windows MSIExec Unregister DLLRegisterServer - Rule", "ESCU - Windows MSIExec With Network Connections - Rule"]
description = Adversaries may abuse msiexec.exe to proxy execution of malicious payloads. Msiexec.exe is the command-line utility for the Windows Installer and is thus commonly associated with executing installation packages (.msi).
narrative = Adversaries may abuse msiexec.exe to launch local or network accessible MSI files. Msiexec.exe can also execute DLLs. Since it may be signed and native on Windows systems, msiexec.exe can be used to bypass application control solutions that do not account for its potential abuse. Msiexec.exe execution may also be elevated to SYSTEM privileges if the AlwaysInstallElevated policy is enabled.

[analytic_story://WinRAR Spoofing Attack CVE-2023-38831]
category = Adversary Tactics
last_updated = 2023-08-29
version = 1
references = ["https://www.group-ib.com/blog/cve-2023-38831-winrar-zero-day/", "https://nvd.nist.gov/vuln/detail/CVE-2023-38831"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - WinRAR Spawning Shell Application - Rule"]
description = Group-IB Threat Intelligence unit discovered a zero-day vulnerability, CVE-2023-38831, in WinRAR, a popular compression tool. Cybercriminals exploited this vulnerability to deliver various malware families, including DarkMe and GuLoader, by crafting ZIP archives with spoofed extensions, which were then distributed on trading forums. Once the malware was executed, it allowed cybercriminals to withdraw funds from brokers' accounts. RARLAB was immediately notified about the vulnerability and released a patch. Group-IB recommends users update WinRAR to the latest version, stay informed about cyber threats, be cautious with unknown attachments, enable 2FA, backup data, and follow the principle of least privilege.
narrative = Group-IB Threat Intelligence unit identified a critical zero-day vulnerability, CVE-2023-38831, in WinRAR, a widely used compression tool. This vulnerability was exploited by cybercriminals to craft ZIP archives containing malicious and non-malicious files, distributed on specialized trading forums. The exploit allowed them to spoof file extensions, hiding the launch of malicious scripts within an archive masquerading as a '.jpg', '.txt', or any other file format. When victims opened the specially crafted archive, it executed the malware, leading to unauthorized access to their broker accounts and enabling the cybercriminals to perform illicit financial transactions and withdraw funds. \
The vulnerability was discovered while researching the spread of DarkMe malware, a VisualBasic spy Trojan attributed to the financially motivated group, Evilnum. The malware was distributed alongside other malware families, such as GuLoader and Remcos RAT, via malicious ZIP archives posted on popular trading forums or distributed via file-sharing services. Despite efforts by forum administrators to warn users and disable threat actors' accounts, the cybercriminals continued to spread the malicious files, compromising devices, and leading to financial losses. \
Group-IB immediately notified RARLAB about the vulnerability, and they promptly responded by issuing a patch. The beta version of the patch was released on July 20, 2023, and the final updated version, WinRAR 6.23, was released on August 2, 2023. Group-IB recommends all users install the latest version of WinRAR to mitigate the risk of exploitation. \
In conclusion, the exploitation of the CVE-2023-38831 vulnerability highlights the constant risks associated with software vulnerabilities and the importance of remaining vigilant, keeping systems updated, and following security guidelines to avoid falling victim to such attacks. Collaboration between security researchers and software developers is essential to quickly identify and fix vulnerabilities, making it harder for cybercriminals to exploit them.

[analytic_story://Winter Vivern]
category = Malware
last_updated = 2023-02-16
version = 1
references = ["https://cert.gov.ua/article/3761023"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Any Powershell DownloadString - Rule", "ESCU - CMD Carry Out String Command Parameter - Rule", "ESCU - GetWmiObject User Account with PowerShell - Rule", "ESCU - GetWmiObject User Account with PowerShell Script Block - Rule", "ESCU - Powershell Fileless Script Contains Base64 Encoded Content - Rule", "ESCU - PowerShell Loading DotNET into Memory via Reflection - Rule", "ESCU - Schedule Task with HTTP Command Arguments - Rule", "ESCU - Scheduled Task Deleted Or Created via CMD - Rule", "ESCU - System User Discovery With Whoami - Rule", "ESCU - Windows Exfiltration Over C2 Via Invoke RestMethod - Rule", "ESCU - Windows Exfiltration Over C2 Via Powershell UploadString - Rule", "ESCU - Windows Scheduled Task Created Via XML - Rule", "ESCU - Windows Screen Capture Via Powershell - Rule", "ESCU - WinEvent Scheduled Task Created to Spawn Shell - Rule", "ESCU - WinEvent Scheduled Task Created Within Public Path - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule", "ESCU - WinEvent Windows Task Scheduler Event Action Started - Rule"]
description = Utilize searches that enable you to detect and investigate unusual activities potentially related to the Winter Vivern malicious software. This includes examining multiple timeout executions, scheduled task creations, screenshots, and downloading files through PowerShell, among other indicators.
narrative = The Winter Vivern malware, identified by CERT UA, is designed to download and run multiple PowerShell scripts on targeted hosts. These scripts aim to gather a variety of files with specific extensions, including (.edb, .ems, .eme, .emz, .key, .pem, .ovpn, .bat, .cer, .p12, .cfg, .log, .txt, .pdf, .doc, .docx, .xls, .xlsx, and .rdg), primarily from desktop directories. In addition to this, the malware captures desktop screenshots and performs data exfiltration using HTTP. To maintain its presence on the targeted host, Winter Vivern also establishes a persistence mechanism, such as creating a scheduled task.

[analytic_story://WordPress Vulnerabilities]
category = Adversary Tactics
last_updated = 2024-02-22
version = 1
references = ["https://attack.mitre.org/techniques/T1190", "https://github.com/Tornad0007/CVE-2024-25600-Bricks-Builder-plugin-for-WordPress/blob/main/exploit.py", "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-25600", "https://op-c.net/blog/cve-2024-25600-wordpresss-bricks-builder-rce-flaw-under-active-exploitation/", "https://thehackernews.com/2024/02/wordpress-bricks-theme-under-active.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - WordPress Bricks Builder plugin RCE - Rule"]
description = This analytic story provides a collection of analytics that detect potential exploitation of WordPress vulnerabilities. The analytics are focused on the detection of known vulnerabilities in WordPress plugins and themes.
narrative = The following collection of analytics are focused on the detection of known vulnerabilities in WordPress plugins and themes. The analytics are focused on the detection of known vulnerabilities in WordPress plugins and themes.

[analytic_story://WS FTP Server Critical Vulnerabilities]
category = Adversary Tactics
last_updated = 2023-10-01
version = 1
references = ["https://www.assetnote.io/resources/research/rce-in-progress-ws-ftp-ad-hoc-via-iis-http-modules-cve-2023-40044", "https://community.progress.com/s/article/WS-FTP-Server-Critical-Vulnerability-September-2023", "https://www.cve.org/CVERecord?id=CVE-2023-40044", "https://www.rapid7.com/blog/post/2023/09/29/etr-critical-vulnerabilities-in-ws_ftp-server/", "https://www.splunk.com/en_us/blog/security/fantastic-iis-modules-and-how-to-find-them.html"]
maintainers = [{"company": "Splunk", "email": "-", "name": "Michael Haag"}]
spec_version = 3
searches = ["ESCU - Detect Webshell Exploit Behavior - Rule", "ESCU - W3WP Spawning Shell - Rule", "ESCU - Windows IIS Components Get-WebGlobalModule Module Query - Rule", "ESCU - WS FTP Remote Code Execution - Rule"]
description = A critical security advisory was released by Progress Software on September 27, 2023, concerning multiple vulnerabilities in WS_FTP Server, a widely-used secure file transfer solution. The two critical vulnerabilities are CVE-2023-40044, a .NET deserialization flaw, and CVE-2023-42657, a directory traversal vulnerability. Rapid7 has observed active exploitation of these vulnerabilities. Affected versions are prior to 8.7.4 and 8.8.2. Immediate action is advised - upgrade to WS_FTP Server version 8.8.2. For those unable to update, disabling the Ad Hoc Transfer module is suggested as a temporary measure. This comes in the wake of increased scrutiny following the Cl0p ransomware attack on MOVEit Transfer in May 2023.
narrative = Two critical vulnerabilities have been identified in WS_FTP Server, a widely-used secure file transfer solution. The first, CVE-2023-40044, is a .NET deserialization flaw that targets the Ad Hoc Transfer module of WS_FTP Server versions earlier than 8.7.4 and 8.8.2. This flaw allows an attacker to execute arbitrary commands on the server's operating system without needing authentication. The second vulnerability, CVE-2023-42657, is a directory traversal flaw that allows attackers to perform unauthorized file operations outside of their authorized WS_FTP folder. In severe cases, the attacker could escape the WS_FTP Server file structure and perform operations on the underlying operating system. Both vulnerabilities have been observed being exploited in the wild and immediate action for mitigation is strongly advised. Updating to WS_FTP Server version 8.8.2 is recommended. For those unable to update, disabling the Ad Hoc Transfer module is suggested as a temporary measure.

[analytic_story://XMRig]
category = Malware
last_updated = 2021-05-07
version = 1
references = ["https://github.com/xmrig/xmrig", "https://www.getmonero.org/resources/user-guides/mine-to-pool.html", "https://thedfirreport.com/2020/04/20/sqlserver-or-the-miner-in-the-basement/", "https://blog.checkpoint.com/2021/03/11/february-2021s-most-wanted-malware-trickbot-takes-over-following-emotet-shutdown/"]
maintainers = [{"company": "Rod Soto Splunk", "email": "-", "name": "Teoderick Contreras"}]
spec_version = 3
searches = ["ESCU - Attacker Tools On Endpoint - Rule", "ESCU - Deleting Of Net Users - Rule", "ESCU - Disable Windows App Hotkeys - Rule", "ESCU - Disabling Net User Account - Rule", "ESCU - Download Files Using Telegram - Rule", "ESCU - Enumerate Users Local Group Using Telegram - Rule", "ESCU - Excessive Attempt To Disable Services - Rule", "ESCU - Excessive Service Stop Attempt - Rule", "ESCU - Excessive Usage Of Cacls App - Rule", "ESCU - Excessive Usage Of Net App - Rule", "ESCU - Excessive Usage Of Taskkill - Rule", "ESCU - Executables Or Script Creation In Suspicious Path - Rule", "ESCU - Hide User Account From Sign-In Screen - Rule", "ESCU - Icacls Deny Command - Rule", "ESCU - ICACLS Grant Command - Rule", "ESCU - Modify ACL permission To Files Or Folder - Rule", "ESCU - Process Kill Base On File Path - Rule", "ESCU - Schtasks Run Task On Demand - Rule", "ESCU - Suspicious Driver Loaded Path - Rule", "ESCU - Suspicious Process File Path - Rule", "ESCU - XMRIG Driver Loaded - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to the xmrig monero, including looking for file writes associated with its payload, process command-line, defense evasion (killing services, deleting users, modifying files or folder permission, killing other malware or other coin miner) and hacking tools including Telegram as mean of Command And Control (C2) to download other files. Adversaries may leverage the resources of co-opted systems in order to solve resource intensive problems which may impact system and/or hosted service availability. One common purpose for Resource Hijacking is to validate transactions of cryptocurrency networks and earn virtual currency. Adversaries may consume enough system resources to negatively impact and/or cause affected machines to become unresponsive. (1) Servers and cloud-based (2) systems are common targets because of the high potential for available resources, but user endpoint systems may also be compromised and used for Resource Hijacking and cryptocurrency mining.
narrative = XMRig is a high performance, open source, cross platform RandomX, KawPow, CryptoNight and AstroBWT unified CPU/GPU miner. This monero is seen in the wild on May 2017.

[analytic_story://Zscaler Browser Proxy Threats]
category = Adversary Tactics
last_updated = 2023-10-25
version = 1
references = ["https://threatlibrary.zscaler.com/", "https://help.zscaler.com/zia/about-threat-categories"]
maintainers = [{"company": "Gowthamaraj Rajendran", "email": "-", "name": "Rod Soto"}]
spec_version = 3
searches = ["ESCU - Zscaler Adware Activities Threat Blocked - Rule", "ESCU - Zscaler Behavior Analysis Threat Blocked - Rule", "ESCU - Zscaler CryptoMiner Downloaded Threat Blocked - Rule", "ESCU - Zscaler Employment Search Web Activity - Rule", "ESCU - Zscaler Exploit Threat Blocked - Rule", "ESCU - Zscaler Legal Liability Threat Blocked - Rule", "ESCU - Zscaler Malware Activity Threat Blocked - Rule", "ESCU - Zscaler Phishing Activity Threat Blocked - Rule", "ESCU - Zscaler Potentially Abused File Download - Rule", "ESCU - Zscaler Privacy Risk Destinations Threat Blocked - Rule", "ESCU - Zscaler Scam Destinations Threat Blocked - Rule", "ESCU - Zscaler Virus Download threat blocked - Rule"]
description = Leverage searches that allow you to detect and investigate unusual activities that might relate to malicious activity from Zscaler. This also encompasses monitoring for events such as users downloading harmful files or accessing websites that pose a risk to system and network security. Additionally, the narrative extends to the detection of insider threats, ensuring comprehensive protection from both external and internal vulnerabilities. By leveraging Zscaler with Splunk, organizations can fortify their defenses, safeguarding against a wide spectrum of cyber threats and maintaining a secure operational environment.
narrative = Zscaler Client Connector is an application installed on your device to ensure that your internet traffic and access to your organization's internal apps are secure and in compliance with your organization's policies, even when you're off your corporate network.

### END STORIES ###

### RESPONSE TASKS ###

[savedsearch://ESCU - All backup logs for host - Response Task]
type = investigation
explanation = none
how_to_implement = The successfully implement this search you must first send your backup logs to Splunk.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Amazon EKS Kubernetes activity by src ip - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your Cloud Watch EKS inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - AWS Investigate Security Hub alerts by dest - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - AWS Investigate User Activities By AccessKeyId - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - AWS Investigate User Activities By ARN - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - AWS Network ACL Details from ID - Response Task]
type = investigation
explanation = none
how_to_implement = In order to implement this search, you must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS(version 4.4.0 or later) and configure your AWS description inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - AWS Network Interface details via resourceId - Response Task]
type = investigation
explanation = none
how_to_implement = In order to implement this search, you must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS(version 4.4.0 or later) and configure your AWS configuration inputs
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - AWS S3 Bucket details via bucketName - Response Task]
type = investigation
explanation = none
how_to_implement = To implement this search, you must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later) and configure your AWS inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - GCP Kubernetes activity by src ip - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the GCP App for Splunk (version 2.0.0 or later), then configure stackdriver and set a Pub/Sub subscription to be imported to Splunk. You must also install Cloud Infrastructure data model.Customize the macro kubernetes_gcp_scan_fingerprint_attack_detection to filter out FPs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get All AWS Activity From City - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get All AWS Activity From Country - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get All AWS Activity From IP Address - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get All AWS Activity From Region - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Backup Logs For Endpoint - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting your backup logs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Certificate logs for a domain - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting your certificates or SSL logs from your network traffic into your Certificates datamodel. Please note the wildcard(*) before domain in the search syntax, we use to match for all domain and subdomain combinations
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get DNS Server History for a host - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search, you must be ingesting your DNS traffic
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get DNS traffic ratio - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting your network traffic
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get EC2 Instance Details by instanceId - Response Task]
type = investigation
explanation = none
how_to_implement = In order to implement this search, you must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS(version 4.4.0 or later) and configure your AWS description inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get EC2 Launch Details - Response Task]
type = investigation
explanation = none
how_to_implement = In order to implement this search, you must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS(version 4.4.0 or later) and configure your AWS description inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Email Info - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must be ingesting your email logs or capturing unencrypted network traffic which contains email communications.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Emails From Specific Sender - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must ingest your email logs or capture unencrypted email communications within network traffic, and populate the Email data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get First Occurrence and Last Occurrence of a MAC Address - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search, you must be ingesting the logs from your DHCP server.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get History Of Email Sources - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must ingest your email logs or capture unencrypted email communications within network traffic, and populate the Email data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Logon Rights Modifications For Endpoint - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must be ingesting your Windows event logs
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Logon Rights Modifications For User - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must be ingesting your Windows event logs
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Notable History - Response Task]
type = investigation
explanation = none
how_to_implement = If you are using Enterprise Security you are likely already creating notable events with your correlation rules. No additional configuration is necessary.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Outbound Emails to Hidden Cobra Threat Actors - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must ingest your email logs or capture unencrypted email communications within network traffic, and populate the Email data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Parent Process Info - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting endpoint data that tracks process activity, including parent-child relationships from your endpoints to populate the Endpoint data model in the Processes node. The command-line arguments are mapped to the "process" field in the Endpoint data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Process File Activity - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must be ingesting endpoint data and populating the Endpoint data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Process Info - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must be ingesting endpoint data and populating the Endpoint data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Process Information For Port Activity - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you must be ingesting endpoint data that associates processes with network events and populate the Endpoint Datamodel
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Process Responsible For The DNS Traffic - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting endpoint data that associates processes with network events into the Endpoint datamodel. This can come from endpoint protection products such as carbon black, or endpoint data sources such as Sysmon.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Sysmon WMI Activity for Host - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search, you must be collecting Sysmon data using Sysmon version 6.1 or greater and have Sysmon configured to generate events for WMI activity. In addition, you must have at least version 6.0.4 of the Sysmon TA installed to properly parse the fields.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Get Web Session Information via session id - Response Task]
type = investigation
explanation = none
how_to_implement = This search leverages data extracted from Stream:HTTP. You must configure the HTTP stream using the Splunk Stream App on your Splunk Stream deployment server.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate AWS activities via region name - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate AWS User Activities by user field - Response Task]
type = investigation
explanation = none
how_to_implement = You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Failed Logins for Multiple Destinations - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you need to be ingesting authentication logs from your various systems and populating the Authentication data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Network Traffic From src ip - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search, you must be ingesting your web-traffic logs and populating the web data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Okta Activity by app - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting Okta logs
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Okta Activity by IP Address - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting Okta logs
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Pass the Hash Attempts - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you need be ingesting windows security logs. This search uses an input macro named `wineventlog_security`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Security logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Pass the Ticket Attempts - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you need to be ingesting windows security logs. This search uses an input macro named `wineventlog_security`. We strongly recommend that you specify your environment-specific configurations (index, source, sourcetype, etc.) for Windows Security logs. Replace the macro definition with configurations for your Splunk environment. The search also uses a post-filter macro designed to filter out known false positives.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Previous Unseen User - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search you need to be ingesting authentication logs from your various systems and populating the Authentication data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Successful Remote Desktop Authentications - Response Task]
type = investigation
explanation = none
how_to_implement = You must be populating the Authentication data model with security events from your Windows event logs.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Suspicious Strings in HTTP Header - Response Task]
type = investigation
explanation = none
how_to_implement = This particular search leverages data extracted from Stream:HTTP. You must configure the http stream using the Splunk Stream App on your Splunk Stream deployment server to extract the cs_content_type field.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate User Activities In Okta - Response Task]
type = investigation
explanation = none
how_to_implement = You must be ingesting Okta logs
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0

[savedsearch://ESCU - Investigate Web POSTs From src - Response Task]
type = investigation
explanation = none
how_to_implement = To successfully implement this search, you must be ingesting your web-traffic logs and populating the web data model.
known_false_positives = not defined
earliest_time_offset = 14400
latest_time_offset = 0


### END RESPONSE TASKS ###