In this post, we provide details of the SLUB backdoor, how it uses SaaS apps including Slack as a command and control channel, and how CASB controls can prevent this and similar threats from affecting the enterprise. For traditional firewalls and even for next-gen firewalls and intrusion detection/prevention systems, attacks like these are extremely insidious since they leverage allow listed services in a malicious way. Many enterprises use Slack day-to-day, and so an attack using a “known good” service may go undetected.
What is SLUB?
SLUB (SLack and GitHUB) is a backdoor, discovered and reported on by Cedric Pernet, Daniel Lunghi, Jaromir Horejsi, and Joseph C. Chen at Trend Micro. The malware was spread via a watering hole attack which exploited CVE-2018-8174. A downloader then retrieved the SLUB backdoor and executed it by exploiting CVE-2015-1701, a vulnerability in the Windows operating system which provided SYSTEM-level privileges. Trend concluded that this was likely the work of an advanced persistent threat actor due to the sophistication of both the attack vector and the malware.
The malware is notable for its ability to evade traditional network intrusion detection systems by leveraging common SaaS applications such as Slack, Github, and File.io.
What are its capabilities?
The SLUB backdoor maintains persistence by setting a registry key named “Microsoft Setup Initializazion” (yes, the spelling of initialization is incorrect in the file) in SOFTWARE\Microsoft\Windows\CurrentVersion\Run, naming itself “Windows-RT-KB2937636.dll”. It uses the rundll32 application to execute the main program logic, which is contained in the “UpdateMPUnits” function.
The malware has a suite of functions that are run based on the contents of a GitHub gist which it retrieves through use of the statically-linked Curl library. It then uses the Boost library (also statically linked) to parse the commands from the Github gist.
When the malware “wakes up”, it will make its initial call out to an attacker-controlled Slack workspace with the victim’s computer name and username. This same Slack workspace is used for posting the responses and results of every command received via the Github gist, using Curl and the statically-linked JsonCpp library. This is a critical channel for the attacker since it gives them a pulse on the infected machines, allowing them to keep inventory, have an idea of whether or not their commands are successful, and when querying for information, Slack is the lifeline which provides it back to them.
File uploads also rely on the curl library and are sent to an attacker-controlled bucket on file.io.
Figure 1 – disassembly showing Slack token.
exec – Execute instruction
Leverages cmd.exe to run instructions on the target system. It will write a log file of the format “%ws\%u_cmd_out.tmp” during execution where output is written, as well as a similarly named .dat file in some cases. The files are deleted at the end of the command execution and a message indicating success or failure is posted to the attacker’s Slack workspace.
dnexec – Download and execute
Here, a file is downloaded and executed using CreateProcessW. If the process fails to run or once the thread has completed execution, the file is deleted and a message is posted to the attacker’s Slack workspace.
update – Download a file, run it, and delete the old file
This functionality “updates” a file, by downloading a new attacker-specified file, deleting the old version, and running the new file. A message indicating completion or failure is posted to the attacker’s Slack workspace.
destroy – Cover your tracks
When SLUB receives the destroy command, it will move to cover its tracks. Through a series of commands, it will remove any trace of itself from the user’s system, deleting the registry key and the dll that serves as the main program logic. When initiated, a message is posted in the Slack workspace identifying the machine and user which will have the malware deleted.
file – Exfiltrate files
This is the main use of File.io and one of the noteworthy uses of Slack in the SLUB backdoor. The files are uploaded to File.io via Curl and the REST API. In an effort to evade traditional IDS/IPS, SLUB uses Curl to interact with the Slack “postMessages” API and an embedded token to conduct file operations, sending the file link to one of a number of channels (“dailynews” and “fallback” are two of the embedded channel names) in the same attacker-controlled workspace.
capture – Screen capture
The Capture feature of the SLUB backdoor will capture an image of the current screen or of the active window. The screenshot is uploaded to file.io and a link to the file is posted in the Slack workspace.
dir – Directory operations
Directory operations creates, moves, and deletes specified directories from the victim system. Upon completion or failure, the directory name and status are posted to the attacker’s Slack workspace.
proc – Process operations
The process operations suite of commands allows for the listing and termination of Processes. For listing, the list of processes along with the victim’s computer name are posted to the attacker’s Slack workspace. For termination, the success or failure is posted to the attacker’s Slack workspace.
drive – Drive operations
Collects information about the victim’s drive including listing files, collecting sevice ID, aerial number, free space, total size, volume name, journal info, drive type, whether or not encryption is used, and extended attributes. All of this information, along with the victim’s computer name are posted to Slack upon successful completion of the operation.
reg – Registry operations
Interestingly – SLUB features several registry operations. This is notable since many times, malware either does not include this functionality, or it is not explicitly available as a command, since it could be accessed through something like the exec command. In this case, the malware authors very specifically implemented methods to interact with the registry. The reg command set maps out the registry and provides attackers the option to query, modify, read, and write arbitrary registry entries. Success or failure status are posted to the attacker’s Slack workspace.
tmout – Sleep
Tmout will put the malware to sleep for some attacker-provided number of seconds.
Conclusiones
As Trend Micro noted in their reporting on this same malware, the use of multiple cloud services by a single piece of malware is unique, but based on the cloud use cases that we at Netskope are familiar with, we expect this trend to grow, particularly since traditional, non-CASB methods used for defending networks are ineffective against these attacks. So far, we have not seen any SLUB samples other than the one that was investigated by Trend Micro, and continue to monitor our telemetry for similar command and control vectors.
As attackers evolve, they will continue to find new ways to evade the detections that their would-be victims put in place. Detecting these evasions will prove difficult for traditional network-based methods and will instead require application-layer detections and use of machine learning techniques to prevent. Netskope can mitigate the use of Slack as a command and control channel via our CASB solution which detects connections to unsanctioned workspaces. Our machine learning and anomaly detection system can also flag unusual use of SaaS services. Abuse of SaaS applications in this way will continue to be of interest to the Netskope Threat Research Labs. As we find new or similar samples, we will report them here on the Netskope blog.
General Recommendations
- Always keep browsers fully patched and up-to-date. Watering hole attacks are notoriously difficult to mitigate, especially for unpatched or out-of-date browsers.
- Detect and remediate cloud threats using a threat-aware CASB solution like Netskope and enforce policy on usage of unsanctioned services as well as unsanctioned instances of sanctioned cloud services
Netskope Detection
If a connection to an unauthorized Slack workspace is attempted by the malware, Netskope can alert you or block the connection entirely through the use of the inline CASB connector. If the session is blocked or an alert is generated, information about the attempt will be found in the SkopeIT application events.
Figure 2 SkopeIT event
