Why are there more and more cyber attacks on software development environments and how is software company security becoming a key issue in the supply chain?
We have recently been contacted by a company in the CE region to do incident response for them. Like with many incidents in the past couple of years, the detection was obvious – the whole IT infrastructure shut down within minutes and ransom notes appeared on the screens of servers. In order to avoid reinfections (or continuous presence), we were involved as the team responsible for adversary removal.
Some of the backups were fortunately not affected, so the IT team had immediately begun to restore from the backups available. Restoring without investigating, however, is a double-edged sword when it comes to evidence collection. On the one hand you – as an organization – are stripped from all evidence between the times of the restore and the latest backup, but on the other hand business continuity is top priority in most cases.
The .RYK extension and the ransom note immediately gave away that we were dealing with Ryuk ransomware. Unfortunately that instantly tells us three things:
Most likely the attackers still had access to the network either by having valid credentials to some of the domain administrator accounts or by having at least one functioning backdoor, even when the restoring and reinstalling were under way.
We had limited access to evidence as most of the servers had been reinstalled from scratch by the time we were contacted. We managed to collect evidence from a machine that had been infected with Ryuk, but that did not really help us find the initial infection.
At that point the adversaries could have eagerly been waiting on some compromised workstations, having sufficient credentials to reinfect the whole network as soon as the team finished restoring. In the meantime, we picked up some interesting network connections from a few restored servers. Locating the machines and the suspicious processes quickly showed us the culprit: Trickbot executables injected into svchost.exe processes. So, does this mean that the full backups had already been infected with Trickbot and were restored, you ask? Yes.
There are several Threat Intelligence reports and articles linking Ryuk with Trickbot. We also observed this tag team of malware in this case; the initial infection of Trickbot has led to a ransomware attack, likely by selling/giving enterprise network access to the Ryuk operators, which is also known as Access-as-a-service.
While separating subnetworks, changing credentials, containing malware and removing them from servers, we also started looking for patient zero. But finding evidence of initial compromise on an organization level is quite tedious if the endpoint event logs and network logs are not collected and stored in a central location (or in a SIEM system). So, we started working backwards and tried to roll back events of code execution and lateral movement.
This is where the restored servers proved to be useful for us. Based on Event log and Registry entries and filesystem timestamps of Trickbot executables, modules and configs, we marked the date of these servers’ first Trickbot compromise. This timestamp is approximately nine months older than the Ryuk infection. So we were dealing with a network that had been fully compromised for almost a year, Trickbot running on servers with domain administrator credentials at its disposal. The next step was to look for propagation, because the most realistic scenario in case of Trickbot was that it had infected a workstation first via malspam, then jumped to other machines in the network through credential harvesting.
Patient zero turned out to be a workstation indeed. We identified an affected machine and the corresponding domain user based on (locally stored) nine-month-old Event log residues on one of the restored servers. Collection of evidence from that specific endpoint verified our findings, Events indicated execution of malicious scripts a day before the servers’ Trickbot infection. Logs of an antivirus software running on endpoints (which remains unnamed in this post on purpose) also showed the detection and removal of said Trickbot executable months after the initial compromise. We can, however, state that this endpoint protection software was not Windows Defender, because the Trickbot dropper disables Windows Defender as its first act on the compromised system. We also found several persistence mechanisms on the system belonging to the removed executable and identified the email message with the malicious document attached that dropped Trickbot. To make things worse, this domain user frequently used RDP to connect to one of the servers, on which they were in the Local administrators group, giving Trickbot a great chance to move laterally.
Back in 2016, Trickbot started its career as the new banking trojan on the block. Gradually it evolved into the full-featured, modular, multi-purpose malware that is Trickbot today. The distribution method is still malspam, attachments weaponized with malicious macros or prevailing 1-day exploits (DDE, MS17-010, CVE-2017-11882, etc.), but the development and pushing of new versions have become almost too fast for the security industry to keep up.
Not long ago, 17th April 2019, Trickbot had its 400th version observed in the wild. The version tag is in every Trickbot config and often corresponds to a certain spam campaign.
Although Trickbot’s persistence methods are still trivial (Startup, Run registry key, Scheduled task or service), in many cases it is still enough for it to maintain presence on systems for months without detection. The injection mechanism it uses, however, is the more advanced ReflectiveDLLInjection. Trickbot uses this technique multiple times: shortly after starting, Trickbot injects itself into an svchost.exe process and later, while running, dynamilcally loads necessary modules, in both cases via reflective injection. The modularity of Trickbot means each module has its own config. Both config files and the modules themselves are stored on the disk, encrypted and a second layer of obfuscation added above it. For communication, Trickbot instances use POST requests over https, according to our observations the most often used ports are 443 and 9001.
Each functionality is coded into a separate .dll module. A Trickbot module has four export functions: Control, FreeBuffer, Release, Start. A common technique used by malware authors is to find a benign ‘host’ application to add further noise to the real functionality in order to thwart automatic sandbox analysis or to delay analysts’ work. We observed this technique used in multiple Trickbot and Trickbot module samples.
Lists user profiles and scheduled tasks as part of basic information gathering.
Responsible for harvesting bank account and credit card credentials by injecting it into browsers
Enumerates network related information from the target system. Runs commands like: cmd.exe /c ipconfig /all cmd.exe /c net config workstation cmd.exe /c net view /all cmd.exe /c net view /all /domain cmd.exe /c nltest /domain_trusts cmd.exe /c nltest /domain_trusts /all_trusts Also gathers Active Directory related data and systeminfo from wmi via: SELECT * FROM Win32_OperatingSystem
BackConnect SOCKS5 proxy.
Point Of Sale module with interesting strings such as: POS found, REG found,CASH found, LANE found, STORE found,*RETAIL*, RETAIL found, BOH found, ALOHA found, *MICROS*,MICROS found, TERM found
Password grabber module for browsers (IE, Firefox, Chrome), protocols (RDP, VNC) and some other software (i.e. Outlook, FileZilla, WinSCP, PuTTY). Querying browser sqlite databases with: select origin_url, username_value, password_value, length(password_value) from logins where blacklisted_by_user = 0;.
Propagation via C$ and ADMIN$ shares, tries to register Trickbot as a service on a remote machine. Used together with wormDll64.dll.
Gets system information by running wmi quieries: SELECT * FROM Win32_OperatingSystem SELECT * FROM Win32_Processor SELECT * FROM Win32_ComputerSystem Also enumerates services on the system.
“Borrowed” Reflective DLL Injection module, remote service installing capabilities.
Similar to injectDll64.dll.
Lateral movement module, SMB, LDAP, IPC connections supported.
Similar to wormDll64.dll.
Authors of Trickbot have gradually expanded Trickbot’s capabilities, shifting its purpose from an advanced banking trojan to an all-around malware. Instead of targeting standalone users and machines, they focus on credential harvesting and lateral movement, and offer access-as-a-service to those who see more value to the compromised host, e.g. operators of targeted ransomware (Ryuk, LockerGoga, SamSam).
From the defensive standpoint, detecting Trickbot in your environment should not be the hardest task, as it tends to be very noisy both on network and host sides. On the flip side, the faster development and deploy cycle Trickbot applies, the harder the system administrators’ and blue teams’ tasks are in order to protect their network against these non-targeted attacks.
White Hat’s Incident Response Team had a versatile task after the ransomware attack at our client that consisted of ensuring business continuity, adversary removal on multiple hosts and finding the initial compromise in order to minimize the chance of reinfection. Furthermore, based on our experience and findings during the incident response process, we also gave advice on hardening the security infrastructure.
Stay tuned, part 2 of our analysis is coming soon…
Hands-on and practical, immediately usable knowledge integrated into academic education – our course at Óbuda University launches February 2019. Are you a BSc or MSc student of Computer Engineering or ...
