This post kicks off my new blog which will primarily be about malware analysis and reverse engineering. I will try to go into detail about tools used and the theory behind the techniques that I’m using wherever appropriate. Also, I’d like to point out that if you’re interested in malware analysis and reverse engineering services, please contact me. I’m now a grass-fed, free-range independent malware researcher. This is the first in a series I will be writing about AlphaBlend, my name for this particular campaign. The backstory on researching AlphaBlend starts with a group of people that pool resources and knowledge to tackle various malware files and threats that pop up. We have have been working together for the past year or so, and all of the following is based on the most recent of these fire drills.
This particular campaign began in mid-January, and the file in question is a zip with four executable files inside. Three of the files are DLLs. One is an executable, which is a benign ISO extraction program and two are benign DLLs. The third DLL, msimg32.dll, shares a filename with a benign DLL that the ISO extractor loads when it runs.
- Setup_4852.zip (e54bc), malicious zip
- Setup.exe (78410), benign ISO extraction program
- QtCore4.dll (70cff), benign DLL
- CFNetwork.dll (4ded6), benign DLL
- msimg32.dll (2fb00), malicious DLL
On a side note, I am going to “defang” all benign file hashes. I know people are automatically processing blogs like this for malicious indicators, and I don’t want to introduce unnecessary noise into those systems. Additionally, I’ll refer to files and other indicators using a short form of the first 5 characters of the sha256 to make this all easier to read. All indicators will be provided in the appendix in JSON format. It is still readable, and it makes it easier on the folks scraping the data.
One of the people in the group noticed that this zip file was being hosted at hxxp://uneft[.]com/userfiles/file/Setup_4852.zip (will add credits if they wish to be known). This is hosted on a compromised website on a large hosting server. I determined this from using poor man’s pDNS, bing.com’s IP index search:
https://www.bing.com/search?q=ip%3A62.210.16.61
This IP address is not of much value on it’s own, but there may be some valuable forensic evidence on the server. I’m not including it as an IP indicator in this post for this reason. However, looking for other malicious files downloaded from the same IP using VirusTotal search yields another zip payload (b191e). Looking at URLs in VT’s database that have hosted this file, a number of Github URLs are found. All are under one single Github account:
hxxps://github[.]com/noroh90
At the time of writing, this user had joined Github 25 days prior. There is a single repository under this account that appears to be used to rotate malware payloads in this campaign.
Focusing on the payload DLL, msimg32.dll, I ran it through Intezer Analyze to look for code reuse from other malware families. Nothing was found:
https://analyze.intezer.com/#/analyses/bdefb307-3853-44bb-bb5d-037665d35052
Focusing on the Import Hash of the DLL, two additional DLLs are revealed via search in VirusTotal (4ff45 & f28ab). The second file didn’t have a filename listed, but it must be what I’ve added below. We’ll see why soon. The second one, f28ab, has an interesting theme to the AV detections: “Floxif”. This is the malware that used CCleaner as a vehicle in a similar way to how this one uses the benign ISO extractor. I have not yet explored how this may be related, but here are two blog posts detailing Floxif. How and if this is related will be explored in a future post in this series.
https://blog.talosintelligence.com/2017/09/avast-distributes-malware.html
http://blog.morphisec.com/morphisec-discovers-ccleaner-backdoor
Examining the three malicious DLLs along with the ones from the Github repo, they all share a similar set of exports. One export, “AlphaBlend”, is identical across all of them. The following is a view of that stretch of code in Hopper Disassembler.
I’d like to point out a concept when writing detection signatures that I learned a few years back at ShmooCon. The concept is strings-based signatures are quite weak, but code-based signatures are quite strong. The following is a video of Lauren Pearce's excellent talk. The backstory starts at about 14:52.
With this concept in mind, I opened the file in Synalize It Pro, a really good hex editor with colored grammar for PE files and other file types. It colorizes the various parts of a PE file for you.
Armed with this information, I wrote a YARA rule to detect this malware. I used the hex representation of the three consecutive exported functions as one of the conditions in the signature. In addition to standard YARA format, a JSON representation of the rule is also provided to help the scapers. I used a tool called plyara to generate this format. I am a maintainer of this tool, so any feedback is more than welcome.
The results of retrohunts for this rule in ReversingLabs and VirusTotal have uncovered around 45 unique files in the campaign which began in January.
Malware that uses a benign file and loads a DLL makes automated malware analysis difficult. Running the DLL by itself or the Setup.exe by itself both yield no results. Therefore, before starting the manual reversing journey, I ran everything in app.any.run’s interactive sandbox.
https://app.any.run/tasks/cc9eaa7c-5649-443d-9666-fd55a43cc0b6
I found that the file crashes when a file named “Setup.msg” is missing. With the file present, a different error is produced, but execution ends presumably because the file content is not what the malware expects.
I then began the process of manual reversing. My setup is straightforward with three tools, x64dbg, Process Hacker, and procmon in a Windows 7x64 VM.
The key to analyzing a DLL like this is to set a breakpoint on the DLL being loaded in the benign file. You just need use the name of the DLL in configuring the breakpoint. Running up to the breakpoint leaves you at the entry point of the DLL. From there, stepping through the code reveals a number of interesting items. One is an interesting string “Actx “. The trailing space is part of the data. It’s unclear what this string is used for, but an XOR key is one possibility.
Looking at procmon to see what’s happening, the malware is observed to do a few checks for AV including Avira and ESET.
It also checks if CEIPEnable is set, which is part of Windows Customer Experience Improvement Program. It also checks for the locales of both CodeGear and Borland.
There is much work to be done sorting through the behavioral data, but via the debugger, everything up to the crash can be captured via procmon.
Looking at the file in Cerbero Profiler, one sees that there is a debug directory present.
One of the people in the group asked how I arrived at the hex code snippet used in the YARA signature. It is based on both the concept outlined in the YouTube video above coupled with a concept from David Bianco’s pyramid of pain. This type of signature aims for the top of the pyramid at the TTPs of the attacker. To avoid this signature, the adversary must change the code. This is in that most painful part of the pyramid. For more info on the pyramid of pain:
https://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
There are a number of avenues of investigation still to take including checking for overlap with Floxif, processing the 45 or so files found by the retrohunt, determining what the Actx interesting string is used for, examining the debug directory, and analyzing the structured exception handler. I hope this has been an enlightening blog post and I look forward to writing more in this series.
Appendix
78410 2cb5eed 67931b6d6 037168c733 571877682 6c24c1c5 e2af3903f8 a72064 (Setup.exe)
70cfff0b4 055994b38 bbb420f59c5 81b5bb1d13db 3a03905f19 dbf5779430c47 (QtCore4.dll)
4ded6 618a9 e294bb670 45d3c45c 705a46231 0de63143d 36bd779f6 13e5c 5085d (CFNetwork.dll)
Benign File Hashes
{
"files": [
{
"filename": "Setup_4852.zip",
"md5": "f0dc136af71e4ebad31da1850c343692",
"sha1": "18ac41ddb0de66ba9b6047b6a0cb5a5e432b634e",
"sha256": "e54bcff1d12e49c1adf1264dbd04993dc4a127fb1bf223caa115cd547c08131d"
},
{
"filename": "msimg32.dll",
"md5": "c0ab87b047515dc2dd47bb49223f24c1",
"sha1": "ac3649b0c3f4e23c3f52e1131d45c16e42eba834",
"sha256": "2fb00d9f9eee56523ac9fe61e7af8966ac60de6fdaf3ccd6214aae745ce2e922",
"imphash": "1bd3413303a379c6301fcac645b55e0c"
},
{
"filename": "Setup_5341.zip",
"md5": "7516fac6d6b3b3085197604a61d8bdf6",
"sha1": "241ed5972a1f46603c684256da7fcc9edef02c11",
"sha256": "b191e33360b886d1d846151b9c30a0e4273b460b709c04648734c71562239868"
},
{
"filename": "msimg32.dll",
"md5": "d7e8d0831dd2d1856da705bc0c80517b",
"sha1": "3b52ab4d6f9e79f95fe1cb27a1ba37de1e14b9eb",
"sha256": "4ff457b97d26f785c57812146565bf1e8b079c076df2ede2b6d3ee3a18eaad87",
"imphash": "1bd3413303a379c6301fcac645b55e0c"
},
{
"filename": "msimg32.dll",
"md5": "e5a16fe47e050df730b71b18265d1f0b",
"sha1": "b1299b7657bdfd4f44ddd17def7487375a592065",
"sha256": "f28ab348185b1c670c738ce90993544e352702f5b2a02b1c5529f3cc3e9f9a3d",
"imphash": "1bd3413303a379c6301fcac645b55e0c"
}
],
"network": [
{
"url": "http://uneft.com/userfiles/file/Setup_4852.zip",
"hostname": "uneft.com"
}
],
"yara": [
{
"condition_terms": [
"$a",
"and",
"pe.exports",
"(",
"\"AlphaBlend\"",
")"
],
"imports": [
"pe"
],
"raw_condition": "condition:\n $a and pe.exports(\"AlphaBlend\")\n",
"raw_strings": "strings:\n $a = { 33 C0 40 C2 18 00 33 C0 40 C2 2C 00 33 C0 40 C3 }\n ",
"rule_name": "AlphaBlend",
"start_line": 3,
"stop_line": 9,
"strings": [
{
"name": "$a",
"type": "byte",
"value": "{ 33 C0 40 C2 18 00 33 C0 40 C2 2C 00 33 C0 40 C3 }"
}
]
}
]
}
Machine Readable Intelligence
import "pe"
rule AlphaBlend
{
strings:
$a = { 33 C0 40 C2 18 00 33 C0 40 C2 2C 00 33 C0 40 C3 }
condition:
$a and pe.exports("AlphaBlend")
}
YARA Rule
For those of you who made it this far, here is a track to listen to while reversing. Balkans, I'm looking at you ;)
