Attack Chain

1. An attacker gains initial access to the target system, potentially through exploiting a vulnerability in a web application or service running on the server (e.g., SharePoint).
2. The attacker leverages the compromised web application to upload a malicious ASPX file to a directory within the web server’s file system, specifically targeting locations like “?:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\*”.
3. The uploaded ASPX file contains malicious code designed to provide the attacker with remote access and control over the server.
4. The attacker triggers the execution of the ASPX file by sending a request to the web server, which processes the ASPX file and executes the embedded malicious code.
5. The web shell allows the attacker to execute arbitrary commands on the server, potentially escalating privileges and moving laterally within the network.
6. The attacker uses the web shell to establish persistence on the compromised server, ensuring continued access even after the initial vulnerability is patched.
7. The attacker may use the web shell to exfiltrate sensitive data from the server or to deploy additional malware and tools.

Impact

A successful web shell deployment can lead to complete compromise of the affected server, potentially impacting numerous organizations. Attackers can use web shells to execute arbitrary code, steal sensitive data, and establish persistent access to internal networks. The impact includes data breaches, financial losses, and reputational damage. Successful exploitation of SharePoint vulnerabilities leading to web shell deployment has been observed in the wild.

Recommendation

• Deploy the Sigma rule “Web Shell ASPX File Creation in Common Directories” to detect suspicious ASPX file creation events, filtering out legitimate processes to reduce false positives.
• Enable Sysmon Event ID 11 (File Create) to capture file creation events on Windows systems, which is a data source for the Sigma rule.
• Investigate any alerts generated by the Sigma rule “Web Shell ASPX File Creation in Common Directories” by examining the file path, creating process, and network activity around the time of the event.
• Monitor web server logs for suspicious requests targeting ASPX files in common web server directories, as referenced in the rule description.

Attack Chain

1. Initial access is achieved via an unknown method (e.g., phishing, exploit).
2. Malware is installed on the victim’s system, likely outside typical program directories.
3. The malware establishes a DNS connection to a commonly abused web service (e.g., pastebin.com, raw.githubusercontent.com) to obscure C2 traffic.
4. The malware sends encrypted or encoded commands to the web service.
5. The web service acts as an intermediary, relaying the commands to the attacker’s C2 server.
6. The C2 server responds with instructions, which are then relayed back to the compromised host through the same web service.
7. The malware executes the received commands, potentially leading to data exfiltration, lateral movement, or other malicious activities.
8. The attacker maintains persistent access and control over the compromised system using the web service as a hidden C2 channel.

Impact

Successful exploitation can lead to data theft, system compromise, and further propagation within the network. Since commonly used web services are utilized, the malicious activity can blend in with legitimate network traffic, making it difficult to detect. The impact can range from minor data breaches to complete network compromise, depending on the attacker’s objectives and the level of access gained.

Recommendation

• Deploy the Sigma rule Detect Commonly Abused Web Services via DNS to your SIEM to identify suspicious DNS queries to known C2 web services originating from anomalous processes.
• Enable DNS query logging on Windows endpoints to provide the data source required for the Sigma rule.
• Review network connection logs for processes outside standard installation directories communicating with domains listed in the query section of the Sigma rule to identify potential C2 activity.
• Implement network segmentation to limit the potential impact of compromised hosts.

Attack Chain

This attack chain describes how an attacker might evade detection in a SOC environment using ineffective metrics.

1. Initial Foothold: An attacker gains initial access via a vulnerability or credential compromise. This is not directly measured by common SOC metrics.
2. Internal Reconnaissance: The attacker performs internal reconnaissance, such as searching for passwords in a SharePoint.
3. Lateral Movement: The attacker uses discovered credentials to move laterally within the network.
4. Data Access: The attacker accesses sensitive data, potentially including intellectual property or personal information.
5. Exfiltration Preparation: The attacker prepares the data for exfiltration, such as compressing or encrypting it.
6. Exfiltration: The attacker exfiltrates the data to an external server.
7. Persistence: The attacker establishes persistence mechanisms to maintain access for future operations.
8. Impact: The attacker achieves their objective, which could be data theft, system disruption, or financial gain. The lack of focus on TTD/TTR means the breach goes unnoticed until significant damage is done.

Impact

The use of poor metrics can lead to a significant increase in dwell time, allowing attackers more time to achieve their objectives. Organizations may experience data breaches, financial losses, reputational damage, and regulatory fines. The NCSC observed SOCs with great potential rendered entirely ineffective through poor choice and application of metrics. If “time to close a ticket” is prioritized, analysts may quickly dismiss alerts as false positives, missing crucial indicators of a real attack.

Recommendation

• Implement TTD/TTR as primary metrics to measure SOC effectiveness, using red/purple teaming to generate data.
• Prioritize hypothesis-led threat hunting to proactively identify potential threats and improve detection capabilities.
• Establish and maintain hard thresholds for false positive rates to minimize alert fatigue and ensure analysts focus on genuine threats.
• Evaluate and refine detection rules to maximize true positives and minimize false positives.
• Focus on the value of collected logs rather than sheer volume to ensure relevant data is available for threat detection.
• Develop detection rules based on understanding likely attackers and their techniques mentioned in the overview.