Ransomware ate my network (IV)

A brief explanation of this series with some clarifying notes can be read at the beginning of the first part.
Series entries: First part, Second part, Third part, Fourth part, Fifth part

[Editor’s note: Clicking on many images – those whose detail is not fully visible with the size of the main page – shows an enlarged version]


In the previous article we saw how Angela had deduced that the attackers had entered the computer used to connect to the DC from another computer using the PsExec tool. Determined to find the PsExec, Angela begins by converting the MFT extracted by CyLR with mftdump.exe to .csv, and searching for activity around the time she saw the connection on the other computer (about 2:16 p.m. 1:16 p.m. in UTC which is what the MFT shows us).

There is no clear target, but that stalin.exe Prefetch looks suspicious (remember that Prefetches are created the first time the software is run, with a delay of a few seconds).

If we look for stalin.exe in the Sysmon logs, we find that, even PsExec wearing a mustache and drinks vodka, it cannot fool him:

Here we can see how launcher.bat is launched on W10-PC3 running the Empire stager. There are several additional details that are very interesting:

  • The parent of that PsExec is dosdivanya_security.bat (script to check with love).
  • It has been executed as SYSTEM (that is, it has system privileges).
  • The password for the admin account (local administrator) is (sigh)… Fiesta2020.
  • Both PsExec and dosdivanya_security.bat are in the Documents folder of the user dolores.jolgorio.

If we check the Sysmon logs, we see that the parent of dosdivanya_security.bat is… an encrypted Powershell script. It is clear that the attackers have assembled an “empire” of Empire agents on MINAF computers. Angela decides to review the contents of dolores.jolgorio’s Documents folder, and finds that the attackers have left behind an arsenal of tools:

We can already find old acquaintances (launcher.bat, plink.exe, launch_plink.bat, stalin.exe). Adfind.exe is an Active Directory reconnaissance tool (part of Ryuk’s TTPs), and gonchaya.exe has an icon that Angela immediately recognizes as that of BloodHound (another Active Directory reconnaissance tool widely used in security offensive).

Although there are several files left to analyze (dosdivanya_security nyetAV.reg and stolichnaya_def.exe), having all these files here makes Angela think that this computer is the bridgehead of the intrusion. Let’s see their content:

The objective seems quite clear: mount the C: of the target computer (something that should not be allowed either), copy the Empire stager and then run PsExec to launch it remotely.

NyetAV.reg is not very complicated either: its goal is to disable Windows Defender from the registry. The last file, however, seems much more mysterious: VirusTotal detects it as malicious, but there is no solid verdict that allows us to define what this executable is for. Angela decides to launch it in a sandbox manually, and she gets this result:

… Along with a terminal with administrator privileges. It is clear that the executable is an elevation of privilege exploit, apparently related to BITS. A little OSINT makes it possible to determine that the exploit used is CVE-2020-0787, possibly thanks to one of the PoCs already available on Github. Worst of all, this vulnerability was patched in MARCH 2020. The guillotine no longer seems to be enough, the entire FFP building will have to be set on fire…

Ready to methodically unravel all the attackers’ actions, Angela takes Sysmon’s logs and prepares to undo all the attackers’ activities. Sysmon lets you carefully “rewind” everything you have done on the system. Lastly (remember that we are going back in time) you can see the execution of SharpHound (BloodHound’s data ingestion module):

The tool has been executed correctly, because we can see that the Documents directory shows the results file 20201109133730_BloodHound.zip (which even indicates when it was executed). Angela recovers the file and passes it to Salvador so that he can import it into his audit VM, which has BloodHound installed, and the result is clear:

BloodHound is a very, very powerful tool. One of its functionalities is to detect where domain administrators have logged in. With these results in hand, it becomes clear why the attackers moved sideways to W10-PC5 – that’s where they knew from BloodHound that they could find the credentials of a domain administrator.

Just before SharpHound the attackers launch a script called adfin.bat, which contains several calls to adfind.exe with various parameters and whose objective is to obtain information about the domain (users, groups, domain controllers, etc.)

A few moments before we can see (twice) how the antivirus is defenestrated by the load of nyetAV.reg:

Being methodical pays off: we almost forgot about persistence, in this case easily detectable by Sysmon by having EventID 19, 20 and 21 correctly loaded (relative to WMI):

The most interesting thing happens at 1:01 p.m. when Sysmon sees how the CVE-2020-0787 exploit unfolds in all its splendor launched from an Empire agent:

The “extra” of creating a local administrator user is very interesting, and especially the fact that the launcher11.sct (another of Empire’s stagers, which in this case is launched with local administrator privileges by performing EoP) has been launched from 101.132.122.215, which is a new IOC that we carefully keep.

If we keep rewinding backwards (Yes, Angela has used a VHS. And yes, she also dyes her gray hair) Angela finds a very interesting thing:

Here we can see how the attackers are launching the Empire stager … but what is launching it does NOT seem to be related to Empire. What could be happening here? Angela knows that there are groups of cybercriminals who specialize in obtaining access, then selling it to other groups like Ryuk, who are in charge of carrying out the intrusion and deploying the ransomware. She makes a note of investigating that rundll32.exe to find out where it may have come from.

[Author’s note: In fact, the idea was to allow for a certain amount of time to elapse between the first and second access, in order to simulate the time in which the first group “puts up for sale” the access and the second group acquires it. Logistical problems (I made a mistake with the recovery of a snapshot that did not synchronize the times well and left the whole scenario out of square) forced me to redo the scenario … without that timeframe that was so beautiful]

Shortly before the deployment of the Empire agent, a fairly standard string of recon commands is observed:

It’s a bit curious, because some of that information was already in the attackers’ possession thanks to Adfind and BloodHound. This reinforces Angela’s theory of two groups of attackers (the first recognizing the terrain and the second confirming that the access is “legitimate”).

Angela is left wondering how the attackers were able to get hold of the password of the local FFP admin. It is clear that “Fiesta2020” is not a particularly strong password (probably not 5 minutes of hashcat with a good set of dictionaries and rules), but … they had to get it from somewhere, right? (Remember that Windows 10 does not have Wdigest, so there are no clear passwords).

Applying a bit of deductive thinking, and with the theory of the two groups, the group that has launched the exploit (and therefore obtained administrative privileges) is the second one the one that makes use of Empire. If we review Empire’s options we see that it has a command called powerdump that is used to dump the hashes of the local passwords. We can then study the powerdump source code, identify unique code strings, and look for them in the W10-PC5 memory dump.

In the end, logic points to the attackers having made use of Powerdump, but logic and evidence are like the reed and the lid: together they are much better:

At this stage of the investigation, it seems that all that remains is to find the input vector. Sysmon has no feelings, and if we keep looking back we find a tragedy in several acts:

First act: The mysterious rundll32.exe launching a cmd.exe and confirming the intrusion on the computer.

Second act: the connection against the C2 (beware, new IOC: 101.132.122.214) of rundll32.exe.

Third act: The father of rundll32.exe is not Darth Vader … but as if he were. Really, FFP users? Haven’t you taken awareness courses? Angela searches the hard drive for the file, but even though deep inside she already knows what she’s going to find she needs to see it with her own eyes:

One thing is clear: the great classics never die. Now Angela only needs two things: what is inside that document, and how it got to MINAF. VirusTotal detects it as malicious, but does not make anything clear what it could be:

Angela extracts the malicious macro, which does not seem to give many clues on its own:

But a bit of searching in open sources brings up a great article from our colleagues at Tarlogic, which points out that macro as belonging to Metasploit (another well-known exploit/post-exploit suite):

[Author’s note: In a real-world scenario, the malicious macro would download Emotet, which could in turn download Trickbot or KegTap. As we do not have an Emotet C2 at hand, Metasploit has been chosen to simulate that first intrusion].

To find out how it got in, we checked the user’s browsing history, and we easily found the download (repeatedly) of the file in the browsing logs of the user dolores.jolgorio (remember that in the simulation rules we ignored in the evidence everything that happened before November 9, so don’t pay attention to those launcher.bat, they are props):

In the absence of browsing traces, everything suggests that the real input vector are emails. In this case, the FFP computers do not have Outlook but instead use the Windows 10 Mail app itself, but Angela has little trouble finding the malicious email:

The Windows Mail app is definitely VERY LITTLE forensic friendly. All the information in the emails is saved in C:\Users\[User]\AppData\Local\ Comms, but the metadata is saved in the file store.vol, an ESE (Extensible Storage Engine) database, which we can open with EseDatabaseViewer and it looks like this:

In the end, Angela ends up saving the email as .eml and opening it in a text editor, with rather sparse results in terms of metadata:

At least she gets what she needs to track the email in the gateway logs: a Real From (admin@mina.es) and a subject (FFP Reorganization). With these data, she verifies that the email was sent on November 4 to 11 other people in the FFP, and that luckily dolores.jolgorio was the only one to fall for the spear-phishing.

If we now re-watch the movie in the right direction, it becomes clear what the attackers did:

  1. They sent an email with a malicious macro, and got a user to open it.
  2. They deployed a Meterpreter agent.
  3. They recognized the system.
  4. They made the switch from Meterpreter to Empire.
  5. They elevated privileges with the CVE-2020-0787 vulnerability exploit.
  6. They dumped local credentials with Powerdump.
  7. They recognized the domain and identify W10-PC3.
  8. They launched an Empire agent via PsExec.

With all the aspects of the incident already analyzed, only the phases of eradication, recovery and the lessons learned remain … which we will look at in the last article of the saga.

See also in: