Before startintg with the post, i would like to refer to you to the TalosIntelligence analysis of a previous variant of Konni. New variant is similar to the variant analyzed in Talos post. However there are some different things. In addition i reversed different parts of the code, and i give other details. For this reason i recommend reading both posts if you are interesting in having a good knowledge about this RAT.
Modules
We have the sample f4abe28f3c35fa75481ae056d8637574. It is a dropper that is able to drop different PE files depending on the architecture (32 / 64). If we unpack the dropper we can find it has two PE files and two DOCX files into resources:
Docx file1: 63a43fe8874fbbf3adb1b9aeb03adb6bfaa2935a40bb1893e90e3ab762dd44bd
Docx file2: a12db66cb7b7b991ac2ba736fb48e04566ffd2defdcb08fb9a8ab3781253f73c
PE file1: 290b1e2415f88fc3dd1d53db3ba90c4a760cf645526c8240af650751b1652b8a
PE file2: 8aef427aba54581f9c3dc923d8464a92b2d4e83cdf0fd6ace00e8035ee2936ad
PE files are packed with ASPack v2.12.
We will analyze the 32 bit version.
RAT module
The 32 bits rat module is installed into this folder:
C:\Users\<user>\AppData\Local\MFAData\event\errorevent.dll
And the Run registry key is modified:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
“RTHDVCP”=”rundll32.exe C:\\Users\\javi\\AppData\\Local\\MFAData\\event\\errorevent.dll check”
After removing the ASPack v2.12 layer, we take a look into the malware with IDA.
The malware installs a windows hook and because of this, the errorevent.dll is loaded into machine’s running processes:
In the SetWindowsHookEx callback, it logs and queues keyboard events together with the window where they happened. Another thread analyzes the keyboard events, and it keeps to a file events happened in browser processes:
It checks these processes names:
Interesting keyboard events are logged to the file:
C:\Users\<user>\AppData\Local\Packages\microsoft\debug.tmp
Other files are used by the RAT in the process of managing commands:
Malware dll is injected into multiple processes. To monitor what malware files are created and written we can use this breakpoint with instructions (it is splitted in multiple lines for better reading):
bp NtWriteFile -> when NtWriteFile hit, execute the next script
“.foreach (tok { !handle (poi (esp+4)) }) -> search “Packages” in the path
{
.if ($spat(\”${tok}\”, \”*Packages*\”) != 0)
{
da (poi (esp+18));.break; -> if found, print the data written
}
};g;”
bp NtWriteFile “.foreach (tok { !handle (poi (esp+4)) }) { .if ($spat(\”${tok}\”, \”*Packages*\”) != 0) { da (poi (esp+18));.break;}};g;”
The other RAT functionality is executed under demand, as we will see it in the next section about communications.
Communications
The malware executes a thread for communications with the CnC. It asks for commands each 15 minutes. A file with commands is downloaded and parsed, and the commands are executed (and the results uploaded to the CnC):
The RAT calculates a value based on the installation time and infected computer info, and that value is used as bot_id to identify the current infected machine. In my case it generated CB5D234D.
To download the commands it connects by http GET to:
http://member-daumchk.netai.net/weget/download.php?file=CB5D234D_dropcom
It is:
http://<domain>/weget/download.php?file=<bodid>_dropcom
This new variant uses wininet api to connect CnC (Talos analysis about the previous variant says the RAT was using winsock api connect, send, recv,… instead of http specified api):
After downloading the commands they are decrypted (key “xzxzxz”) and parsed:
The decryption function:
Seeing the communications code, it seems it would be not difficult to create a fake CnC to control a bot (not RSA keys or something like that are used to certify the command comes from the author).
Once decrypted it starts to parse commands:
Command for collecting computer info
With this command the malware collects different information about the machine:
Command for screen capturing
Capture of the screen it is done here:
No comments:
Post a Comment