Archive

Archive for the ‘web shell’ Category

Web shell attacks continue to rise

February 11th, 2021 No comments

One year ago, we reported the steady increase in the use of web shells in attacks worldwide. The latest Microsoft 365 Defender data shows that this trend not only continued, it accelerated: every month from August 2020 to January 2021, we registered an average of 140,000 encounters of these threats on servers, almost double the 77,000 monthly average we saw last year.

Figure 1. Web shell encounters on servers

The escalating prevalence of web shells may be attributed to how simple and effective they can be for attackers. A web shell is typically a small piece of malicious code written in typical web development programming languages (e.g., ASP, PHP, JSP) that attackers implant on web servers to provide remote access and code execution to server functions. Web shells allow attackers to run commands on servers to steal data or use the server as launch pad for other activities like credential theft, lateral movement, deployment of additional payloads, or hands-on-keyboard activity, while allowing attackers to persist in an affected organization.

As web shells are increasingly more common in attacks, both commodity and targeted, we continue to monitor and investigate this trend to ensure customers are protected. In this blog, we will discuss challenges in detecting web shells, and the Microsoft technologies and investigation tools available today that organizations can use to defend against these threats. We will also share guidance for hardening networks against web shell attacks.

Web shells as entry point for attacks

Attackers install web shells on servers by taking advantage of security gaps, typically vulnerabilities in web applications, in internet-facing servers. These attackers scan the internet, often using public scanning interfaces like shodan.io, to locate servers to target. They may use previously fixed vulnerabilities that unfortunately remain unpatched in many servers, but they are also known to quickly take advantage of newly disclosed vulnerabilities.

For example, on June 30, F5 Networks released a patch for CVE-2020-5902, a remote code execution (RCE) vulnerability in Traffic Management User Interface (TMUI). The vulnerability is a directory traversal bug with a CVSS score of 9.8 out of a possible 10. Just four days later, on July 4, exploit code was added to a Metasploit module.

Figure 2. CVE-2020-5902 exploit code

The following day, Microsoft researchers started seeing the exploit being used by attackers to upload a web shell to vulnerable servers. The web shell was used to run common cryptocurrency miners. In the days that followed, industry security researchers saw the exploit being broadly used to deploy web shells, with multiple variants surfacing not long after.

This incident demonstrates the importance of keeping servers up to date and hardened against web shell attacks. Web servers are frequently accessible from the internet and can be used by attackers to gain access to a network.

Web shells as persistence mechanisms

Once installed on a server, web shells serve as one of the most effective means of persistence in an enterprise. We frequently see cases where web shells are used solely as a persistence mechanism. Web shells guarantee that a backdoor exists in a compromised network, because an attacker leaves a malicious implant after establishing an initial foothold on a server. If left undetected, web shells provide a way for attackers to continue to gather data from and monetize the networks that they have access to.

Compromise recovery cannot be successful and enduring without locating and removing attacker persistence mechanisms. And while rebuilding a single compromised system is a great solution, restoring existing assets is the only feasible option for many. So, finding and removing all backdoors is a critical aspect of compromise recovery.

And this brings us back to the challenge of web shell detection. As we mentioned earlier, web shells can be generalized as a means of executing arbitrary attacker input by way of an implant. The first challenge is dealing with just how many ways an attacker can execute code. Web applications support a great array of languages and frameworks and, thus, provide a high degree of flexibility and compatibility that attackers take advantage of.

In addition, the volume of network traffic plus the usual noise of constant internet attacks means that targeted traffic aimed at a web server can blend right in, making detection of web shells a lot harder and requiring advanced behavior-based detections that can identify and stop malicious activities that hide in plain sight.

Challenges in detecting web shells

Web shells can be built using any of several languages that are popular with web applications. Within each language, there are several means of executing arbitrary commands and there are multiple means for arbitrary attacker input. Attackers can also hide instructions in the user agent string or any of the parameters that get passed during a web server/client exchange.

Attackers combine all these options into just a couple of bytes to produce a web shell, for example:

Figure 3. Example of web shell code

In the example above, the only readable word in the web shell is “eval”, which can be easy to miss or misinterpret. When analyzing script, it is important to leverage contextual clues. For example, a scheduled task called “Update Google” that downloads and runs code from a suspicious website should be inspected more closely.

With web shells, analyzing context can be a challenge because the context is not clear until the shell is used. In the following code, the most useful clues are “system” and “cat /etc/passwd”, but they do not appear until the attacker interacts with the web shell:

Figure 4. Another example of web shell code

Another challenge in detecting web shells is uncovering intent. A harmless-seeming script can be malicious depending on intent. But when attackers can upload arbitrary input files in the web directory, then they can upload a full-featured web shell that allows arbitrary code execution—which some very simple web shells do.

These file-upload web shells are simple, lightweight, and easily overlooked because they cannot execute attacker commands on their own. Instead, they can only upload files, such as full-featured web shells, onto web servers. Because of their simplicity, they are difficult to detect and can be dismissed as benign, and so they are often used by attackers for persistence or for early stages of exploitation.

Finally, attackers are known to hide web shells in non-executable file formats, such as media files. Web servers configured to execute server-side code create additional challenges for detecting web shells, because on a web server, a media file is scanned for server-side execution instructions. Attackers can hide web shell scripts within a photo and upload it to a web server. When this file is loaded and analyzed on a workstation, the photo is harmless. But when a web browser asks a server for this file, malicious code executes server side.

These challenges in detecting web shells contribute to their increasing popularity as an attack tool. We constantly monitor how these evasive threats are utilized in cyberattacks, and we continue to improve protections. In the next section, we discuss how behavior-based detection technologies help us protect customers from web shell attacks.

How Microsoft helps defend networks against web shell attacks

Gaining visibility into internet-facing servers is key to detecting and addressing the threat of web shells. To tackle challenges in detecting these threats, Microsoft Defender for Endpoint uses a combination of durable protections that prevent web shell installation and behavior-based detections that identify related malicious activity. Microsoft Defender for Endpoint exposes malicious behavior by analyzing script file writes and process executions. Due to the nature of web shells, static analysis is not effective—as we have shown, it is relatively easy to modify web shells and bypass static protections. To effectively deliver protection, Microsoft Defender for Endpoint uses multiple layers of protection through behavior inspection.

Behavior-based blocking and containment capabilities, which use engines that specialize in detecting threats by analyzing behavior, monitor web-accessible directories for any new script file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process tree can yield more reliable signals and surface malicious attempts. The engine can then remediate the script, neutralizing the primary infection vector. For example, IIS instance (w3wp.exe) running suspicious processes such as ‘cmd.exe /c echo’, ‘certutil.exe’, or ‘powershell.exe’ that result in the creation of script files in web -accessible folders is a rare event and is, thus, typically a strong sign of web server compromise and web shell installation.

Microsoft Defender for Endpoint also detects web shell installation attempts originating from remote systems within the organization using various lateral movement methods. For example, attackers have been observed to drop web shells through Windows Remote Management (WinRM) or use existing Windows commands to transfer web shells over SMB. On the web server, these remote actions are carried by system processes, thus giving visibility into the process tree. System privilege process dropping script files is another suspicious event and provides the behavior inspection engines ways to remediate the script before the attackers can perform any malicious actions.

Behavior-based protection also provides post-compromise defense in scenarios where attackers are already operating and running commands on web servers. Once attackers gain access to a server, one of their first steps is to understand the privilege and the environment they have access to by using built-in reconnaissance commands that are not typically used by web applications. IIS instance (w3wp.exe) running commands like ‘net’, ‘whoami’, ‘dir’, ‘cmd.exe’, or ‘query’, to name a few, is typically a strong early indicator of web shell activity.

IIS servers have built-in management tools used by administrators to perform various maintenance tasks. These platforms surface various PowerShell cmdlets that can expose critical information to the attackers. IIS instances (w3wp.exe) that host various web-facing client services such as Outlook on the web (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the Exchange Control Panel or ECP) accessing the management platform or executing below cmdlets is a suspicious activity and signifies a hands-on-keyboard attack. The behavior engine monitors execution of such cmdlets and the responsible process trees, for example:

With its behavior-based blocking and containment capabilities, Microsoft Defender for Endpoint can identify and stop behavior associated with web shell attacks. It raises alerts for these detections, enabling security operations teams to use the rich investigation tools in Microsoft Defender for Endpoint to perform additional investigation and hunting for related or similar threats.

Figure 5. Microsoft Defender for Endpoint alerts for behaviors related to web shell attacks

Microsoft 365 Defender and Microsoft Defender for Endpoint customers can also run advanced hunting queries to proactively hunt for web shell attacks:

Look for suspicious process that IIS worker process (w3wp.exe), Apache HTTP server processes (httpd.exe, visualsvnserver.exe), etc. do not typically initiate (e.g., cmd.exe and powershell.exe)

DeviceProcessEvents
| where InitiatingProcessCommandLine has_any("beasvc.exe","coldfusion.exe","httpd.exe","owstimer.exe","visualsvnserver.exe","w3wp.exe") or InitiatingProcessCommandLine contains 'tomcat'
| where FileName != "csc.exe" // exclude csharp compiler
| where FileName != "php-cgi.exe" //exclude php group, fast cgi
| where FileName != "vbc.exe" //exclude Visual Basic Command Line Compiler
| summarize by FileName

Look for suspicious web shell execution, this can identify processes that are associated with remote execution and reconnaissance activity (example: “arp”, “certutil”, “cmd”, “echo”, “ipconfig”, “gpresult”, “hostname”, “net”, “netstat”, “nltest”, “nslookup”, “ping”, “powershell”, “psexec”, “qwinsta”, “route”, “systeminfo”, “tasklist”, “wget”, “whoami”, “wmic”, etc.)

DeviceProcessEvents
| where InitiatingProcessParentFileName in~("beasvc.exe","coldfusion.exe","httpd.exe","owstimer.exe","visualsvnserver.exe","w3wp.exe") or InitiatingProcessParentFileName startswith "tomcat"
| where InitiatingProcessFileName in~("powershell.exe","powershell_ise.exe","cmd.exe")
| where FileName != 'conhost.exe'

Hardening servers against web shells

A single web shell allowing attackers to remotely run commands on a server can have far-reaching consequences. With script-based malware, however, everything eventually funnels to a few natural chokepoints, such as cmd.exe, powershell.exe, and cscript.exe. As with most attack vectors, prevention is critical.

Organizations can harden systems against web shell attacks by taking these preventive steps:

  • Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Use Threat and Vulnerability Management to discover and fix these weaknesses. Deploy the latest security updates as soon as they become available.
  • Implement proper segmentation of your perimeter network, such that a compromised web server does not lead to the compromise of the enterprise network.
  • Enable antivirus protection on web servers. Turn on cloud-delivered protection to get the latest defenses against new and emerging threats. Users should only be able to upload files in directories that can be scanned by antivirus and configured to not allow server-side scripting or execution.
  • Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
  • Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible, limiting lateral movement, as well as other attack activities.
  • Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
  • Practice good credential hygiene. Limit the use of accounts with local or domain admin level privileges.

Web shells and the attacks that they enable are a multi-faceted threat that require comprehensive visibility across domains and platforms. Microsoft 365 Defender correlates threat data from endpoints, email and data, identities, and apps to coordinate cross-domain protection. Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

 

Detection and Response Team (DART)

Microsoft Defender Security Research Team

 

The post Web shell attacks continue to rise appeared first on Microsoft Security.

Defending Exchange servers under attack

June 24th, 2020 No comments

Securing Exchange servers is one of the most important things defenders can do to limit organizational exposure to attacks. Any threat or vulnerability impacting Exchange servers should be treated with the highest priority because these servers contain critical business data, as well as highly privileged accounts that attackers attempt to compromise to gain admin rights to the server and, consequently, complete control of the network.

If compromised, Exchange servers provide a unique environment that could allow attackers to perform various tasks using the same built-in tools or scripts that admins use for maintenance. This is exacerbated by the fact that Exchange servers have traditionally lacked antivirus solutions, network protection, the latest security updates, and proper security configuration, often intentionally, due to the misguided notion that these protections interfere with normal Exchange functions. Attackers know this, and they leverage this knowledge to gain a stable foothold on a target organization.

There are two primary ways in which Exchange servers are compromised. The first and more common scenario is attackers launching social engineering or drive-by download attacks targeting endpoints, where they steal credentials and move laterally to other endpoints in a progressive dump-escalate-move method until they gain access to an Exchange server.

The second scenario is where attackers exploit a remote code execution vulnerability affecting the underlying Internet Information Service (IIS) component of a target Exchange server. This is an attacker’s dream: directly landing on a server and, if the server has misconfigured access levels, gain system privileges.

The first scenario is more common, but we’re seeing a rise in attacks of the second variety; specifically, attacks that exploit Exchange vulnerabilities like CVE-2020-0688. The security update that fixes this vulnerability has been available for several months, but, notably, to this day, attackers find vulnerable servers to target.

In many cases, after attackers gain access to an Exchange server, what follows is the deployment of web shell into one of the many web accessible paths on the server. As we discussed in a previous blog, web shells allow attackers to steal data or perform malicious actions for further compromise.

Behavior-based detection and blocking of malicious activities on Exchange servers

Adversaries like using web shells, which are relatively small pieces of malicious code written in common programming languages, because these can be easily modified to evade traditional file-based protections. A more durable approach to detecting web shell activity involves profiling process activities originating from external-facing Exchange applications.

Behavior-based blocking and containment capabilities in Microsoft Defender ATP, which use engines that specialize in detecting threats by analyzing behavior, surface suspicious and malicious activities on Exchange servers. These detection engines are powered by cloud-based machine learning classifiers that are trained by expert-driven profiling of legitimate vs. suspicious activities in Exchange servers.

In April, multiple Exchange-specific behavior-based detections picked up unusual activity. The telemetry showed attackers operating on on-premises Exchange servers using deployed web shells. Whenever attackers interacted with the web shell, the hijacked application pool ran the command on behalf of the attacker, generating an interesting process chain. Common services, for example Outlook on the web  (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the  Exchange Control Panel or ECP), executing net.exe, cmd.exe, and other known living-off-the-land binaries (LOLBins) like mshta.exe is very suspicious and should be further investigated.

Figure 1. Behavior-based detections of attacker activity on Exchange servers

In this blog, we’ll share our investigation of the Exchange attacks in early April, covering multiple campaigns occurring at the same time. The data and techniques from this analysis make up an anatomy of Exchange server attacks. Notably, the attacks used multiple fileless techniques, adding another layer of complexity to detecting and resolving these threats, and demonstrating how behavior-based detections are key to protecting organizations.

Figure 2. Anatomy of an Exchange server attack

Initial access: Web shell deployment

Attackers started interacting with target Exchange servers through web shells they had deployed. Any path accessible over the internet is a potential target for web shell deployment, but in these attacks, the most common client access paths were:

  • %ProgramFiles%\Microsoft\Exchange Server\<version>\ClientAccess
  • %ProgramFiles%\Microsoft\Exchange Server\<version>\FrontEnd

The ClientAccess and FrontEnd directories provide various client access services such as Outlook on the web, EAC, and AutoDiscover, to name a few. These IIS virtual directories are automatically configured during server installation and provide authentication and proxy services for internal and external client connections.

These directories should be monitored for any new file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process results in more reliable signals. Common services like OWA or ECP dropping .aspx or .ashx files in any of the said directories is highly suspicious.

In our investigation, most of these attacks used the China Chopper web shell. The attackers tried to blend the web shell script file with other .aspx files present on the system by using common file names. In many cases, hijacked servers used the ‘echo’ command to write the web shell. In other cases, certutil.exe or powershell.exe were used. Here are some examples of the China Chopper codes that were dropped in these attacks:

We also observed the attackers switching web shells or introducing two or more for various purposes. In one case, the attackers created an .ashx version of a popular, publicly available .aspx web shell, which exposes minimum functionality:

Figure 3. Microsoft Defender ATP alert for web shell

Reconnaissance

After web shell deployment, attackers typically ran an initial set of exploratory commands like whoami, ping, and net user. In most cases, the hijacked application pool services were running with system privileges, giving attackers the highest privilege.

Attackers enumerated all local groups and members on the domain to identify targets. Interestingly, in some campaigns, attackers used open-source user group enumerating tools like lg.exe instead of the built-in net.exe. Attackers also used the EternalBlue exploit and nbtstat scanner to identify vulnerable machines on the network.

Next, the attackers ran built-in Exchange Management Shell cmdlets to gain more information about the exchange environment. Attackers used these cmdlets to perform the following:

  • List all Exchange admin center virtual directories in client access services on all Mailbox servers in the network
  • Get a summary list of all the Exchange servers in the network
  • Get information on mailboxes, such as size and number of items, along with role assignments and permissions.

Figure 4. Microsoft Defender ATP alert showing process tree for anomalous account lookups

Persistence

On misconfigured servers where they have gained the highest privileges, attackers were able to add a new user account on the server. This gave the attackers the ability to access the server without the need to deploy any remote access tools.

The attackers then added the newly created account to high-privilege groups like Administrators, Remote Desktop Users, and Enterprise Admins, practically making the attackers a domain admin with unrestricted access to any users or group in the organization.

Figure 5. Microsoft Defender ATP alert showing process tree for addition of local admin using Net commands

Credential access

Exchange servers contain the most sensitive users and groups in an organization. Gaining credentials to these accounts could virtually give attackers domain admin privileges.

In our investigation, the attackers first dumped user hashes by saving the Security Account Manager (SAM) database from the registry.

Next, the attackers used the ProcDump tool to dump the Local Security Authority Subsystem Service (LSASS) memory. The dumps were later archived and uploaded to a remote location.

In some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server.

Figure 6. Microsoft Defender ATP alert on detection of Mimikatz

In environments where Mimiktaz was blocked, attackers dropped a modified version with hardcoded implementation to avoid detection. Attackers also added a wrapper written in the Go programming language to make the binary more than 5 MB. The binary used the open-source MemoryModule library to load the binary using reflective DLL injection. Thus, the payload never touched the disk and was present only in memory, achieving a fileless persistence.

The attackers also enabled ‘wdigest’ registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attacker to steal the actual password, not just the hash.

Another example of stealthy execution that attackers implemented was creating a wrapper binary for ProcDump and Mimikatz. When run, the tool dropped and executed the ProcDump binary to dump the LSASS memory. The memory dump was loaded inside the same binary and parsed to extract passwords, another example of reflective DLL injection where the Mimikatz binary was present only in memory.

With attacker-controlled accounts now part of Domain Admins group, the attackers performed a technique called DCSYNC attack, which abuses the Active Directory replication capability to request account information, such as the NTLM hashes of all the users’ passwords in the organization. This technique is extremely stealthy because it can be performed without running a single command on the actual domain controller.

Lateral movement

In these attacks, the attackers used several known methods to move laterally:

  • The attackers heavily abused WMI for executing tools on remote systems.

  • The attackers also used other techniques such as creating service or schedule task on remote systems.

  • In some cases, the attackers simply run commands on remote systems using PsExec.

Exchange Management Shell abuse

The Exchange Management Shell is the PowerShell interface for administrators to manage the Exchange server. As such, it exposes many critical Exchange PowerShell cmdlets to allow admins to perform various maintenance tasks, such as assigning roles and permissions, and migration, including importing and exporting mailboxes. These cmdlets are available only on Exchange servers in the Exchange Management Shell or through remote PowerShell connections to the Exchange server.

To understand suspicious invocation of the Exchange Management Shell, we need to go one step back in the process chain and analyze the responsible process. As mentioned, common application pools MSExchangeOWAAppPool or MSExchangeECPAppPool accessing the shell should be considered suspicious.

In our investigation, attackers leveraged these admin cmdlets to perform critical tasks such as exporting mailboxes or running arbitrary scripts. Attackers used different ways to load and run PowerShell cmdlets through the Exchange Management Shell.

In certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity.

These cmdlets allowed the attackers to perform the following:

  • Search received email

In our investigations, attackers were primarily interested in received emails. They searched for message delivery information filtered by the event ‘Received’. The search time frame showed the attackers were initially interested in the entire log history. Later, a similar command was run with a trimmed timeline of one year.

  • Export mailbox

Attackers exported mailboxes through these four steps:

    1. Granted ApplicationImpersnation role to the attacker-controlled account. This effectively allowed the supplied account to access all mailboxes in the organization.
    2. Granted ‘Mailbox Import Export’ role to the attacker-controlled account. This role is required to be added before attempting mailbox export.
    3. Exported the mailbox with filter “Received -gt ‘01/01/2020 0:00:00’”.
    4. Removed the mailbox export request to avoid raising suspicion.

Tampering with security tools

As part of lateral movement, the attackers attempted to disable Microsoft Defender Antivirus. Attackers also disabled archive scanning to bypass detection of tools and data compressed in .zip files, as well as created exclusion for .dat extension. The attackers tried to disable automatic updates to avoid any detection by new intelligence updates. For Microsoft Defender ATP customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Remote access

The next step for attackers was to create a network architecture using port forwarding tools like plink.exe, a command line connection tool like ssh. Using these tools allowed attackers to bypass network restrictions and remotely access machines through Remote Desktop Protocol (RDP). This is a very stealthy technique: attackers reused dumped credentials to access the machines through encrypted tunneling software, eliminating the need to deploy backdoors, which may have a high chance of getting detected.

Exfiltration

Finally, dumped data was compressed using the utility tool rar.exe. The compressed data mostly comprised of the extracted .pst files, along with memory dumps.

Improving defenses against Exchange server compromise

As these attacks show, Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive, fileless techniques. For example, at every stage in the attack chain above, the attackers abused existing tools (LOLBins) and scripts to accomplish various tasks. Even in cases where non-system binaries were introduced, they were either legitimate and signed, like plink.exe, or just a proxy for the malicious binary, for example, the modified Mimikatz where the actual malicious payload never touched the disk.

Keeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take to ensure they don’t fall victim to Exchange server compromise.

  1. Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations in Exchange servers. Deploy the latest security updates, especially for server components like Exchange, as soon as they become available. Specifically, check that the patches for CVE-2020-0688 is in place. Use threat and vulnerability management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

  1. Keep antivirus and other protections enabled

It’s critical to protect Exchange servers with antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and WMI. Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT pros to help determine the true impact of these settings. Security teams and IT pros should collaborate on applying mitigations and appropriate settings.

  1. Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

  1. Restrict access

Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and Enable MFA. Use tools like LAPS.

Place access control list (ACL) restrictions on ECP and other virtual directories in IIS. Don’t expose the ECP directory to the web if it isn’t necessary and to anyone in the company who doesn’t need to access it. Apply similar restrictions to other application pools.

  1. Prioritize alerts

Pay attention to and immediately investigate alerts indicating suspicious activities on Exchange servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Common application pools like ‘MSExchangeOWAAppPool’ or ‘MSExchangeECPAppPool’ are commonly hijacked by attackers through web shell deployment. Prioritize alerts related to processes such as net.exe, cmd.exe, and mshta.exe originating from these pools or w3wp.exe in general.

Behavior-based blocking and containment capabilities in Microsoft Defender Advanced Threat Protection stop many of the malicious activities we described in this blog. Behavior-based blocking and containment stops advanced attacks in their tracks by detecting and halting malicious processes and behaviors.

 

 

Figure 7. Microsoft Defender ATP alerts on blocked behaviors

In addition, Microsoft Defender ATP’s endpoint detection and response (EDR) sensors provide visibility into other suspicious and malicious activities on Exchange servers, which are raised as alerts. The new alert page presents data in an investigation-driven approach meant to empower SecOps teams to easily investigate and take actions.

Figure 8. Microsoft Defender ATP alert and process tree

If these alerts are immediately prioritized, security operations teams can better mitigate attacks and prevent further damage. Beyond resolving these alerts in the shortest possible time, however, organizations should focus on investigating the end-to-end attack chain and trace the vulnerability, misconfiguration, or other weakness in the infrastructure that allowed the attack to occur.

Microsoft Defender ATP is a component of the broader Microsoft Threat Protection (MTP), which provides comprehensive visibility into advanced attacks by combining the capabilities of Office 365 ATP, Azure ATP, Microsoft Cloud App Security, and Microsoft Defender ATP. Through the incidents view, MTP provides a consolidated picture of related attack evidence that shows the complete attack story, empowering SecOps teams to thoroughly investigate attacks.

In addition, MTP’s visibility into malicious artifacts and behavior empowers security operations teams to proactively hunt for threats on Exchange servers. For example, MTP can be connected to Azure Sentinel to enable web shell threat hunting.

Through built-in intelligence and automation, Microsoft Threat Protection coordinates protection, detection, and response across endpoints, identity, data, and apps. Learn more.

 

Hardik Suri

Microsoft Defender ATP Research Team

 

MITRE ATT&CK techniques

Initial access

Execution

Persistence

Privilege escalation

Defense evasion

Credential access

Discovery

Lateral movement

Collection

Command and control

Exfiltration

 

The post Defending Exchange servers under attack appeared first on Microsoft Security.

Ghost in the shell: Investigating web shell attacks

February 4th, 2020 No comments

Recently, an organization in the public sector discovered that one of their internet-facing servers was misconfigured and allowed attackers to upload a web shell, which let the adversaries gain a foothold for further compromise. The organization enlisted the services of Microsoft’s Detection and Response Team (DART) to conduct a full incident response and remediate the threat before it could cause further damage.

DART’s investigation showed that the attackers uploaded a web shell in multiple folders on the web server, leading to the subsequent compromise of service accounts and domain admin accounts. This allowed the attackers to perform reconnaissance using net.exe, scan for additional target systems using nbstat.exe, and eventually move laterally using PsExec.

The attackers installed additional web shells on other systems, as well as a DLL backdoor on an Outlook Web Access (OWA) server. To persist on the server, the backdoor implant registered itself as a service or as an Exchange transport agent, which allowed it to access and intercept all incoming and outgoing emails, exposing sensitive information. The backdoor also performed additional discovery activities as well as downloaded other malware payloads. In addition, the attackers sent special emails that the DLL backdoor interpreted as commands.

Figure 1. Sample web shell attack chain

The case is one of increasingly more common incidents of web shell attacks affecting multiple organizations in various sectors. A web shell is a piece of malicious code, often written in typical web development programming languages (e.g., ASP, PHP, JSP), that attackers implant on web servers to provide remote access and code execution to server functions. Web shells allow adversaries to execute commands and to steal data from a web server or use the server as launch pad for further attacks against the affected organization.

With the use of web shells in cyberattacks on the rise, Microsoft’s DART, the Microsoft Defender ATP Research Team, and the Microsoft Threat Intelligence Center (MSTIC) have been working together to investigate and closely monitor this threat.

Web shell attacks in the current threat landscape

Multiple threat actors, including ZINC, KRYPTON, and GALLIUM, have been observed utilizing web shells in their campaigns. To implant web shells, adversaries take advantage of security gaps in internet-facing web servers, typically vulnerabilities in web applications, for example CVE-2019-0604 or CVE-2019-16759.

In our investigations into these types of attacks, we have seen web shells within files that attempt to hide or blend in by using names commonly used for legitimate files in web servers, for example:

  • index.aspx
  • fonts.aspx
  • css.aspx
  • global.aspx
  • default.php
  • function.php
  • Fileuploader.php
  • help.js
  • write.jsp
  • 31.jsp

Among web shells used by threat actors, the China Chopper web shell is one of the most widely used. One example is written in JSP:

We have seen this malicious JSP code within a specially crafted file uploaded to web servers:

Figure 2. Specially crafted image file with malicious JSP code

Another China Chopper variant is written in PHP:

Meanwhile, the KRYPTON group uses a bespoke web shell written in C# within an ASP.NET page:

Figure 3. Web shell written in C# within an ASP.NET page

Once a web shell is successfully inserted into a web server, it can allow remote attackers to perform various tasks on the web server. Web shells can steal data, perpetrate watering hole attacks, and run other malicious commands for further compromise.

Web shell attacks have affected a wide range of industries. The organization in the public sector mentioned above represents one of the most common targeted sectors.

Aside from exploiting vulnerabilities in web applications or web servers, attackers take advantage of other weaknesses in internet-facing servers. These include the lack of the latest security updates, antivirus tools, network protection, proper security configuration, and informed security monitoring. Interestingly, we observed that attacks usually occur on weekends or during off-hours, when attacks are likely not immediately spotted and responded to.

Unfortunately, these gaps appear to be widespread, given that every month, Microsoft Defender Advanced Threat Protection (ATP) detects an average of 77,000 web shell and related artifacts on an average of 46,000 distinct machines.

Figure 3: Web shell encounters 

Detecting and mitigating web shell attacks

Because web shells are a multi-faceted threat, enterprises should build comprehensive defenses for multiple attack surfaces. Microsoft Threat Protection provides unified protection for identities, endpoints, email and data, apps, and infrastructure. Through signal-sharing across Microsoft services, customers can leverage Microsoft’s industry-leading optics and security technologies to combat web shells and other threats.

Gaining visibility into internet-facing servers is key to detecting and addressing the threat of web shells. The installation of web shells can be detected by monitoring web application directories for web script file writes. Applications such as Outlook Web Access (OWA) rarely change after they have been installed and script writes to these application directories should be treated as suspicious.

After installation, web shell activity can be detected by analyzing processes created by the Internet Information Services (IIS) process w3wp.exe. Sequences of processes that are associated with reconnaissance activity such as those identified in the alert screenshot (net.exe, ping.exe, systeminfo.exe, and hostname.exe) should be treated with suspicion. Web applications such as OWA run from well-defined Application Pools. Any cmd.exe process execution by w3wp.exe running from an application pool that doesn’t typically execute processes such as ‘MSExchangeOWAAppPool’ should be treated as unusual and regarded as potentially malicious.

Microsoft Defender ATP exposes these behaviors that indicate web shell installation and post-compromise activity by analyzing script file writes and process executions. When alerted of these activities, security operations teams can then use the rich capabilities in Microsoft Defender ATP to investigate and resolve web shell attacks.

Figure 4. Sample Microsoft Defender ATP alerts related to web shell attacks

Figure 5. Microsoft Defender ATP alert process tree

As in most security issues, prevention is critical. Organizations can harden systems against web shell attacks by taking these preventive steps:

  • Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Deploy latest security updates as soon as they become available.
  • Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
  • Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.
  • Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
  • Enable cloud-delivered protection to get the latest defenses against new and emerging threats.
  • Educate end users about preventing malware infections. Encourage end users to practice good credential hygiene—limit the use of accounts with local or domain admin privileges.

 

 

Detection and Response Team (DART)

Microsoft Defender ATP Research Team

Microsoft Threat Intelligence Center (MSTIC)

 

The post Ghost in the shell: Investigating web shell attacks appeared first on Microsoft Security.