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

ma_fa2

ma_fa2_upx

2) CFF Explorer:

Unpacked the UPX section

ma_cffe_upx

and saved the unpacked binary

ma_cffe_save_unpacked

3) Resource Hacker:

Analyzed the GUI to determine purpose of strings in data section

ma_rh_d1

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.

r2_imports

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).

r2_entry0_visual

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.

ma_fn

The program then creates another executable in %APPDATA%\Roaming\ which is named KB#########.exe, mimicking a standalone Windows Update installer.

ma_fake_update

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.

ma_fake_update_process

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.