• Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg
  • Delicious

Anti-Malware Laboratory

Yet Another Malware Blog

About

An informal blog from your friendly neighborhood software security humans.

Blog Archive

  • ▼  2015 (5)
    • ▼  October (1)
      • Another Macro Script Technique in Executing Malware
    • ►  August (2)
    • ►  May (1)
    • ►  March (1)
  • ►  2014 (8)
    • ►  October (1)
    • ►  July (1)
    • ►  June (1)
    • ►  May (4)
    • ►  April (1)
  • ►  2013 (12)
    • ►  December (3)
    • ►  November (5)
    • ►  August (2)
    • ►  March (2)
  • ►  2012 (35)
    • ►  April (4)
    • ►  March (12)
    • ►  February (17)
    • ►  January (2)

Categories

adobe (1) android (10) android february (1) baksmali (1) Black Hole (2) crimepack (1) disassembler (1) exploit (3) Exploits (4) Fakeav Winrar sfx (1) Fishbowl (1) flash (1) gift certificates (1) Google Authenticator (1) google play (1) hcp (1) java (1) Malware (5) mdac (1) Mobile (24) NSA Mobility Program (1) obfuscated script (1) pdf (1) Reversing (2) rhino (1) skype (1) smali (1) spam (1) test (1) Unpacking (1) vouchers (1) vulnerability (3)

Popular Posts

  • Bank of America spam: An Analysis
    An email claiming to be from Bank of America lures users to open an attachment that shows how to open secure emails from the bank. The mess...
  • [BE CAUTIOUS] Dragon Ball Z: Resurrection of F MALWARE and SCAM
    Be wary of downloading movies in torrent sites.  Executables can also be executed with a file size as huge as a gigabyte...
  • Unpacking MFC Compiled CryptoWall Malware
    Unpacking MFC Compiled CryptoWall Malware Introduction First and foremost, this article does not intend to analyze what CryptoWall malw...

Visitors to this blog

Thursday, May 1, 2014

Native Vobfus Malware

Posted on Thursday, May 01, 2014 by Unknown | No comments

ANALYSIS

VOBFUS – stands for VB Obfuscated malware, is a Visual Basic compiled (pseudo code or native code) malware that demonstrates obfuscation techniques with the purpose of eluding signature based detections by most antivirus softwares.

The sample being analyzed (a5e979799c725b45c39cfe87257107d2) is native code compiled. Let’s skip all the obfuscation techniques and focus on what the actual vobfus malware does.

At some point after the malware’s self-de-obfuscation in memory, a call to MSVBVM60.rtcStrConvVar2 API will be performed and the actual vobfus strings (in Unicode format) will be revealed. Based solely on the revealed strings, we can now at least have a vague idea on what it does or what it will do.

The malware uses MSVBVM60.DllFunctionCall in order to execute Windows API functions (APIs like CreateToolhelp32Snapshot, GetDiskFreeSpaceExW, GetUserNameW, etc.).

The figure below demonstrates how kernel32.sleep is traversed using MSVBVM60.DllFunctionCall.

First and foremost, it will gather information about the system like username, logical drives, drive types, and disk free space. It will create a mutex named “A” upon execution.

Vobfus will create a copy of itself as %USERPROFILE%\<RandomFileName>.exe with file attributes set to READONLY, HIDDEN, and SYSTEM and proceeds to execute it.

Using CreateToolhelp32Snapshot, Process32First and Process32Next APIs, it will search thru running processes and monitors for the presence of strings such as “task” (for task manager) or “proc” (for process explorer). When found existing, it will prevent users from manually closing the malware by hooking to TerminateProcess and TerminateThread APIs loaded into task manager or process explorer so that when this APIs are triggered, it will just do nothing. It does this by using WriteProcessMemory API and replaces the first byte of TerminateProcess and TerminateThread API to 0xC3 (RETN).

It then creates its REGRUN entry to ensure activation every system startup.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run] “<RandomFileName>” = %USERPROFILE%\<RandomFileName>.exe.

It disables windows update by adding this registry entry [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU] “NoAutoUpdate” = dword:00000001.

It will also set the folder settings to hide system files (files with properties set to SYSTEM) in order to conceal the malware away from easy inspection. It does this by modifying the registry [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] “ShowSuperHidden” = dword:00000000 (from dword:00000001).

It then attempts to connect to the following sites (sending the information gathered earlier) and may attempt to download an updated copy of itself.
·         ns1.player1352.com
·         ns1.player1352.net
·         ns1.player1352.org

It will also try to copy itself into removable drives like floppy, USB, etc. with filenames such as Passwords.exe, Porn.exe, Secret.exe and Sexy.exe. An autorun.inf file will also be created in the removable drive that will point to the malware copy in order to automatically execute it when the drive is mounted. A file x.mpeg may also be created but with 0 bytes in size.

It also modifies/updates ICON resource section of the files Passwords.exe, Porn.exe, Secret.exe and Sexy.exe in an attempt to avoid CRC signature based detection of some antivirus softwares.

MANUAL REMEDIATION

In order to successfully restore the system, first and foremost is we have to find a way on how to kill the vobfus malware running as a process. Remember that vobfus monitors for running processes with names having “task” or “proc” and when found, will hook TerminateProcess and TerminateThread that successfully prevents task manager or process explorer’s ability to terminate processes. So, to solve this problem, we can actually trick the malware by renaming process explorer’s executable to any name as long as it does not contain “task” or “proc” keywords.

To put it in steps:
1. Rename procexp.exe to 1.exe.
2. Run 1.exe (copy of procexp.exe).
3. Terminate vobfus malware in memory.
4. Delete the following registry entries using regedit:
a. [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run] “<RandomFileName>” = %USERPROFILE%\<RandomFileName>.exe
b. [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU] “NoAutoUpdate” = dword:00000001
5. Modify the following registry entry using regedit:
a. [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] “ShowSuperHidden” = dword:00000000 (from dword:00000001 to see hidden system files in explorer.)
6. Manually delete copies of malware found in %USERPROFILE%\<RandomFileName>.exe and removable drives including the created autorun.inf, x.mpeg, Passwords.exe, Porn.exe, Secret.exe and Sexy.exe.
7. As a recommendation, run a full system scan using Vipre to completely remove possible remnants of the malware.

SUMMARY

Platforms:  WINXP, WIN7, WIN8 x64
File-type: Win32 PE
Malware-type: WORM
Vtest first seen date: 12/31/2013 02:58
Vipre detection name: Trojan.Win32.Generic!BT
Installation
Dropped files
  • %USERPROFILE%\<RandomFileName>.exe (copy of malware)
  • Adds copy of itself to removable drives (including floppy A:\) and may have filenames such as Passwords.exe, Porn.exe, Secret.exe, Sexy.exe
  • Creates autorun.inf file in removable drives and points to malware copy
  • May create x.mpeg file in removable drives with 0 bytes

Registry
Added registry
  • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run] “<RandomFileName>” = %USERPROFILE%\<RandomFileName>.exe - to execute vobfus at system startup
  • [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU] “NoAutoUpdate” = dword:00000001 – to prevent windows update on system

Modified registry
  • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced] “ShowSuperHidden” = dword:00000000 (from dword:00000001) – to hide vobfus dropped copy from users

Memory Residency
Invoked processes: %USERPROFILE%\<RandomFileName>.exe (malware dropped copy)
Backdoor/Bot/Stealer
Communicates to/from
  • Attempts to connect to ns1.player1352.com
  • Attempts to connect to ns1.player1352.net
  • Attempts to connect to ns1.player1352.org

Propagates
Method of spreading: copies itself into removable and mapped network drives.
General Malware
Summary of payload
  • drops malware copies to removable and mapped network drives
  • modifies TerminateProcess and TerminateThread APIs loaded in task manager or process explorer to prevent them from terminating vobfus malware
  • may attempt to connect to outside address in order to download updated copy of itself

Pertinent APIs used
advapi32
CloseHandle
connect
CreateToolhelp32Snapshot
GetDiskFreeSpaceExW
GetDriveTypeW
GetFileAttributesW
GetLocaleInfoW
GetLogicalDrives
GetLogicalDriveStringsW
CreateMutexW
GetModuleHandleW
GetUserNameW
ExitProcess
htons
InternetCloseHandle
InternetOpenUrlW
InternetOpenW
InternetReadFile
kernel32
OpenProcess
Process32First
recv
shell32
ShellExecuteW
SHGetSpecialFolderPathW
Sleep
socket
TerminateProcess
user32
wininet
WriteProcessMemory
WSAAsyncSelect
WSAStartup
ws2_32
RegCreateKeyExW
RegSetValueExW
RegCloseKey
What makes it unique: Visual Basic compiled and obfuscation techniques

Read More

Monday, April 28, 2014

DISSECTING KULUOZ

Posted on Monday, April 28, 2014 by Unknown | No comments

Introduction

Kuluoz, or commonly known as Asprox by some antivirus vendors, is a Trojan botnet that is usually distributed thru spam emails.
This variant of kuluoz was first seen in our malware database on the 4th of April 2014.
Kuluoz imitating a word document

It spoofs the icon of a Microsoft Word document in an attempt to fool the user in executing it.

The most common and obvious indicators of compromise (IOC) of kuluoz on an infected system are:
·         Presence of an 8-lowercase-random filename with a word document icon located in %USERPROFILE%\Local Settings\Application Data
Kuluoz in %USERPROFILE%\Local Settings\Application Data
·         Presence of an autorun entry located in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run pointing to the botnet’s executable image
·          An SVCHOST.EXE process can be seen running under Explorer.exe
Copy of SVCHOST.EXE injected with kuluoz

Breaking Into Bits and Pieces 

UNPACKING ROUTINE:

The unpacker section of kuluoz needs to meet two conditions in order to properly continue its execution.

First is the existence of “HKEY_CLASSES_ROOT\ typelib\{640d3148-a423-11d2-b943-00c04f79d22f}\1.0” in registry. If not found, it self terminates.
Checks for a specific registry entry

And second, the height of the target machine’s full screen window on the primary monitor in pixels should be greater than 500 pixels.
Checks screen height if greater than 500 pixels

Then what happens if the height of the window falls short of 500 pixels? A debug exception occurs, and again the Trojan terminates.

As a reader you might ask, "What is the purpose of kuluoz doing these two checks?". Simple answer, kuluoz assumes that by calling these fake APIs some antivirus engines may fail in emulation, thus successfully bypassing its heuristic/generic detections.

An encrypted data within its body (starting at 0x40F003) with a size of 0x12300 bytes is then copied and decrypted in memory using VirtualAlloc. After which, execution is then transferred.

It then gets the image base of kernel32.dll by parsing its value in Win32 Thread Information Block (TIB). In turn, it then populates its API table based from the image base of kernel32.dll.

The following imported APIs that are to be populated are listed below.
VirtualAlloc
UnmapViewofFile
VirtualProtect
LoadLibraryExA
GetModuleHandleA
CreateFileA
SetFilePointer
WriteFile
CloseHandle
GetTempPathA
lstrenA
lstrcatA

Once again, it will make use of VirtualAlloc to allocate a memory region for itself to copy and decrypt a part of its code. This time the data that is decrypted in memory contains an MZ-PE header.
An MZ-PE file copied and decrypted in memory
               
It then proceeds to fix the import table of the said PE file in memory and looks for the values of the following APIs that it needs to use:
WaitForSingleObject
CreateEventA
VirtualAlloc
CreateProcessA
GetProcAddress
GetModuleHandleA
CloseHandle
ReleaseMutex
TerminateProcess
GetCurrentProcess
GetLastError
CreateMutexA


This newly decrypted PE file is then overwritten to the memory region of the original executable before transferring execution.

You can dump this into a new file and we have successfully created an unprotected version of Kuluoz!

PROCESS INJECTION (INJECTING THE MODULE):

Kuluoz creates a mutex name of “2GVWNQJz1” to prevent duplicate process of it running in memory.
“2GVWNQJz1” as mutex name

It then proceeds to gather all the necessary APIs that it needs, which are listed below:
NtQueryInformationProcess
ZwReadVirtualMemory
ZwMapViewOfSection
NtCreateSection
ZwUnmapViewOfSection
ZwResumeThread

Next it will inject a portion of its dll code to a normal process “SVCHOST.EXE”.
By doing so, kuluoz successfully made itself to stay memory resident unknowingly to the user.

I will explain in detail how this process injection is done.

First, it spawns a suspended process of svchost.exe in memory using CreateProcessA.
Create suspended process of svchost.exe

Next, it will create a memory section using ZwCreateSection and maps a section location using ZwMapViewofSection in order to copy portion of its code into memory address 0x00090000.
A portion of kuluoz code copied in memory

Then it allocates another memory region to copy svchost.exe data in memory using ZwReadVirtualMemory.
svchost.exe copied in memory

It then traverses the entry point for svchost.exe in memory and overwrites it with the following instructions in order to jump to its malicious code.
Entry point of svchost.exe overwritten to point to malware code

Bingo! From the image above we can see that kuluoz wants to execute at memory space 0x00090000, which in truth holds its malicious routines that was mapped earlier.

After that, it will recopy all the changes done to svchost.exe into another memory region before unmapping, effectively saving all the modifications done to svchost.exe that is loaded in memory.
It then makes use of CreateEventA to create an event with a string name of “y76gDDb3”.

After which, the suspended process of svchost.exe is resumed by calling ZwResumeThread.

GETTING TO “WORK” (WHERE THE FUN STARTS!):

Let’s analyze the code injected at svchost.exe shall we?
Kuluoz code is located at 0x00090000.

It starts off by traversing Process Environment Block (PEB) to obtain the image base address of kernel32.dll and get to its export table.

A more detailed explanation on how it was done is seen in the image below.
Traversing PEB to get to kernel32.dll exports

It gets to the list of module names and compares it against a hash of kernel32.dll which is 0x6A4ABC5B. This little code of “walking” the PEB to get to kernel32.dll has also been used by other malwares such as Zeus.

It looks for GetProcAddress function and uses it to get function addresses of GetModuleHandleA, LoadLibraryA, ExitProcess, and VirtualAlloc in kernel32.dl, and memset, memcpy and _stricmp in ntdll.dll.

It then continues to get addresses of the following APIs:
For KERNEL32.Dll:
OpenProcess
HeapCreate
CreateMutexA
GetLastError
GetCurrentProcess
TerminateProcess
WideCharToMultiByte
OpenEventA
GetSystemTimeAsFileTime
GetCurrentProcessId
DeleteFileA
Sleep
GetFileInformationByHandle
ReadFile
SetEvent
ResumeThread
CreateProcessA
CreateFileA
WriteFile
CloseHandle
GetProcessHeap
HeapAlloc
HeapFree
GetModuleHandleA
GetTickCount
VirtualAlloc
VirtualFree
LoadLibraryA
GetProccAddress

For ADVAPI32.DLL:
CryptDestroyHash
CryptEncrypt
CryptCreateHash
CryptHashData
CryptVerifySignatureA
RegDeleteKeyA
RegCreateKeyA
RegSetValueExA
RegOpenKeyA
RegEnumKeyExA
RegEnumValueA
GetUserNameA
LookUpAccountNameA
RegOpenKeyExA
RegQueryValueExA
RegCloseKey
CryptAcquireContextA
RegDeleteValueA
MD5Init
MD5Update
MD5Final

For SHELL32.DLL:
SHGetSpecialFolderPathA

For OLE32.DLL:
CoInitialize
CoCreateInstance

For WS2_32.DLL:
WSAStartup
WSACleanup
inet_addr
inet_ntoa

For WININET.DLL:
InternetCloseHandle
InternetReadFile
HttpSendRequestA
HttpOpenRequestA
InternetConnectA
InternetOpenA

For MSVCRT.DLL:
free
malloc
memset
wcstombs
_wcsicmp
mbstowcs
memcpy

For CRYPT32.DLL:
CryptImportPublicKeyInfo
CryptStringToBinaryA
CrypteDecodeObjectEx

Using VirtualAlloc, it will allocate memory space for itself to copy stubs of it code using memcpy.
Work Function copied in memory

These code stubs belongs to its kuluoz dll exported function named “Work” which is subsequently called after.

SO WHAT’S INSIDE?:

Inside of “Work” module, the Trojan uses again GetProcAddress to get the addresses of the following APIs.
_stricmp
strcat
strlen
strcpy
sprintf
sscanf
memset
memcpy
NtQueryInformationProcess
ZwReadVirtualMemory
ZwMapViewOfSection
NtCreateSection
ZwUnmapViewOfSection
ZwResumeThread

After everything is now properly setup first thing that it does is to get the user name of the account that is currently logged on to Windows by using GetUserNameA and retrieves its equivalent Security IDentifier (SID). It then checks for the installation date of Windows in registry located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ “InstallDate”.

All these data gathered are then transformed to its MD5 hash equivalent using MD5Init, MD5Update and MD5Final functions. The MD5 hash is used as a unique ID by the bot in order to be identified by a C2 server.

Each time it attempts to make a network request to a C2 server (Command-and-Control), it enumerates all the keys found in HKEY_CURRENT_USER\Software and decrypts their values and compares to the string “You Fag!!!!!”. If it matches, the data after the string you fag is translated as an in_addr struct.

It then contacts the C2 server by generating an IP address either thru registry (as stated above) or by using a hardcoded IP address that is encoded using RC4 encryption with a hardcoded key.

It will use the following request headers in contacting the C2 server as an example.

Where “67454D7C3015100394CEF4D903E2D5DDDB1FA83AD0” is the unique ID generated by hashing user account name, SID and operating system installation date and “Host: 213.21.158.141:443” is the IP address of the C2 server that was generated either thru registry or hardcoded in the malware body.
Request header of kuluoz
The content sent by kuluoz to a C2 server follows the following XML encapsulation format.
<knock><id>%s</id><group>%s</group><src>%d</src><transport>%d</transport><time>%d</time><version>%d</version><status>%d</status><debug>%s</debug></knock>

Where:
Knock = xml top element
Id = Id string
group = group id string
src = presence of analysis tools or sandbox strings
transport = reports if kuluoz is running from a removable drive or not
time = time stamp
version = bot version
status = status of last command
debug = OS version and type

It checks for the presence of the following malware analysis tools window names and registries and places the result in <src></src> in its knock data.

FOR WINDOW NAMES:
wireshark.exe
Tfrmrpcap
iptools.exe
Iris - Version 5.59
ProcessLasso_Notification_Class
TSystemExplorerTrayForm.UnicodeClass
PROCMON_WINDOW_CLASS
PROCEXPL
WdcWindow
ProcessHacker
99929D61-1338-48B1-9433-D42A1D94F0D2-x64
99929D61-1338-48B1-9433-D42A1D94F0D2-x32
99929D61-1338-48B1-9433-D42A1D94F0D2
Dumper
Dumper64
APISpy32Class
VMwareDragDetWndClass
VMwareSwitchUserControlClass
vmtoolsd.exe
prl_cc.exe
prl_tools.exe
SharedIntApp.exe
VBoxTray.exe
VBoxService.exe
vmusrvc.exe
vmsrvc.exe

FOR REGISTRY:
HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\\services\\Disk\\Enum 0=VMware
HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\\services\\Disk\\Enum 0=PTLTD
HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\\services\\Disk\\Enum 0=Virtual
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemProductName=VMware
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemProductName=PTLTD
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemManufacturer=VMware
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemManufacturer=PTLTD
HKEY_LOCAL_MACHINESYSTEM\\CurrentControlSet\\Enum\\PCI\\VEN_15AD&DEV_0774&SUBSYS_040515AD&REV_00
HKEY_LOCAL_MACHINESYSTEM\\CurrentControlSet\\Enum\\PCI\\VEN_15AD&DEV_0774&SUBSYS_074015AD&REV_00
HKEY_LOCAL_MACHINESYSTEM\\CurrentControlSet\\Enum\\PCI\\VEN_80EE&DEV_CAFE&SUBSYS_00000000&REV_00
HKEY_LOCAL_MACHINE\HARDWARE\\ACPI\\DSDT\\PTLTD__
HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\\services\\Disk\\Enum 0=Virtual
HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\\services\\Disk\\Enum 0=PRLS
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemProductName=Virtual
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemProductName=PRLS
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemManufacturer=Virtual
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS SystemManufacturer=PRLS
HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\\services\\Disk\\Enum  0= VBox
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS\ SystemProductName = VBox
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS\ SystemManufacturer=VBox
HKEY_LOCAL_MACHINE\HARDWARE\\ACPI\\DSDT\\VBOX__
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS\ SystemProductName = AMIBI
HKEY_LOCAL_MACHINE\HARDWARE\\DESCRIPTION\\System\\BIOS\ SystemManufacturer = AMIBI
HKEY_LOCAL_MACHINE, "SYSTEM\\CurrentControlSet\\Enum\\PCI\\VEN_5333&DEV_8811&SUBSYS_00000000&REV_00
HKEY_LOCAL_MACHINE, "SYSTEM\\CurrentControlSet\\Enum\\PCI\\VEN_80EE&DEV_BEEF&SUBSYS_00000000&REV_00
HKEY_LOCAL_MACHINE, "SYSTEM\\CurrentControlSet\\Enum\\PCI\\VEN_80EE&DEV_CAFE&SUBSYS_00000000&REV_00
HKEY_LOCAL_MACHINE, "HARDWARE\\ACPI\\DSDT\\AMIBI

It uses the following RSA public key certificate (which is found embedded in its body) to encrypt data before sending over a secure shell.
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCUAUdLJ1rmxx+bAndp+Cz6+5I
Kmgap2hn2df/UiVglAvvg2US9qbk65ixqw3dGN/9O9B30q5RD+xtZ6gl4ChBquqw
jwxzGTVqJeexn5RHjtFR9lmJMYIwzoc/kMG8e6C/GaS2FCgY8oBpcESVyT2woV7U
00SNFZ88nyVv33z9+wIDAQAB
-----END PUBLIC KEY-----

After sending encrypted data to a C2 server, it will attempt to acquire a list of current IP addresses and ports of other possible C2 servers to ensure its continuity in communicating to the REAL C2 server (the mother) accompanied by commands issued by the C2.
Communicating with a C2 Server

A sample of a response header is seen below.
Response Header from C2 Server
As seen from the image, the server it connects to is of type nginx which is only a proxy server.
A list of possible proxy servers that I have acquired is listed below:
1.234.53.27:443
213.21.158.141:443
27.54.87.235:443
27.54.87.235:443

The commands are sent also by using the following knock data format
<knock><id>67454D7C26333FBA5B5169311188D3A7</id><task type="idl" /></knock>

Where:
task type = the command sent by C2 server

A list of possible commands are:
idl = Long sleep
rdl = download and run kuluoz module
run = download .exe, install and run
rem = remove kuluoz module from the system
red = update registry keys
upd = update kuluoz.exe


Read More
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)
volute-glacial
volute-glacial
volute-glacial
volute-glacial
Copyright © Anti-Malware Laboratory | Powered by Blogger
Design by Fabthemes | Blogger Template by NewBloggerThemes.com