Analysis of the Win32.Cridex Malware
Overview
a. Methodology
Before analyzing this virus, I made sure to do no research, to more closely simulate an unknown and/or environment-specific virus sample. Because of this, I also chose to be more cautious than might otherwise be necessary.
1) I began by running it against some simple PE analysis tools in a sandboxed Windows7Pro environment. 2) I then progressed to static analysis using Binja and r2. 3) Finally, I progressed to live detonation of the malware and dynamic analysis.
b. Environment
- I performed the full analysis in a sandboxed Windows 7 Pro VM on Virtualbox, with Guest Additions installed
- The environment does not have internet access
- The environment has a full suite of analysis software
- The following tools were used:
- Radare 2
- CFF Explorer
- FileAlyzer2
- FakeNet
- ProcMon
- ProcessExplorer
- Autoruns
- Resource Hacker
Analysis Walkthrough
PE Analysis
Tool Used | Information Discovered | Inferences |
---|---|---|
FileAlyzer2 | file is a PE with UPX packing | could be malware due to presence of UPX packer |
CFF Explorer | unpacked UPX section, enum’d imports, enum’d text sections, enum’d file metadata | appears to possibly feature a shell replacement (lighttek). Data sections include possible wordlist? |
Resource Hacker | correlated unusual data sections to GUI menu system; not wordlist | text randomized for obfuscation? |
radare2 | static analysis, enum’d DLL and function imports | attempts to kill process, and exits if unsuccessful. If successful, spawns a GUI and continues execution |
Step-by-step
1) FileAlyzer2:
Determined that the File is 1) a PE file, and 2) packed using UPX
2) CFF Explorer:
Unpacked the UPX section
and saved the unpacked binary
3) Resource Hacker:
Analyzed the GUI to determine purpose of strings in data section
Data section strings appear to be obfuscated GUI labels.
Static Analysis
At this point we’re ready to dive into the executable and begin to analyze it’s program flow.
1) r2:
Performed complete analysis(aaaa
). Only 1 entrypoint present(entry0
). Import table shows a lot of process manipulation function calls.
There is no main entrypoint, and entry0
is not a function, so pdr
(Print Disassembled [Function] Recursive) must be used in lieu of pdf
(Print Disassembled Function).
Here we see there is an early check for the presence of something, and if that is not present, the process terminates. Moving on to dynamic analysis, we’ll look for indications of what this jump could be.
Dynamic Analysis
Given the relative compactness of the executable, it’s fair to assume that it likely pulls additional components from the internet(or is a destructor, and simply tries to damage the computer it infects; given that it performs a state check of some kind, however, this is less likely).
Step-by-step
Pre-Detonation
1) Launch FakeNet as admin 2) Launch ProcMon and filter running processes as needed 3) Double-check the isolation of the environment(i.e. no network access, no guest-to-host transfer access, etc) 4) Detonate original malware(not the manually-unpacked one; this one is likely to crash, since the version of UPX can have different artifacts and slight format differences)
Post-Detonation
As expected, there is a flurry of process and registry activity taking place after execution. There are also DNS queries made for a number of domains, so it would appear that the program is indeed attempting to download some additional components.
The program then creates another executable in %APPDATA%\Roaming\
which is named KB#########.exe
, mimicking a standalone Windows Update installer.
It then adds an entry to HKLM\Software\Microsoft\Windows\CurrentVersion\Run
pointing to this executable, to run on boot.
Interestingly, if we examine this executable, it turns out to be the same as the original packed executable we ran; basically, it copies itself into this directory and renames itself as a stealth mechanism.
Wrap-Up
Unfortunately, without actually allowing the program to access the internet we cannot analyze the behaviour of the modules it would attempt to download, and if we look at online writeups of this sample we see why we cannot do this: some versions contain a worm for lateral movement.
Even just coming this far, there are plenty of IoCs we could use to build firewall or YARA rules to detect this particular malware.
For instance, the placement of the suspiciously-named executable into the %APPDATA%\Roaming\
folder, or the presence of certain strings within the executable, or any number of the registry changes it makes while setting up persistence, could all be used as potential IoCs.
Unfortunately, the DNS hostnames cannot be used as IoCs on their own, as it turns out they are pseudo-randomized. Potentially, however, some related data to the DNS names combined with another IoC, like netblocks + a string in the executable, could be used.