Recently the ransomware world provided a couple surprises: the discovery of CryptoWall 4 in the wild and a new ransomware dubbed Chimera, so far found to be infecting businesses mainly in Germany and threatening to leak personal files if the ransom isn’t paid.
This is the sample we’ve analyzed.
Size: 393.216 bytes
The main executable appears to be mainly delivered by email and is written in .NET, the first stage doesn’t perform any malicious function other than decrypting and extracting the second stage. All the relevant code is contained inside the Stub class, the main method is pretty straightforward:
A base-64 encoded key is used to decrypt whatever is contained inside Stub.pe which, as it happens, is the second stage’s encrypted payload, analysts can retrieve it from here, this is the key used: fO69CKrW5riZeZWZibAc2jzkqvbrNOMxgsBGRGG39ogzNQA0uB8sJXASVzhq5yZn2RldONsSsEgKjITpkKJX4A==
A quick look at the method Stub.decryptBloc() suggests that we are dealing with a local implementation of AES and according to the decoded key, it should be in its 256-bit flavour.
Interestingly enough the decrypted payload is manually mapped in memory:
After mapping every section the module is called directly through a function pointer:
That’s where the job of the first stage is done. Let’s jump now to the next stage, exactly where the fnDllEntry() is called on the raw assembly by the run_pe() function. The next stage is 54.265 bytes in size, we can dump it to obtain the second stage.
Size: 54.265 bytes
Checking the debug information we find: C:\Projects\Ransom\bin\Release\Loader.pdb an indication that (when in doubt) yes, we are dealing with a ransomware and the current stage is just a loader DLL for the next stage. This loader is actually quite simple and its function is simply to find a suitable process for the injection of the core module of Chimera. Checking the binary we can indeed notice the presence of a third and final stage packed into the payload, the MZ signature, DOS stub, the PE header together with pieces of .text, .rodata and .reloc sections headers are still visible:
The first step performed is to acquire SeDebugPrivilege capabilities for the current process:
After that the loader begins to enumerate every window through the EnumWindows() function, looking for a 32-bit process to use as a host for the infection:
once a suitable process is found the core is injected and started: a OpenProcess() is called to open the process, a chunk of memory is allocated into the host process though VirtualAllocEx() then the code is copied with WriteProcessMemory().
After injecting the unpacked third stage’s code a CreateRemoteThread() is called and the ransomware core life begins. This stage seems to use parts of ReflectiveLoader to perform the loading into the the final host process.
Size: 88.577 bytes
Once again from the debug information we retrieve the (supposedly) original name of the component: C:\Projects\Ransom\bin\Release\Core.pdb. First of all Chimera tries to understand if it’s already running on the system, to do this it simply creates a mutex using as a name the VolumeSerialNumber of the computer it’s running on, if the instance is found then the ransomware stops. If Chimera is not running the next action is to remove itself from the disk and then call the main infection routine that can be called through a thread, or directly in case the core has been invoked statically. The pseudo-code below shows the first steps of the infection process:
The function we called infectionProc() performs three main actions:
- Phone home and tell the C2 who we are (ip address + volume serial number)
- Find files and encrypt them
- Show a threatening message in full screen using Internet Explorer
Chimera first tries to obtain the public ip address of the infected machine using a simple query to whatismyipaddress.com:
After that a new thread is started to contact two embedded IP addresses: 188.8.131.52 and 184.108.40.206:
The handshake uses the following schema:
- Chimera’s version is sent to the C2
- The ransomware waits for an acknowledgement message containing the string verack
- After the ack a further message is awaited containing the version of the server component
- Finally a verack is sent to the server to confirm the end of the handshake
Chimera uses BitMessage as a P2P communication protocol, instead of what we’ve been used to see with other counterparts using TOR. The two IP addresses listed above are contacted respectively on port 8444 and 8080.
Let the encryption begin
Whether the connection to the C2 is successful or not, the encryption stage will begin anyway. Every disk drive is enumerated and browsed, including the Floppy Disk if present.
Chimera first looks for some specific folders: \Windows, \$Recycle.bin, \Microsoft, \Mozilla Firefox, \Opera, \Internet Explorer, \Temp, \Local, \LocalLow, \Chrome. These directories are left untouched to avoid compromising the system’s functionalities, otherwise no ransom could be paid. Then is looks for different families of files (images, multimedia, documents, keyrings etc…): .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
At which point the encryption process begins and all the identified files are renamed by adding the .crypt extension, a ransom request file is dropped in every folder and used later for the decryption stage:
The encryption procedure is asynchronous to speed up the operations. Chimera embeds different encryption and hashing algorithms or references to them into its code, but only two appears to be used. We didn’t delve into the encryption algorithms since our interest was in the infection stage, so disclaimer: the following details might not be accurate, feel free to contact us if you’ve more details about these steps. When the encryption engines is initialized, 128 random bytes are requested to the system:
This data is stored into a buffer and passed to a hashing function that appears to be either SHA-256 or SHA-512, this same data become the key used later on during the encryption stage.
After the file encryption is complete a menacing message will popup, requesting a given amount of BitCoin and threatening the user that her personal data, documents and pictures will be published on the internet if the ransom is not paid. There’s no countdown for the decryption as opposed to what happens with the other ransomware families.
The user is invited to download a program called Chimera Decrypt to aid in the decryption of the resources fallen victim to Chimera. The decrypter program first searches for all files whose extension is .crypt and then looks for the first occurrence of the ransom request file: YOUR_FILES_ARE_ENCRYPTED.HTML. The HTML file is used to retrieve the bitcoin address, during the second step the decrypter queries https://blockchain.info/de/rawaddr/<bitcoin address> to check if a payment has been received. The amount retrieved from the blockchain.info is checked against the amount stated in the ransom file, if the final balance for the address is greater than or equals to that amount a confirmation message is obtained (before anyone asks: no we didn’t really pay the ransom):
Once the payment is received the decrypter asks to wait a few hours since keys are sent over the BitMessage network every few hours. The BitMessage address monitored is: BM-2cWsXQDYSueEKCtcJS8wzAka3KiYYYC9rB and the hash of the Volume Serial Number is used to discriminate between messages.
When they key has been received the decryption process begins. The code resides inside a wrapper DLL and is a copy&paste of the encryption routine used inside the core module of Chimera. When a file is decrypted with what appears to be AES the .crypt extension is dropped.
We’ve tested Chimera against an endpoint equipped with ReaQta-core, the A.I. engine spots the infection attempt immediately, killing the malware during the infection stage. The data integrity system keeps protecting the data from tampering and exfiltration even if the A.I. engine is disabled. All of our customers are already safe and no updates are required.
Chimera is a new entry in the ransomware world although it’s still not as sophisticated as other older ransomware as CryptoWall, CryptoLocker or CTB-Locker. At this point of our analysis Chimera doesn’t seem capable of really publishing and posting on the internet personal files, documents and pictures but these capabilities, if proven to be effective, can certainly be added at a later stage by the author. The addition of BitMessage is an interesting novelty and it can be an effective means to keep the identity of the authors hidden. As usual we suggest to keep your security tools up to date and to have a protected backup available, due to their simplicity ransomware can easily bypass the protection of traditional antivirus systems, so if detection fails the next best option becomes a full restore from a fresh backup. Never forget that network folders and attached drives are also encrypted.
Join our newsletter to get the world’s latest security events and our technical analyses delivered directly to your inbox!