AlienVault R&D Labs Portal. Get the latest news from our research.
Header

Author Archives: Alberto Ortega

Set up your keylogger to report by email? Bad idea! (The case of Ardamax)

February 11th, 2013 | Posted by Alberto Ortega in Forensics | Malware | Windows - (Comments Off)

A couple of days ago, I was surfing our wild Internet when I came up with a dirty piece of software dedicated to steal accounts of a popular build-with-bricks videogame.

The program offered a premium account of the videogame for free. The real fact is that it was a stealer, which installs a keylogger on your computer to record and send your private information to the bad actors.

When the user executes the program, the keylogger silently installs itself and then hides its directories and processes. If we take a look at the installation directory, it has these files:

d6192e6ac19bedf50772769568b8a1bf RKJ.00 (encrypted configuration file)
c8602a35ed53655f62eb70e52627f7ef RKJ.01 (aux exec file)
cabd1ee6acc039dd33ba48f886f3b12d RKJ.02 (aux exec file 2)
29c88770640993a5f0df70bfa272bb09 RKJ.exe (main executable)

It looks like an Ardamax Keylogger installation, latest version. This is a pretty popular keylogger among bad guys, it has trial and paid versions. It can monitor keystrokes, login credentials, clipboard and even take screenshots and pictures from the webcam.

A couple of minutes after the infection, the machine started to connect to Google’s email server using an encrypted channel (SSL SMTP). Is the keylogger reporting results to the administrator using this? In that case, we could probably analyse the sample and get the email account credentials of the malware administrator.

As the configuration file is encrypted, the easiest way to get some more information is by doing some reverse engineering. Let’s going to infect a machine, dump the memory (keylogger.mem) and analyse it with volatility.

$ python vol.py -f keylogger.mem pslist

The keylogger process is hidden for Windows Task Manager, but volatility can show it to us.

Offset(V) Name PID PPID Thds
0x862d6528 RKJ.exe 1832 1528 1

Time to dump process memory.

$ python vol.py -f keylogger.mem memdump -p 1832 --dump-dir=/tmp/

And if we carefully study the strings contained in that memory dump (take care of the encoding!)…

$ strings -a --encoding=l 1832.dmp
[...]
Logs from "%USERNAME%
[censored].server232@gmail.com --> username
smtp.googlemail.com --> password
[...]

Luckily Google had disabled the email account due to service abuse, no need to report the issue.

What about the encrypted configuration file?

We have seen some people infected by this keylogger wondering how to decrypt the file to see where is the malware leaking information to. Well, if you can not do memory analysis or some debugging it is quite easy to decrypt.

After a quick cryptanalysis of the file, it is quite obvious that it is encrypted with XOR cipher or something similar. You can easily decrypt it by using a XOR analysis tool like xortool. Let’s give a try:

$ python xortool.py -b keylogger/RKJ.00

xortool will generate some output files with possible decryptions. In this case the 33rd file was the good shot, encrypted with key “Z|NY”. If we open it with an editor, we can see all configuration parameters and reporting credentials in plain text.

Take care of the channels you allow on your network! We have seen how Google do a great job on cancelling accounts of this kind, but we should never have a blind faith on a legit connection because it could be a potential way to leak private information to the outside.

Hardening Cuckoo Sandbox against VM aware malware

December 19th, 2012 | Posted by Alberto Ortega in Code | Malware | Windows - (Comments Off)

Some time ago, we wrote a post about how a lot of malware samples check the execution environment, and if it is unwanted (VM, debugger, sandbox, …) the execution unexpectedly finishes.

We use Cuckoo Sandbox in the lab for our analysis tasks, we really love how customizable it is.

Sometimes we have to deal with malware aware of the execution environment, and this is a problem when you are using public virtualization products. Let’s see how modifying some parts of cuckoo we are able to fake crucial parts of the system to the malware sample, so it will not be able to detect the VM (in this case, VirtualBox).

Pafish will help us to test our work, it is a demo tool that performs some anti(debugger/VM/sandbox) tricks, most of them often used by malware. When it is executed, it writes a log with the successful detections, so we can easily track and solve them.

To monitor the malware activity, cuckoo executes the sample with cuckoomon, the part responsible of hooking system calls to save the malware actions. With this powerful hooking system, we can modify the hooks to return fake responses if we do not like the call. For example, calls to check files / registry keys / processes to detect the VM.

When we execute pafish for the first time, it will detect VirtualBox using different tricks:

[pafish] Start
[pafish] Windows version: 5.1 build 2600
[pafish] Sandbox traced using mouse activity
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0 "Identifier"
[pafish] VirtualBox traced using Reg key HKLM\HARDWARE\Description\System "SystemBiosVersion"
[pafish] VirtualBox traced using Reg key HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
[pafish] VirtualBox traced using file C:\WINDOWS\system32\drivers\VBoxMouse.sys
[pafish] End

As we can see, it has detected our VM by reading some registry keys and looking for a file.

The piece of code responsible of hook RegOpenKeyExA (the call used by the detection) is this one (hook_reg.c):

HOOKDEF(LONG, WINAPI, RegOpenKeyExA,
  __in        HKEY hKey,
  __in_opt    LPCTSTR lpSubKey,
  __reserved  DWORD ulOptions,
  __in        REGSAM samDesired,
  __out       PHKEY phkResult
) {
    LONG ret = Old_RegOpenKeyExA(hKey, lpSubKey, ulOptions, samDesired,
        phkResult);
    LOQ("psP", "Registry", hKey, "SubKey", lpSubKey, "Handle", phkResult);
    return ret;
}

So we can modify it:

/* Hardened */
HOOKDEF(LONG, WINAPI, RegOpenKeyExA,
  __in        HKEY hKey,
  __in_opt    LPCTSTR lpSubKey,
  __reserved  DWORD ulOptions,
  __in        REGSAM samDesired,
  __out       PHKEY phkResult
) {
    LONG ret;
    if (strstr(lpSubKey, "VirtualBox") != NULL) {
        ret = 1;
        LOQ("s", "Hardening", "Faked RegOpenKeyExA return");
    }
    else if (strstr(lpSubKey, "ControlSet") != NULL) {
        ret = 1;
        LOQ("s", "Hardening", "Faked RegOpenKeyExA return");
    }
    else {
        ret = Old_RegOpenKeyExA(hKey, lpSubKey, ulOptions, samDesired,
            phkResult);
    }
    LOQ("psP", "Registry", hKey, "SubKey", lpSubKey, "Handle", phkResult);
    return ret;
}

We have changed the code to check if “VirtualBox” or “ControlSet” is in the provided SubKey to read. If it is, we will log a Hardening warning in cuckoo log and fake the response.

We have to do the same with RegQueryValueExA:

HOOKDEF(LONG, WINAPI, RegQueryValueExA,
  __in         HKEY hKey,
  __in_opt     LPCTSTR lpValueName,
  __reserved   LPDWORD lpReserved,
  __out_opt    LPDWORD lpType,
  __out_opt    LPBYTE lpData,
  __inout_opt  LPDWORD lpcbData
) {
    LONG ret = Old_RegQueryValueExA(hKey, lpValueName, lpReserved, lpType,
        lpData, lpcbData);
    LOQ("psLB", "Handle", hKey, "ValueName", lpValueName,
        "Type", lpType, "Buffer", lpcbData, lpData);
    return ret;
}

We change it to:

/* Hardened */
HOOKDEF(LONG, WINAPI, RegQueryValueExA,
  __in         HKEY hKey,
  __in_opt     LPCTSTR lpValueName,
  __reserved   LPDWORD lpReserved,
  __out_opt    LPDWORD lpType,
  __out_opt    LPBYTE lpData,
  __inout_opt  LPDWORD lpcbData
) {
    LONG ret;
    if (strstr(lpValueName, "SystemBiosVersion") != NULL) {
        ret = ERROR_SUCCESS;
        LOQ("s", "Hardening", "Faked RegQueryValueExA return");
    }
    else if (strstr(lpValueName, "Identifier") != NULL) {
        ret = ERROR_SUCCESS;
        LOQ("s", "Hardening", "Faked RegQueryValueExA return");
    }
    else if (strstr(lpValueName, "ProductId") != NULL) {
        ret = ERROR_SUCCESS;
        LOQ("s", "Hardening", "Faked RegQueryValueExA return");
    }
    else {
        ret = Old_RegQueryValueExA(hKey, lpValueName, lpReserved, lpType,
            lpData, lpcbData);
    }
    LOQ("psLB", "Handle", hKey, "ValueName", lpValueName,
        "Type", lpType, "Buffer", lpcbData, lpData);
    return ret;
}

If the malware sample tries to read a registry key with “SystemBiosVersion“, “Identifier” or “ProductId” in the value name, it will fail.

With these two changes, we have covered the two registry keys detections done by pafish. Then we have to change the call used to access the files.

The call used is GetFileAttributesA, which is not hooked by default, so we add it (hook_file.c):

/* Hardened */
HOOKDEF(DWORD, WINAPI, GetFileAttributesA,
  __in      LPCTSTR lpFileName
) {
    BOOL ret;
    if (strstr(lpFileName, "VBox") != NULL) {
        ret = INVALID_FILE_ATTRIBUTES;
        LOQ("s", "Hardening", "Faked GetFileAttributesA return");
    }
    else {
        ret = Old_GetFileAttributesA(lpFileName);
    }
    LOQ("s", "GetFileAttributesA", lpFileName);
    return ret;
}

After that, we have to compile our new cuckoomon.dll and replace the original.

You can find it in cuckoo/analyzer/windows/dll/cuckoomon.dll, you can replace it while cuckoo is running, no need to stop it.

And we are done, we have placed some measures to disallow the samples to detect our VM by using these functions. We can execute pafish again with our new cuckoomon.dll to check the results:

[pafish] Start
[pafish] Windows version: 5.1 build 2600
[pafish] Sandbox traced using mouse activity
[pafish] End

It only traced our VM by using the mouse activity, we could hook that too. We can also take a look at cuckoo log to see the responses faked by our hardened monitor:

"pafish.exe","620","532","registry","RegOpenKeyExA","SUCCESS","0x00000000","Registry->0x80000002","SubKey->HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0","Handle->0x0000003c"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Hardening->Faked RegQueryValueExA return"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Handle->0x0000003c","ValueName->Identifier","Type->0","Buffer->0x0022f64c"
"pafish.exe","620","532","registry","RegOpenKeyExA","SUCCESS","0x00000000","Registry->0x80000002","SubKey->HARDWARE\Description\System","Handle->0x00000040"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Hardening->Faked RegQueryValueExA return"
"pafish.exe","620","532","registry","RegQueryValueExA","SUCCESS","0x00000000","Handle->0x00000040","ValueName->SystemBiosVersion","Type->0","Buffer->0x0022f64c"
"pafish.exe","620","532","registry","RegOpenKeyExA","FAILURE","0x00000001","Hardening->Faked RegOpenKeyExA return"
"pafish.exe","620","532","registry","RegOpenKeyExA","FAILURE","0x00000001","Registry->0x80000002","SubKey->SOFTWARE\Oracle\VirtualBox Guest Additions","Handle->0x77c05c94"
"pafish.exe","620","532","filesystem","GetFileAttributesA","FAILURE","0xffffffff","Hardening->Faked GetFileAttributesA return"
"pafish.exe","620","532","filesystem","GetFileAttributesA","FAILURE","0xffffffff","GetFileAttributesA->C:\WINDOWS\system32\drivers\VBoxMouse.sys"

It is quite difficult to cover all functions used by malware to detect VMs, but with modifications in some common functions we can cover ~90% of the cases.

You can download the modifications made in this post from here, it is a patch compatible with the last stable version of the software. You can also download the compiled library, ready to use in your cuckoo installation.

It is well known that a big amount of malware samples are aware of the execution environment. This means that a malware sample can change his behavior if it detects that the running environment is unwanted.

There are resources, public source code, and even programs that detail how to bypass automatic malware analysis systems and make things awkward for malware researchers. Of course, these resources are quite useful for both researchers and malware developers.

We are going to take a look at some of these tricks, all found in real malware samples.

Also, just as they do, we have developed some yara signatures to detect these tricks that could be useful to differently process or classify these malware samples.

We could classify anti analysis tricks in three big groups:

- Anti Virtual Machine, that tries to detect if the execution environment is a known VM or emulator.
- Anti Debugging, that tries to detect if the program is running under the surveillance of a debugger.
- Anti Sandbox, that tries to detect known sandboxing products.

It is not unusual to find all kind of tricks in just one malware sample. For example, we can take a look at the sample 9255c75de8fbc20ee67f427397e1ef82:

Quickly we can find that it is looking for sbiedll.dll (to detect Sandboxie) and dbghelp.dll

It also opens the registry key HKLM\SYSTEM\ControlSet001\Services\Disk\Enum with value 0 to read the ID of the hard disk in the machine:

Then it is compared with these three strings (VIRTUAL, VMWARE, VBOX):

Finally, it opens the registry key HKLM\Software\Microsoft\Windows\CurrentVersion with value ProductId:

And checks it against these three known MS Windows products ID from different commercial sandboxes:

If we take a look at another sample (36527d5954bf3b2af60e6efa6398ccff), we will discover a canonical function to check this:

It checks the MS Windows product ID and if it is “76487-644-3177037-23510″, the function will return 1. Else, it will return 0. It also has the same function prototype to check keys “55274-640-2673064-23950″ and “76487-337-8429955-22614″.

This sample also uses MS Windows system functions to detect debugging.

It loads the function handler for IsDebuggerPresent using the function GetProcAddress() from kernel32.dll. Hey wait! And why not use IsDebuggerPresent() directly? Because it is noisy and easily detectable.

If it can not load the function or the function returns 0 (debugger not present), it will return 0. Else, it will return nonzero.

It also looks for files (SyserDbgMsg / SyserBoot) and (SICE / NTICE) using this function:

This trick is to detect both SyserDebugger and SoftICE debuggers.

As we said, we have published a ruleset of yara signatures to detect AntiVM, AntiDebugger and AntiSandbox procedures in malware samples. You can grab it in our GitHub repository here.

Capfire4 malware, RAT software and C&C service together

June 21st, 2012 | Posted by Alberto Ortega in Attacks | Malware - (3 Comments)

A big amount of the malware out there are RAT (Remote administration tool) samples. This is software created by people specialized on it, people that develop, improve and sell their tools. It  has capabilities that let the attacker spy on the victims with actions like screen capturing, keylogging, password stealing, command execution and remote access and controlling.

Their clients usually pay to gain access to the tools and additional services like support, zero or low antivirus detection, …

We are going to see a service we have been studying recently. Clients pay for the service and then they gain access to a web portal where they can generate personalized Trojans, manage the infected victims via the web browser and host the malware on their “cloud”.

Creators promote itself as a service to remote control computers and “recover passwords”.

It means that clients don’t have to mess with almost any technical issues, and they don’t need special skills or knowledge. The providers supply the tools, the hosting, and the Command and Control server.

When you login in your personal account you can see the main menu, tutorials and shortcuts.

The control panel uses HTTPS with a valid certificate.

Then you can create a new personalized malware (Trojan Horse) that will be generated in real time.

They take care of the antivirus detections for you. Created samples have a very low antivirus detection ratio (2/42).

Then the time to host the malware comes. Clients can choose between some fake domains that seem legitimate. The administrator of the service have bought two domains to create the fake subdomains.

cf.pro.br
as.bio.br

The domain whois data from the main website is hidden but the previous domains we mentioned are not. This way we can discover some information about the authors:

http://whois.domaintools.com/cf.pro.br


domain: cf.pro.br
owner: Pedro Henrique
ownerid: 401.407.278-92
country: BR
created: 20090510
changed: 20100713

Finally, once infected, you can easily manage your victims. You can perform remote control on the machine, password stealing, and command execution.

Uninstall software, Reboot, Logoff user, Kill process, Send DOS command, Download an execute file, Open web page.

If you need to infect more targets, you will have to pay for them.

Malware communication with the C&C is done using HTTP. For command execution they use other protocol from port 9000.

The C&C IP is from Brazil and always the same, which is included in our IP reputation database -> 174.142.93.226.

You can use the following rules to detect the communication traffic and command execution requests:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”MALWARE Capfire4 register machine”; flow:to_server,established; content:”GET”; depth:3; uricontent:”/registraMaquina”; content:”Host|3A| api|2E|capfire4|2E|com”; http_header; classtype:trojan-activity; sid:5000080; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”MALWARE Capfire4 update machine status”; flow:to_server,established; content:”POST”; depth:4; uricontent:”/updMaqStatus”; content:”Host|3A| api|2E|capfire4|2E|com”; http_header; classtype:trojan-activity; sid:5000081; rev:1;)

alert tcp $EXTERNAL_NET 9000 -> $HOME_NET any (msg:”MALWARE Capfire4 remote command execution”; flow:to_server,established; content:”|10|”; depth:1; content:”|14|”; distance:1; within:1; content:”.exe”; classtype:trojan-activity; sid:5000082; rev:1;)

alert tcp $EXTERNAL_NET 9000 -> $HOME_NET any (msg:”MALWARE Capfire4 remote kill process”; flow:to_server,established; content:”|10|”; depth:1; content:”|14|taskkill”; distance:1; within:9; classtype:trojan-activity; sid:5000083; rev:1;)

alert tcp $EXTERNAL_NET 9000 -> $HOME_NET any (msg:”MALWARE Capfire4 remote download and exec”; flow:to_server,established; content:”|10|”; depth:1; content:”|14|wget -c”; distance:1; within:8; classtype:trojan-activity; sid:5000084; rev:1;)

As a conclusion, we can mention that the ease to use frameworks to monetize malware is getting more and more popular on the Internet as they let people without technical skills to easily manage their victims.

CVE-2012-0158 vulnerability has been one of the main players in the information security scene during the last weeks. Since it was seen in the wild for the first time, attackers have been using it to break the security of specific targets.

We have been tracking one of these campaigns against one of the main steel industry corporations based in Japan. We will see how the attackers have been testing the exploits, starting the attack, and then improving it. All this just in a couple of days.

Since we can’t exactly determine where the attack comes from, we will see some evidences that could lead us to some conclusions.

One of the first samples found in the wild linked to this campaign is a specially crafted Microsoft Office file that uses CVE-2012-0158 to execute a malicious payload, then showing an embedded harmless MS Office file to the victim. All the other documents are very similar, but the payloads and the harmless documents are different each time.

The way to infect the targets is sending emails to specific key people in the organization.

Some of the harmless documents showed after exploitation are related to industrial products:

In this first sample the malicious dropped payload, named 0412test.exe, is a Microsoft Notepad binary from Windows XP Service Pack 2, Chinese Edition. This suggests that the attackers were doing the first tests in his own infrastructure to build the attack.

The next samples include malicious payloads that connect to a Command & Control server managed by the attackers, which is always the same IP. At this moment all the domains found point to 210.175.53.122, an IP address located in Japan.

The second sample found drops a Trojan Horse that connects to the C&C showing another Office document to the victim. This sample has a very reduced functionality. One interesting fact is the high antivirus detection ratio (23/42).

Analysis

The main feature of the next sample found is the antivirus detection ratio. Less than half than the previous one the day of the discovery (only 11/42). Now it has changed a bit.

Analysis

Finally, we found a sample with much more capabilities that the previous ones. It is more focused on stealing user credentials and retrieve internal information from the affected systems. It reads saved login credentials from Mozilla Firefox browser and hooks some Windows user inputs to collect information.

It also has two internal IP ranges (192.168.20.1-62, 10.18.104.88-245) hard-coded in the source code.

The antivirus detection ratio has decreased. The day of the discovery only 6/42 antivirus detected the threat. At the time of writing it is detected by five more.

Analysis

Each sample connects to one of the following domains, like we previously mentioned, all are pointing to the same IP.

touber.lagga.net
nasa.yorli.net

munite.vazuki.com
unbye.sqehom.com
tprovty.igekng.com

ernet.afywis.com
oeoe.yetrap.com
lence.kovmir.com

We will probably see more attacks as part of this campaign, with more advanced payloads. We’ve added the C&C IP address to our IP Reputation Database, and we will monitor these C&C servers to detect new threats coming from them.