Multi-stage downloader Trojan sLoad abuses BITS almost exclusively for malicious activities
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:
- Creates an installation folder in the %APPDATA% folder named after the first 6 characters of the Win32 Product UUID.
- 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.
- Drops the encrypted sLoad script and the C2 URL file as config.ini and web.ini, respectively.
- Builds and drops two more randomly named scripts: one VBScript and one PowerShell script.
- 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.
READ MORE HERE
