Welcome back, my nascent hackers!
Now that all of the data on Evil Corp's servers (including 70% of the world's consumer debt and student loans) has been successfully destroyed, let's examine how they did it, or rather... how they might have done it. Since the show is a bit vague on details, let's examine a similar attack that has recently surfaced in Europe.
We know that Elliot and fsociety had destroyed all of the back-up tapes held by Steel Mountain when they hacked the HVAC system with a Raspberry Pi, which they used to turn up the temperature in the storage facility high enough to render the backups unusable.
With the tapes unusable, Elliot had to then destroy the data on Evil Corp's servers without being traced. As you know by now, deleting the files on the servers will not remove the data. Elliot and his colleagues knew this too, so they decided to encrypt the data with AES instead. In this way, the data was still there, but indecipherable to Evil Corp.
Recently, a new type of ransomware was found in Germany called Chimera. It has been used to attack businesses in Germany, rather than consumers as much of the previous ransomware targeted. Since most ransomware works similarly, let's use it as a model for how Elliot and fsociety may have "destroyed," or rendered useless, the data on Evil Corp's hard drives.
In this analysis, I will summarize how Chimera works, leaving out some steps for the sake of brevity. If you would like a copy of Chimera to conduct your own detailed analysis, I have posted it on Pastebin here.
Like much of the ransomware that has appeared in recent years, Chimera was delivered by email, likely with a social engineering component to get someone to click on a link or a file. It was written in .NET.
In this first stage, Chimera initially delivers an executable stub, whose only job is to call, decrypt, and decode the second stage payload, to the victim.
The second stage is the encrypted and encoded payload that contains a method that is clearly an AES encryption algorithm. Elliot and his colleagues would have used this or something very similar to encrypt Evil Corp's data. Likely, that would have it run in multiple threads to speed up the process. Considering the fact that Evil Corp likely has petabytes of data, encrypting it all would take some time.
In the next stage, Chimera then manually maps its processes to memory. This is very likely to bypass ASLR and DEP protections that are built into Windows and other operating systems. These protections randomize where a process will likely be in memory, making it more difficult to implement a buffer overflow as the malware cannot predict the location of the pointer. By manually mapping the process to memory, it makes it more likely that the malware will function as expected.
Next, Chimera goes through every Windows process looking for a 32-bit process that can host its payload and then open it.
Next, this ransomware goes out and finds the public IP of the machine it has infected by using whatismyipaddress.com. It then stores that value in a variable.
Once Chimera has the IP of the infected host, it then calls out to its command and control (C&C) servers. In this case, those servers are at 184.108.40.206 and 220.127.116.11.
Chimera uses Bitmessage to communicate via a P2P protocol on ports 8444 and 8080. Bitmessage is a secure, encrypted P2P messaging system that enables a single person to send out messages to one or many recipients. You can see in the screenshot below that Chimera calls the Bitmessage client PyBitmessage.
Next, the malware must find the hard drives where the data is stored. It needs to browse each of the logical drives and then store these locations into a variable for later use in the encryption process.
Now that Chimera has successfully taken over a 32-bit process, mapped itself to memory to avoid ASLR, and enumerated the hard drives, it needs to call back to its command and control server to get a random key with which to encrypt the files.
Once the random key has been obtained from the command and control server, Chimera calls the function from Step #2 above—the AES encryption algorithm—and begins to encrypt critical files.
Before it starts the encryption, it looks for the following file types:
.jpg, .jpeg, .xml, .xsl, .wps, .cmf, .vbs, .accdb, .ini, .cdr, .svg, .conf, .config, .wb2, .msg, .azw, .azw1, .azw3, .azw4, .lit, .apnx, .mobi, .p12, .p7b, .p7c, .pfx, .pem, .cer, .key, .der, .mdb, .htm, .html, .class, .java, .asp, .aspx, .cgi, .php, .jsp, .bak, .dat, .pst, .eml, .xps, .sqllite, .sql, .jar, .wpd, .crt, .csv, .prf, .cnf, .indd, .number, .pages, .x3f, .srw, .pef, .raf, .rf, .nrw, .nef, .mrw, .mef, .kdc, .dcr, .crw, .eip, .fff, .iiq, .k25, .crwl, .bay, .sr2, .ari, .srf, .arw, .cr2, .raw, .rwl, .rw2, .r3d, .3fr, .eps, .pdd, .dng, .dxf, .dwg, .psd, .png, .jpe, .bmp, .gif, .tiff, .gfx, .jge, .tga, .jfif, .emf, .3dm, .3ds, .max, .obj, .a2c, .dds, .pspimage, .yuv, .3g2, .3gp, .asf, .asx, .mpg, .mpeg, .avi, .mov, .flv, .wma, .wmv, .ogg, .swf, .ptx, .ape, .aif, .av, .ram, .m3u, .movie, .mp1, .mp2, .mp3, .mp4, .mp4v, .mpa, .mpe, .mpv2, .rpf, .vlc, .m4a, .aac, .aa3, .amr, .mkv, .dvd, .mts, .vob, .3ga, .m4v, .srt, .aepx, .camproj, .dash, .zip, .rar, .gzip, ., mdk, .mdf, .iso, .bin, .cue, .dbf, .erf, .dmg, .toast, .vcd, .ccd, .disc, .nrg, .nri, .cdi
These file types are likely critical to the business operation. These are graphics files, spreadsheet files, database files, backup files, email files, Java files, audio files, movie files, and encryption keys. Without them, the business is crippled.
Finally, Chimera makes a ransom request to the business owner. Note that the browser and its associated files are exempt from the encryption to enable the browser request and receive the payment of the ransom.
I want to thank the folks at ReaQTA in Valleta, Malta for finding, disassembling, and analyzing this malware (and for the screenshots).
Keep coming back, my nascent hackers, as we continue to explore the hacks of Mr. Robot, including an upcoming guide on how I would catch Elliot!