Nanocore Cracked Alcatraz – Leaving The Door Open
Remote administration tools are used often in many attacks, from entry points to APT attacks to the teenager in the bedroom, it is still a popular class of malware used today to infect systems. Nanocore has had many owners since it’s inception and has had many alterations and changes put upon it, when the cracked version of Nanocore was released it provided many criminals the ability to use the tool for free. Many now utilise the cracked version as its openly available, free and fairly powerful in features. The most popular cracked version, although there are many variants, is the “Alcatraz” crack, which was produced by a prominent reverse engineer. This crack is using the version 1.2.2.0, which is fairly old compared to how many revisions Nanocore has since had. There has been much research on Nanocore due to it being used in attacks, one such research is from ‘Kevin’, who in 2014 talked about “decoding” the config of Nanocore. The cracked version uses this old way of holding configuration and so is trivial to extract, later versions have implemented different ways of retrieving configuration.
Many decisions made by the Nanocore developer who developed this version were poor in regards to cryptography. As other research has already touched on, the configuration is blatantly held within the resources by the simple use of having a resource called “1” and the binary calling FindResourceEx(). This resource does not simply hold the configuration, it also has flags to whether it is compressed and also an encrypted key for the resource. We derive 16 bytes from the resource which is our encrypted key and use Rfc2898DeriveBytes to get our IV and key. What’s poorly done in this case is that IV and Key are using the same value and have no difference between them whatsoever, simply the assemblys Guid set as a Byte array. Another issue that this variant has is the iteration count in deriving the bytes, the recommended amount is 1000, which is fairly conservative and can be ramped up with todays hardware. The iteration that Nanocore has decided to incorporate is 8.
The policy of keeping the key and IV the same is again shown when we then utilise the DES algorithm in Nanocore for config decryption and network packet encryption. After we have generated the key from the bytes we then set our encrypter and decrypter using the set value. DES is a very weak algorithm and has been known to be broken for a while now, this allows people who are infected with Nanocore a helping hand in understanding what possibly might of been stolen or seen from this RAT variant (Assuming corporate full packet capture environment).
From the cracked version I have tested and looked at many samples and can see that something interesting which can help DFIR guys considerably when it comes down to the cracked variant which most likely is the most well spread. It seems that the license holder has a value which is connected to the decryption key of the malware in some manner. This means you can possibly not only identify individuals campaigns not only by C2 but by the key. I came under this assumption by constantly outputting samples, I then viewed Palo Alto networks work and noticed that the key was the same they had revealed that their configuration key was the values 72 20 18 78 8C 29 48 97, which now can be identified as the key for the alcratraz crack. If the version is 1.2.2.0 and you have full packet capture or want to decrypt the configuration easily, the values above will more than likely be the correct sequence of bytes. Although the Guid is used, builds from the cracked version will always have this value.
This leaves us able to decrypt traffic and configurations easily. So if you’ve been infected in some way by Nanocore, you should probably try that key before anything else. This value is not the same in modern legitimate versions of Nanocore, the key is different but may still be identifiable to the user.