Published on November 11, 2015

Diving into Chimera Ransomware

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.
MD5: e6922a68fca90016584ac48fc7722ef8
SHA1: a039ae3f86f31a569966a94ad45dbe7e87f118ad
SHA256: ffb4a81fc336b1d77c81eef96eab0a5249ebb053c8920dd0c02e1d9f3ac257b0
Size: 393.216 bytes
Chimera Ransomware Icon


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:
Chimera Ransomware Main Function
A base-64 encoded key is used to decrypt whatever is contained inside 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.
Chimera Ransomware Stage1 Encryption
Interestingly enough the decrypted payload is manually mapped in memory:
Chimera Ransomware Manual Mapping
After mapping every section the module is called directly through a function pointer:
Chimera Ransomware Memory Loading
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.


MD5: 44aa17e27280603c9f83cc6fc1d50d82
SHA1: e8266169ed366c31e14a8cfaba6e850b1b3f39ef
SHA256: fb02021257e90f3feb1be35dbc98db8a9cd68a83da320ba106b6ad1c77ff701f
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:
Chimera Ransomware Obfuscated Core
The first step performed is to acquire SeDebugPrivilege capabilities for the current process:
Chimera Ransomware Sedebugprivilege
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:
Chimera Ransomware isWow64Process
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().
Chimera Ransomware Injection
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.


MD5: 1fc11f7a387b7fe66e1e85135f5f1ffe
SHA1: fd834485724db80658538f710eb271f431375a85
SHA256: 3fd22016570ca8072180705c8fa2a81efc927313ee9fdabbb1d43e21f3e995de
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:
Chimera Ransomware Loader
The function we called infectionProc() performs three main actions:

  1. Phone home and tell the C2 who we are (ip address + volume serial number)
  2. Find files and encrypt them
  3. Show a threatening message in full screen using Internet Explorer

Chimera Ransomware Main Functions

Phoning Home

Chimera first tries to obtain the public ip address of the infected machine using a simple query to
Chimera Ransomware Get Local Ip
After that a new thread is started to contact two embedded IP addresses: and
Chimera Ransomware C2 IP
The handshake uses the following schema:
Chimera Ransomware C2 Handshake

  1. Chimera’s version is sent to the C2
  2. The ransomware waits for an acknowledgement message containing the string verack
  3. After the ack a further message is awaited containing the version of the server component
  4. 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.
Chimera Ransomware Pybitmessage

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 Ransomware Drives Browsing
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:
Chimera Ransomware Encrypted Files
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:
Chimera Ransomware Key
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.

Ransom Request

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.
Chimera Ransomware Request
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.HTMLThe HTML file is used to retrieve the bitcoin address, during the second step the decrypter queries<bitcoin address> to check if a payment has been received. The amount retrieved from the 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):
Chimera Ransomware Bitcoin Payment
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.
Chimera Ransomware Keys
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.

Behavioral Analysis

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 Ransomware Blocked by ReaQta-core


MD5: e6922a68fca90016584ac48fc7722ef8
SHA1: a039ae3f86f31a569966a94ad45dbe7e87f118ad
SHA256: ffb4a81fc336b1d77c81eef96eab0a5249ebb053c8920dd0c02e1d9f3ac257b0
MD5: 44aa17e27280603c9f83cc6fc1d50d82
SHA1: e8266169ed366c31e14a8cfaba6e850b1b3f39ef
SHA256: fb02021257e90f3feb1be35dbc98db8a9cd68a83da320ba106b6ad1c77ff701f
MD5: 1fc11f7a387b7fe66e1e85135f5f1ffe
SHA1: fd834485724db80658538f710eb271f431375a85
SHA256: 3fd22016570ca8072180705c8fa2a81efc927313ee9fdabbb1d43e21f3e995de


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!