Archive

Archive for the ‘living-off-the-land’ Category

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.

Latest Astaroth living-off-the-land attacks are even more invisible but not less observable

March 23rd, 2020 No comments

Following a short hiatus, Astaroth came back to life in early February sporting significant changes in its attack chain. Astaroth is an info-stealing malware that employs multiple fileless techniques and abuses various legitimate processes to attempt running undetected on compromised machines. The updated attack chain, which we started seeing in late 2019, maintains Astaroth’s complex, multi-component nature and continues its pattern of detection evasion.

Figure 1. Microsoft Defender ATP data showing revival of Astaroth campaigns

Heat map showing Astaroth encounters, with Brazil accounting for majority of encounters

Figure 2. Geographic distribution of Astaroth campaigns this year, with majority of encounters recorded in Brazil

When we first blogged about Astaroth’s methods, we noted how it completely lived off the land to avoid detection: only system tools that are already existing on the machine are ever executed. In fact, it was an unusual spike in activities related to Windows Management Instrumentation Command-line (WMIC) that prompted our investigation and eventually exposed the Astaroth campaign.

Astaroth now completely avoids the use of WMIC and related techniques to bypass existing detections. Instead, the attackers introduced new techniques that make the attack chain even stealthier:

  • Abusing Alternate Data Streams (ADS) to hide malicious payloads
  • Abusing the legitimate process ExtExport.exe, a highly uncommon attack vector, to load the payload

Astaroth exemplifies how living-off-the-land techniques have become standard components of today’s attacks intent on evading security solutions. However, as we mentioned in our previous blog on Astaroth, fileless threats are very much observable. These threats still leave a great deal of memory footprint that can be inspected and blocked as they happen. Next-generation protection and behavioral containment and blocking capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) lead the charge in exposing threats like Astaroth.

In this blog, we’ll share our technical analysis of the revamped Astaroth attack chain and demonstrate how specific Microsoft technologies tackle the multiple advanced components of the attack.

Dismantling the new Astaroth attack chain

The attackers were careful to ensure the updates didn’t make Astaroth easier to detect; on the contrary, the updates only make Astaroth’s activities even more invisible.

One of the most significant updates is the use of Alternate Data Stream (ADS), which Astaroth abuses at several stages to perform various activities. ADS is a file attribute that allows a user to attach data to an existing file. The stream data and its size are not visible in File Explorer, so attacks abuse this feature to hide malicious code in plain sight.

Astaroth 2020 attack chain

Figure 2. Astaroth attack chain 2020

In the case of Astaroth, attackers hide binary data inside the ADS of the file desktop.ini, without changing the file size. By doing this, the attackers create a haven for the payloads, which are read and decrypted on the fly.

Screenshot comparing contents of desktop.ini before and after infection

Figure 3. Desktop.ini before and after infection

The complex attack chain, which involves the use of multiple living-off-the-land binaries (LOLBins), results in the eventual loading of the Astaroth malware directly in memory. When running, Astaroth decrypts plugins that allow it to steal sensitive information, like email passwords and browser passwords.

In the succeeding sections, we describe each step of Astaroth’s attack chain in detail.

Arrival

The attack begins with an email with a message in Portuguese that translates to: “Please find in the link below the STATEMENT #56704/2019 AND LEGAL DECISION, for due purposes”. The email contains a link that points to URL hosting an archive file, Arquivo_PDF_<date>.zip, which contains a LNK file with a similarly misleading name. When clicked, the LNK file runs an obfuscated BAT command line.

Email used in Astaroth campaign

Figure 4. Sample email used in latest Astaroth attacks

The BAT command drops a single-line JavaScript file to the Pictures folder and invokes explorer.exe to run the JavaScript file.

Malware code showing GetObject technique

The dropped one-liner script uses the GetObject technique to fetch and run the much larger main JavaScript directly in memory:

Malware code showing BITSAdmin abuse

BITSAdmin abuse

The main script then invokes multiple instances of BITSAdmin using a benign looking command-line to download multiple binary blobs from a command-and-control (C2) server:

Malware code showing downloaded content showing ADS

The downloaded payloads are encrypted and have the following file names:

  • masihaddajjaldwwn.gif
  • masihaddajjalc.jpg
  • masihaddajjala.jpg
  • masihaddajjalb.jpg
  • masihaddajjaldx.gif
  • masihaddajjalg.gif
  • masihaddajjalgx.gif
  • masihaddajjali.gif
  • masihaddajjalxa.~
  • masihaddajjalxb.~
  • masihaddajjalxc.~
  • masihaddajjal64w.dll
  • masihaddajjal64q.dll
  • masihaddajjal64e.dll

Alternate Data Streams abuse

As mentioned, the new Astaroth attacks use a clever technique of copying downloaded data to the ADS of desktop.ini. For each download, the content is copied to the ADS, and then the original content is deleted. These steps are repeated for all downloaded payloads.

Malware code showing abuse of ADS to run script to find security products

Another way that Astaroth abuses ADS is when it runs a script to find installed security products. A malicious script responsible for enumerating security products is dropped and then copied as an ADS to an empty text file. The execution command-line looks like this:

ExtExport.exe abuse

The main script combines three separately downloaded binary blobs to form the first-stage malware code:

Malware code showing three blobs forming first-stage malware code

The script then uses a LOLBin not previously seen in Astaroth attacks to load the first-stage malware code: ExtExport.exe, which is a legitimate utility shipped as part of Internet Explorer. Attackers can load any DLL by passing an attacker-controlled path to the tool. The tool searches for any DLL with the following file names: mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll. Attackers need only to rename the malicious payload to one of these names, and it is loaded by ExtExport.exe.

Malware code showing ExtExport.exe abuse

Userinit.exe abuse

The newly loaded DLL (mozcrt19.dll, mozsqlite3.dll, or sqlite3.dll) is a proxy that reads three binary ADS streams (desktop.ini:masihaddajjalxa.~, desktop.ini:masihaddajjalxb.~, and desktop.ini:masihaddajjalxc.~) and combines these into a DLL. The newly formed DLL is the second-stage malware code and is loaded in the same process using the reflective DLL loading technique.

The newly loaded DLL is also a proxy that reads and decrypts another ADS stream (desktop.ini:masihaddajjalgx.gif) into a DLL. This DLL is injected into userinit.exe using the process hollowing technique.

The newly loaded DLL inside userinit.exe is again a proxy that reads and decrypts another ADS stream (desktop.ini:masihaddajjalg.gif) into a DLL. This DLL is the malicious info-stealer known as Astaroth and is reflectively loaded inside userinit.exe. Hence, Astaroth never touches the disk and is loaded directly in memory, making it very evasive.

Astaroth payload

When running, the Astaroth payload then reads and decrypts more components from the ADS stream of desktop.ini (desktop.ini:masihaddajjaldwwn.gif, desktop.ini:masihaddajjalc.jpg, desktop.ini:masihaddajjala.jpg, desktop.ini:masihaddajjalb.jpg, and desktop.ini:masihaddajjali.gif).

Some of these components are credential-stealing plugins hidden inside the ADS stream of desktop.ini. Astaroth abuses these plugins to steal information from compromised systems:

  • NirSoft’s MailPassView – an email client password recovery tool
  • NirSoft’s WebBrowserPassView – a web browser password recovery tool

As mentioned, Astaroth also finds installed security products. It then attempts to disable these security products. For Microsoft Defender Antivirus customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Comprehensive, dynamic protection against living-off-the-land, fileless, and other sophisticated threats with Microsoft Threat Protection

Attackers are increasingly turning to living-off-the-land techniques to attempt running undetected for as long as possible on systems. Because these attacks use multiple executables that are native to the system and have legitimate uses, they require a comprehensive, behavior-based approach to detection.

Microsoft Threat Protection combines and orchestrates into a single solution the capabilities of multiple Microsoft security services to coordinate protection, detection, response, and prevention across endpoints, email, identities, and apps.

In the case of Astaroth, Office 365 ATP detects the malware delivery via email. Using detonation-based heuristics and machine learning, Office 365 ATP inspects links and attachments to identify malicious artifacts.

On endpoints, next-generation protection capabilities in Microsoft Defender ATP detect and prevent some components of Astaroth’s new attack chain. Notably, through Antimalware Scan Interface (AMSI), Microsoft Defender ATP can inspect the encrypted malicious scripts used in the initial stages of the attack.

For the more sophisticated sections of the attack chain, behavioral blocking and containment capabilities provide dynamic protection that can stop malicious behaviors and process trees. Behavior-based protections are key to exposing living-off-the-land threats that abuse and hide behind legitimate processes. These protections identify suspicious behavior sequences and advanced attack techniques observed on the client, which are used as triggers to analyze the process tree using real-time machine learning models in the cloud.

Diagram showing preventive and behavior-based blocking & containment solutions against Astaroth

Figure 5. Preventive and behavior-based blocking & containment protections against Astaroth

These behavior-based detections raise alerts in Microsoft Defender Security Center. With behavioral blocking and containment, not only are evasive threats exposed, detected, and stopped; security operations personnel are also notified so they can thoroughly investigate and remediate the root cause.

Figure 6. Sample Microsoft Defender ATP alerts on behavior-based detections of Astaroth’s activities

Microsoft Defender ATP’s EDR capabilities also have very strong coverage of advanced techniques employed by Astaroth, including cross-process migration, code injection, and use of LOLBins.

Figure 7. Sample Microsoft Defender ATP EDR alert and process tree on Astaroth’s behaviors

We expect Astaroth to further develop and increase in complexity, as long-running malware campaigns do. We will continue to watch this evolving threat and ensure that customers are protected from future updates through durable behavior-based protections.

 

 

Hardik Suri

Microsoft Defender ATP Research Team

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

The post Latest Astaroth living-off-the-land attacks are even more invisible but not less observable appeared first on Microsoft Security.

Multi-stage downloader Trojan sLoad abuses BITS almost exclusively for malicious activities

December 12th, 2019 No comments

Many of today’s threats evolve to incorporate as many living-off-the-land techniques as possible into the attack chain. The PowerShell-based downloader Trojan known as sLoad, however, puts all its bets on BITS.

Background Intelligent Transfer Service (BITS) is a component of the Windows operating system that provides an ability to transfer files in an asynchronous and throttled fashion using idle bandwidth. Abusing BITS, which provides the ability to create self-contained jobs that can be prioritized and queued up and that can launch other programs, has become a prevalent attack technique. Recent sophisticated malware campaigns like Astaroth have found success in the use of BITS for downloading payloads or additional components, especially in systems where the firewall is not configured to block malicious traffic from BITS jobs.

sLoad, detected by Windows Defender Antivirus as TrojanDownloader:PowerShell/sLoad, is used by adversaries for exfiltrating system information and delivering additional payloads in targeted attacks. It has been around for a few years and has not stopped evolving. What hasn’t changed, though, is its use of BITS for all of its exfiltration activities, as well as command-and-control (C2) communications from handshake to downloading additional payloads.

Once sLoad has infiltrated a machine, it can allow attackers to do further, potentially more damaging actions. Using exfiltrated information, attackers can identify what security solutions are running and test payloads before they are sneaked into the compromised system or, worse, high-priced targets. sLoad uses scheduled tasks, which runs the malware every three minutes, opening the window of opportunity for further compromise—hence raising the risk for the affected machine—every time it runs. We have already seen the malware attempt to deliver several other, potentially more dangerous Trojans to compromised machines.

While several malware campaigns have leveraged BITS, sLoad’s almost exclusive use of the service is notable. sLoad uses BITS as an alternative protocol to perform data exfiltration and most of its other malicious activities, enabling the malware to evade defenders and protections that may not be inspecting this unconventional protocol. Cloud-based machine learning-driven behavioral blocking and containment capabilities in Microsoft Defender Advanced Threat Protection detect and block sLoad’s activities as Behavior:Win32/sLoad.A.

In this blog we’ll share our analysis of the multiple ways in which sLoad is abusing BITS and share how Microsoft Defender Advanced Threat Protection defeats these advanced malware techniques.

Stealthy installation via multiple cascaded scripts

sLoad is known to infect machines using spear-phishing emails and a common but effective detection evasion technique: the cascaded scripts. One script drops or downloads one or more scripts, passes control to one of these scripts, and repeats the process multiple times until the final component is installed.

Over time, we’ve seen some variations of this technique. One sLoad campaign used the link target field of a LNK file to run PowerShell commands that extracts and runs the first-stage PowerShell code, which is appended to the end of the LNK file or, in one instance, the end of the ZIP file that originally contained the LNK file. In another campaign, the first-stage PowerShell code itself uses a download BITS job to download either the sLoad script and the C2 URL file or the sLoad dropper PowerShell script that embeds the encrypted sLoad script and C2 URL file within itself.

In the most recent attacks, for the first stage, sLoad shifted from using PowerShell script to VBScript. The randomly named VBScript file is simply a proxy that builds and then drops and runs a PowerShell script, always named rr.ps1. This is none other than the same sLoad PowerShell dropper mentioned earlier that embeds the encrypted sLoad script and C2 URL file within itself.

In most variations of the installation, the sLoad dropper script is the last intermediate stage that performs the following actions, and eventually decrypts and runs the final sLoad script:

  1. Creates an installation folder in the %APPDATA% folder named after the first 6 characters of the Win32 Product UUID. 
  2. Drops an infection marker file named _in, and during the successive executions, uses the LastWriteTime on this file to check whether the malware is installed within last 30 mins, in which case, it terminates. 
  3. Drops the encrypted sLoad script and the C2 URL file as config.ini and web.ini, respectively. 
  4. Builds and drops two more randomly named scripts: one VBScript and one PowerShell script. 
  5. Uses schtasks.exe to create a scheduled task named AppRunLog to run the randomly named VBScript from the previous step with decryption key supplied as a command line parameter; deletes the previously created related tasks (if found) before creating this one. The scheduled task is configured to start at 7:00 AM and run every 3 mins. 

The dropped VBScript that runs under the scheduled task is yet another proxy that simply runs the dropped PowerShell script with the same command line parameter (the decryption key). The PowerShell script decrypts the contents of the previously dropped config.ini in the memory into another piece of PowerShell code, which it then runs. This is the final component, the script detected as TrojanDownloader:PowerShell/sLoad, that uses BITS to perform every important malicious activity.

BITS abuse

The sLoad PowerShell script (the final component) then abuses BITS to carry out all of the following activities:

Finding an active C2 server

The malware decrypts the contents of previously dropped web.ini into a set of 2 URLs and creates a BITS download jobs to test the connection to these URLs. It then saves the URL that responds in the form of a file that contains a message “sok”, being downloaded as part of created BITS job. This ensures that the handshake is complete.

If none responds, the script appends the number “1” to the domain names in both URLs, saves the encrypted data back to the web.ini file, and exits from the script. As a result, the next time the scheduled job runs, the script uses the modified web.ini to obtain the modified URLs to attempt connecting to an active C2. With each unsuccessful attempt of connecting with C2s, the number appended to the domain names is increased by increments of 1 until it reaches 50, at which time it resets to 1. This technique offers a bit of a cushion and ensures continued contact between a compromised machine and a C2, in case the primary C2 is blocked.

This prevents the malware infrastructure from losing a compromised host if the primary C2 is blocked. It’s also interesting to see how the URLs used to reach C2 are structured to appear related to CAPTCHA verification, an attempt to escape watchful eyes.

Fetching a new list of C2s

For continued exfiltration of information, it’s important to maintain contact with an active C2. As the malicious domains cannot stay up running for a long time, the malware packs a functionality to refresh the list of C2 every time the scheduled task runs. Using a BITS download job, the malware downloads a new copy of web.ini from the active C2 to provisions a new set of C2s for future use.

Exfiltrating system information

Once an active C2 is identified, the malware starts collecting system information by performing the following:

  • saves the output of “net view” command
  • enumerates network drives and saves the provider names and device ids
  • produces the list of all running processes
  • obtains the OS caption
  • looks for Outlook folder, as well as Independent Computing Architecture (ICA) files, which are used by Citrix application servers to store configuration information

It then creates a BITS download job with the RemoteURL built using the URL for active C2 and the system information collected up this point.

Crafting URLs infused with stolen info is not a novel attacker technique. In addition, creating a BITS job with an extremely large RemoteURL parameter that includes non-encrypted system information stands out and is relatively easy to detect. However, this malware’s use of a download job instead of an upload job is a clever move to achieve stealth.

Deploying additional payloads

Because the malware exfiltrates system information using a BITS download job, it gets an opportunity to receive a response in the form of a file downloaded to the machine. It uses this opportunity to obtain additional payloads from the C2.

It sleeps and waits for the file to be downloaded. If the downloaded file instructs to download and invoke additional PowerShell codes, the supplied URL is used for the task. If not, then the URL is assumed to be pointing to an encoded PE image payload. The malware creates another BITS download job to download this payload, creates a copy of this newly downloaded encoded file, and uses another Windows utility, certutil.exe, to decode it into a portable executable (PE) file with .exe extension. Finally, it uses PowerShell.exe to run the decoded PE payload. One more BITS download job is created to download additional files.

Spying

The malware comes built with one of the most notorious spyware features: uploading screenshots. At several stages during the installation as well as when running additional payloads, the malware takes several screenshots at short intervals. It then uses a BITS upload job to send the stolen screenshots to the active C2. This is the only time that it uses an upload job, and these are the only files it uploads to the C2. Once uploaded, the screenshots are deleted from the machine.

Conclusion: Multiple layers of protection against multi-stage living-off-the-land threats

sLoad is just one example of the increasingly more prevalent threats that can perform most of their malicious activities by simply living off the land. In this case, it’s a dangerous threat that’s equipped with notorious spyware capabilities, infiltrative payload delivery, and data exfiltration capabilities. sLoad’s behavior can be classified as a Type III fileless technique: while it drops some malware files during installation, its use of only BITS jobs to perform most of its harmful behaviors and scheduled tasks for persistence achieves an almost fileless presence on compromised machines.

To defeat multi-stage, stealthy, and persistent threats like sLoad, Microsoft Defender ATP’s antivirus component uses multiple next-generation protection engines on the client and in the cloud. While most threats are identified and stopped by many of these engines, behavioral blocking and containment capabilities detects malicious behaviors and blocks threats after they have started running:

These detections are also surfaced in Microsoft Defender Security Center. Security operations teams can then use Microsoft Defender ATP’s other capabilities like endpoint detection and response (EDR), automated investigation and response, Threat and Vulnerability Management, and Microsoft Threat Experts to investigate and respond to attacks. This reflects the defense-in-depth strategy that is central to the unified endpoint protection provided by Microsoft Defender ATP.

As part of Microsoft Threat Protection, Microsoft Defender ATP shares security signals about this threat to other security services, which likewise inform and enrich endpoint protection. For example, Office 365 ATP’s intelligence on the emails that carry sLoad is shared to and used by Microsoft Defender ATP to build even stronger defenses at the source of infection. Real-time signal-sharing across Microsoft’s security services gives Microsoft Threat Protection unparalleled visibility across attack vectors and the unique ability to provide comprehensive protection against identities, endpoints, data, cloud apps, and infrastructure.

 

Sujit Magar
Microsoft Defender ATP Research Team

 

 


Talk to us

Questions, concerns, or insights on this story? Join discussions at the Microsoft Defender ATP community.

Read all Microsoft security intelligence blog posts.

Follow us on Twitter @MsftSecIntel.

 

The post Multi-stage downloader Trojan sLoad abuses BITS almost exclusively for malicious activities appeared first on Microsoft Security.