Incident response case study featuring Ryuk and Trickbot (part 1)

Ransomware János Pallagi todayApril 29, 2019 210

share close

Incident – Ryuk

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:

  • as of the time of writing this post, no known decryption is available for Ryuk (probably never will);
  • the attackers behind Ryuk are often operating the malware manually after gaining access to a network;
  • Ryuk is run almost exclusively on servers, where sensitive data are stored – so workstations are not affected.

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.

Root cause – Trickbot

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.

Finding patient zero

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.

Trickbot analysis

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.

  •  appinfoDll64.dll

Lists user profiles and scheduled tasks as part of basic information gathering. 

  • injectDll64.dll

Responsible for harvesting bank account and credit card credentials by injecting it into browsers

  •  mailsearcher64.dll
  •  networkDll64.dll

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

  •  NewBCtestnDll64.dll

BackConnect SOCKS5 proxy.

  •  psfin64.dll

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

  • pwgrab64.dll

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;.

  •  shareDll64.dll

Propagation via C$ and ADMIN$ shares, tries to register Trickbot as a service on a remote machine. Used together with wormDll64.dll.

  •  systeminfo64.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.

  •  tabDll64.dll

“Borrowed” Reflective DLL Injection module, remote service installing capabilities.

  •  totinjectDll64.dll

Similar to injectDll64.dll.

  •  wormDll64.dll

Lateral movement module, SMB, LDAP, IPC connections supported.

  •  wormwinDll64.dll

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…

Written by: János Pallagi

Tagged as: , , .

Rate it
Previous post

Similar posts