DiamondFox is a multipurpose botnet with capabilities ranging from credential stealing to theft of credit card information from point of sale systems. This capable malware is being distributed in a number of hacker forums, allowing it to be operated by attackers with extremely limited capabilities. Fortunately for malware researchers, DiamondFox fails to protect itself in various ways.
DiamondFox
When reversing malware to increase my malware tracking capabilities, I came across this interesting bot developed in VB6. DiamondFox (aka Gorynch) is a bot which has a wide range of functionality. Capable of acting as a DDoS bot, RAM scraper for credit card track information, and password stealer, it is particularly well featured. Despite this feature density, the code quality is an entirely different story...
Functionality
DiamondFox has quite a few features, some of which are listed here:
- VM detection
- Detonation service detection
- Debugger detection
- Researcher detection
- Configurable install locations
- Configurable persistence locations
- Self-deletion
- Keystroke logging
- RAM scraping (credit card scraping)
- Password theft
- USB spreading
- Dropbox spreading
- Disable TaskMgr/Regedit
- Plugin based functionality
- Desktop screenshots
Here is the code used to detect if the DiamondFox bot is executing in a VMWare VM:
Many of these features are controlled via the C2 (command and control) panel, which is coded in PHP, albeit poorly.
None of these features are particularly groundbreaking, but it is quite interesting to see them all in one bot. Of these features, I did find the researcher detection interesting. To detect if it was detonating on what it deemed a researcher’s computer, it checked the computer name against a predefined list of computer names.
They are listed below, and if you are a researcher or service using them, I would suggest updating to something else:
ANTIVIRUS
VWINXP-MALTEST
MALWARE-STAR
VMG-CLIENT
HOME-OFF-D5F0AC
NAMAMO-AAAFC41B
BRIAN-BCAD2EA45
CANON
PAN-1E6ECC1F78B
VM_WINXP
WOLF
TEST
COMPUTERNAME
USER-2A6E79DA98
CITY5
Z-235
XP-SILO5YEIYKEX
JH-C64A2618CF31
SYSTEM-78358297
Network Communications
DiamondFox communicates exclusively over HTTP to a command and control server developed in PHP. There are multiple PHP scripts that the DiamondFox client interacts with. In order to report in to the C2, DiamondFox contacts “gate.php”.
In this HTTP POST, the User-Agent header is used as a filtering method. Without a User-Agent set to the value configured in the command and control server, the request will not be processed. Once this User-Agent is confirmed, the data in the POST is then processed. This information is encrypted/encoded (via XOR) with a key statically built into the C2 and the bots.
When reversing this encryption, I came to an interesting realization. The XOR key is not actually used, but instead, each byte (before being hex encoded) is XOR’d against the length of the key. Given a single byte of known plaintext, we can reverse this with little effort. We can get this from the last byte of the “arc” parameter.
Before decryption:
pc=4D434A4B564140&admin=4A6B24456A706D726D767177&os=536D6A606B73772433245168706D6965706124&hid=3630403D373C3C32&arc=373629466D7077&user=6D636A6B7661&fw=42716868&ram=30343D32244946&cpu=4D6A7061682C562D24476B76612C50492D246D3329303D3034495C24475451244424372A3534434C7E&gpu=5249736576612457524345243740&hd=3534342A3434244346&id=36
After decryption:
fw: Full
admin: No Antivirus
ram: 4096 MB
id: 2
pc: IGNORED
arc: 32-Bits
hid: 24D93886
user: ignore
gpu: VMware SVGA 3D
os: Windows 7 Ultimate
cpu: Intel(R) Core(TM) i7-4940MX CPU @ 3.10GHz
hd: 100.00 GB
Here is the code (Python 2) used to decrypt these parameters:
# Decode parameters
parameters = "pc=4D434A4B564140&admin=4A6B24456A706D726D767177&os=536D6A606B73772433245168706D6965706124&hid=3630403D373C3C32&arc=373629466D7077&user=6D636A6B7661&fw=42716868&ram=30343D32244946&cpu=4D6A7061682C562D24476B76612C50492D246D3329303D3034495C24475451244424372A3534434C7E&gpu=5249736576612457524345243740&hd=3534342A3434244346&id=36"
pairs = [i.split("=") for i in parameters.split("&")]
dict_param = {}
for p in pairs:
dict_param[p[0]] = p[1].decode('hex')
# Get key
key = ord(dict_param['arc'][-1]) ^ ord('s')
# Decrypt and print
for k in dict_param.keys():
print "{0}: {1}".format(k, "".join([chr(key ^ ord(i)) for i in dict_param[k]]))
In order to upload data stolen from the victims, files are uploaded to “post.php”. These files are then put into the appropriate folder in the “logs/” directory in the DiamondFox panel. The appropriate folder is determined by the file extension of the uploaded file. Additionally, only files with the allowed extensions can be uploaded.
When I saw the code for this part of the panel, I had a good laugh. The panel does not check for multiple extensions being applied to the file. This can be exploited with improper configurations of Apache and PHP to execute PHP code. This double extension attack was also exploitable in some versions of the Zeus command and control panel.
As it turns out Xylitol already discovered this vulnerability, and has uploaded a proof of concept. The proof of concept can be found here.
When files are uploaded to “post.php”, they are uploaded to one of the following directories (relative to the root of the DiamondFox panel):
logs/wallet
logs/scr
logs/rdp
logs/ftp
logs/mail
logs/pass
logs/kyl
logs/dump
From the live instances of DiamondFox that were investigated during my research, a number of these servers actually allowed for HTTP indexing of these directories. This allows researchers to easily track the actions of malicious actors using DiamondFox. The files stored in these directories are named after the “hid” parameter from each bot. One could potentially guess all the possible “hid” values (2^32) in order to get data from a C2 that disabled HTTP indexes. The “hid” values are the hard drive serial numbers from the victim.
Granted, those are not the only security issues related to the DiamondFox C2 panel, but we wouldn’t want to share all our secrets.
Configuration
Automation is a powerful weapon for malware analysts, as often our most valuable resource is time. For that reason, I often try to devise methods to automate configuration extraction for malware families. This allows for some simple botnet tracking without a great deal of effort.
In the case of DiamondFox, the configuration is quite easy to extract. The configuration can be stored in one of two places. It can either be stored as a resource named “101”, or appended to the end of the file after the string “<--------->”.When building a sample of DiamondFox, the attacker would set a 32 character key to XOR the configuration against. Much like the key for the network communications, it is nowhere near as effective as one may believe. Instead of using the entire 32 character key, only the first byte of the key is used to XOR the entire configuration. Again, we only need a single byte of known plaintext in order to decrypt the configuration, and the first byte of the configuration, “<”, is perfect.
Once this configuration is decrypted, there are still some values which are encrypted (using the same flawed method) with keys that are defined in the now decrypted sections of the configuration. When the configuration values are extracted and decrypted with bamfdetect, it looks like the following:
bwall@ragnarok:~$ bamfdetect loader.res.exe
{
{
"loader.res.exe": {
"description": "Bot that steals passwords, DDoSes, etc, written in VB6",
"information": {
"c2s": [
{
"c2_uri": "http://192.168.36.208/Panel/"
}
],
"raw_config": {
"ABox": "0",
"AVMW": "0",
"Abis": "0",
"Agra": "1",
"Ares": "0",
"Asys": "0",
"Boxie": "0",
"Drop": "0",
"FBP": "",
"HKML": "0",
"Inam": "svchost",
"Ipat": "APPDATA",
"Keyl": "0",
"MELT": "1",
"MKey": "YZ[\\",
"Malwr": "0",
"Norman": "0",
"Olly": "0",
"Panel": "http://192.168.36.208/Panel/",
"PoS": "1",
"Reg": "0",
"SFOL": "1",
"Stpe": "0",
"Task": "0",
"Time": "360",
"USB": "0",
"UsA": "88C6390D99703EC6F8B837CF1DAF2C5F",
"WLOG": "0",
"Wall": "0",
"Wine": "0",
"Xor": "hOtfBy6RPooEiQ3XAHhgkS0DbZtvce"
}
},
"module": "diamondfox",
"postprocessor": {
},
"preprocessor": {
"md5": "539cf6ad0f269f7107af3902cc84ba15",
"sha1": "a8667d2c59428ab3f4b06941b9e3bfd762c7f0f6",
"sha256": "d86fe39900812a0eaac7e3d2c8b517b2f62688ee96b0cecfd17db3e20b8db04c",
"upx_compressed": false
},
"type": "diamondfox"
}
},
}
The bamfdetect plugin for DiamondFox can be found here.
The Yara rule for DiamondFox can be found here.
Conclusion
DiamondFox, despite all of its functionality, is still simple for researchers to hunt, observe, and track. Developers, no matter what level of morality they have, are still likely to make cryptography mistakes, some worse than others. In the case of DiamondFox, they are quite laughable.
SHA256s + Cylance Scores
Cylance Scores generated with active model from September 2nd of 2015.
2feefc41b7d057680cb25198f1ba16c3358511a2e8914bd6727588d77259b080 -0.999999999997
ca6d3593337ec54f7ce383f95633a10a8c33bcc8f3417ce27cc2e96d10b57e43 -1.0
bc3de6b52f9a17cc48f2fbcf22681b12ca6126c69e94c28c9e227eaae0f0e14f -0.999999999942
41e3712037601a81168ecaf2b55409e4f914e3c4277b2c6d59979e3f8083f0a8 -1.0
acfe9bab64ac3e91ed0f04303959e4100c83f91c358da35534475c558b380d1f -0.999999996047
0fde9b23d734fa6a9f5df1109d054667e6d44df6c12bdfb0316b363119755bae -1.0
f4f41b2d38949817be76c42c8d544bb37b57c32f262bd19a11da1479654d6afe -1.0
cea655a6ba9f659ab92961f78d6052e870c094bef5ad60034d6aafb5dfaf51f3 -1.0
7db71994b36c1a4d7a52b3eba3396e36bbe3bf5df2bb332031ecc1bdfd9a2ea7 -0.999999999997
423c69ef020f776ef6896c9bb5ad467ad79358548e2c4a96c88790a2b3afe1e0 -1.0
2a57ee0e373638e5ec185098f7c078093ad61676f41967795b2eb88a043e7e95 -1.0
1d0ffbdc5777864870a133451bd6586e50bf85a5ce2dde56beec598d6e6b52f8 -1.0
4ebbbde7f4a5fc18de493dbb810916e83f9de15870bd3df2a7187a25186cb047 -1.0
a77a2d8d3cba696ddc619b75ca4be63a520845490eb6f40c6f683aa84864d74d -0.999999996823
3fe47e068693301a0651ecf57593e940eb81a407da6a3eaf788e1349d27b7a78 -0.999986004098
0828ac8253b0572473050ba9a79da0d0439e51ba0271f8f5350592ee3b6ef00c -1.0
b896ce77c3ea6dd708750bb4003ef28a35565082e6b8dc9960bcbb8073c97c6d -0.999999999997
3485a8e98de350d8cfee27f6a44163bfba62914f6748049dc912ea93b72de45e -1.0
fd42668c9964b0fe0e500ed3974dcb1f5459249424be59ad12439936831fa5d1 -0.999999999997
fa19c01587cae2909f7d96f77166c01e27f1e4ddb6e7e164ad7ac67dcf2be91d -0.999999999997
206a3907f6a520b46a4b8fbe9e8b09ab14cffab120c24c32def5dbed4109ef8d -0.99999973437
df997dcf6dcc9e2451146b05623f8950daf924c3e3125b5aef1cc9f84edf4bc9 -0.999999999998
435a69cc9db75d29b2ac005d20d5cc24360ccdef7e12358eba09dd16d2669923 -1.0
26449430d416cad4be35e74f3f83395f782a381e3cdf0c51bffaccf4bbef31f1 -1.0
810cd32eccca51d7fbc5962193008265d6dcfa2c07a17fdcf89cc30096cb444e -1.0
b1c0290937d8ca395b2974b9fd78250831e88f02e21f4bc7a8f570b131c4ccfb -0.999999999999
91e36378796961187bf904ae8d1c7e1d931a24b641d31329150dc03f80c0d6b6 -1.0
1cafd8a7d481628e13350945a58ca435d226f5d828f47a83a31f04272d90a235 -0.999999999999
8841f04d55d2563e54421b9baf724776f41bbc5cc091c06ff9e691c147c03610 -0.999999999998
c0d5ef9fea83170b986c684c591cdf99b7c6554b4fd75eb910821c8dccdbd990 -0.999999999972
b76760b8c21e347f06f4d09eb59cea4a3aeb0a2daffe83cec1f459c91ad5b6d8 -0.999999999997
63f4f60a5b6f67066488b7188b5b41ddcafa64a9d0399bb0eb37a2c2173683ca -0.999999999997
b576ff2d424e9e6e83b5b248c9f8936077b80140700e4de632fe0b3471ab3e74 -0.999999999999
2f58145a16e5f21dc14151111bb7538cca83dd1f1e2cf9b5a7a45685bc01166b -0.999999999997
MD5s
57b6201c4234848ed9a8379d29d39680
cab89edb360efd381255b3bf1e558739
ed2216354f360ee446f2270bca5855cb
8c6252082a4d2a80f8f0680d8ba285bd
25510b26828fa83233d8066e254d1054
81c1342f1158e031f65039c16a21c704
de9e9e640e1a1690883a14d4c38557d0
e574366fd9a708405c6620d1d723e214
2fbd48a16da6eeabd855e4726ea0620c
c5c01a3063a85af1cf48d9bafe9cd468
be617918109b99a95a89db54c2d63fd6
c6ae9dfa0252488aacb5c0be49c4ee43
8c610d12ee5e0052168a3f631772c356
00e90d335c40aaa3ec475ac2dc0ec107
7ef1853de2f894ab6e91410ea930a20d
1013cab5c1151d20e3a75cdf4ec46606
c5273a857baffe2d9426e6eb91f37285
1f537b7ee0f050898ab71d81b142a8e8
dc394063269815da30c6e09d433781a4
2443982b34f5ebb23ace7bab8f1f2a36
5e9f5ce035e7f690752adc75e92b45bf
7577b6202df0947d832520b151b446e4
86e71e980ca81124b59b8948c79f8103
30b9ee4cced970da8a25532b35b5faa0
0e3fb3e2f70750e845613006a00c05cb
5d2e471fd7337fcd4a0260e64ae631f4
0ce4138f90e70df1ed352e3355a06b09
c2cf234b0782f1f25df1b16258dc08f0
698aeee768549ff78e9aac35ec2073b4
32b0a63b5d37fba8e581bb08b401e42e
36d4b5d5f1dce5fba9edd9a339c3948f
52e0110fe956c9d092200e729bafc215
db3167d1f62805c2bcf7bd9f51c47819
941b85005e84859b8287c5cfbec34cd5
9209b051c1f4b305f84a382386d5dd57
