Recently we came across a new sample of the ArdBot malware, appearing on kernelmode, credited to R136a1.

A research of this sample showed a malware strain that is not yet ready for production use and provided an interesting peek inside a malware’s development process.

Initial Observation

The malware comes as an executable file with no icon. It weighs about 60KB.

As always, this file can be run in many ways to infect a system.

Executing the file displays a message box saying “Entry”, then another one saying “Entry 2”, a third one saying “Injected”.

Closing the last message box shows the Windows application error message – a crash of Explorer.exe (on access violation error, 0xc0000005), followed by an automatic restart of the latter.

Showing messages to the user is of course strange for standard malware which strive to be as stealthy as possible. Crashing processes on the infected system is more of a proof that this malware is not yet fully “baked”.

Packing and Protection

At the initial stages of analyzing the malware we can tell that it is packed and the installer unpacks a new executable and writes it to disk. The new executable would not run without fixing its headers. It also has an interesting characteristic: although being a normal .exe image it has exported entries, like DLLs usually have.
These will be used later for searching specific functions by the bot in its own executable.

The export table shows us the original module name as compiled by the authors – “ArdBot”.

The packing mechanism was simple enough to overcome by itself and could have been skipped altogether, but between the lines it tells us something important about the authors who probably created this mechanism themselves from scratch rather than using a commercial or freeware packers. While commercial packers provide better protection for the packed software against analysis they also tend to raise suspicion and thus detection rate by security products. It is possible that the creators of ArdBot decided to compromise on anti-analysis in favor of trying to avoid detection.

Anti-debugging was nowhere to be found and allowed full analysis with a normal user-mode debugger at all stages.

Process Injection

As is common with Windows malware, this sample injects code into Windows’ explorer.exe.

The injected routine is responsible for the message box saying “Injected” and is also the cause of the crash of the process.

Injection stages include:

1. Searching for “explorer.exe” in the list of open processes.
   Using APIs: CreateToolhelp32Snapshot, Process32First and Process32Next.

2. Opening a handle to the process.
   Using API: OpenProcess.

3. Finding a thread that belongs to the target process.
   Using APIs: CreateToolhelp32Snapshot, Thread32First and Thread32Next.

4. Mapping a new section in the remote process.
   Using APIs: NtCreateSection and NtMapViewOfSection.

5. Suspending all threads in the process.
   Using API: NtSuspendProcess

6. Hooking the GetMessageW function and replacing its code.
   Using API: VirtualProtectEx and NtWriteVirtualMemory

7. Sending a message to all of the windows in the target process.
   Using APIs: EnumWindows, GetWindowThreadProcessId and PostMessageW

8. Resuming the previously suspended threads.
   Using API: NtResumeProcess

9. The injected code creates a new thread.
   Using API: CreateThread

10. The injected code also replaces the code of GetMessageW back to the original code.

Notice that a remote thread was created in explorer.exe but at no point did the malware call the CreateRemoteThread API which is provided by Windows and is widely used by malware and picked up by many security solutions.

At some later point, explorer indeed crashes.

Fixing the Crashing Code

At the previous stage we found out that the injection mechanism is in good shape and the code does run in the context of explorer. The crash happens at a later time where the code copies a buffer from one memory page to another and tries to read past the end of the source page. Patching this little bug allowed the malware to run.

Installation and Persistence

The malware installs itself in %appdata%, under a new folder named “Flash”.
%appdata% folder also contains the bot’s log files

A registry key is added to the autorun path in the registry.

Persistence is maintained by a protector thread that runs every second and continuously searches for the registry key and executable file combination.
If either one is deleted – it will recreate it.

Removal

The mentioned protector thread detects deletion of the file or the key, however it does not examine their contents.

Overwriting either of these with anything else and restarting explorer.exe will effectively remove ArdBot from the system.

Configuration and Communication

ArdBot comes with a configuration data embedded in the binary. This can also be updated by the C&C server. This data is encrypted in 2 stages. Similar to the packing algorithm, the one used for decryption is simple enough to overcome or skip but again tells us that the authors had encryption in mind and did not want to use external libraries, APIs or known methods.

Configuration contains a few parameters that have to do with the malware’s behavior (communication frequency and sleep times) and a list of servers with which it shall communicate.

Our particular sample communicates with “localhost” – the local machine, suggesting that the authors had the C&C server installed on the same machine they use to test the malware itself. Communication is done using HTTP over a non-standard port.

APIs used for communication:
WinHttpOpen, WinHttpConnect, WinHttpOpenRequest, WinHttpSendRequest, WinHttpReceiveResponse, WinHttpQueryDataAvailable WinHttpReadData and WinHttpCloseHandle.

Commands and Capabilities

These commands are recognized by ArdBot:

1. Remove itself
2. Download a binary file and execute it
3. Download a binary file and execute it in memory
4. Add a C&C server address
5. Start Internet Explorer
6. Flood a host with HTTP GET requests, TCP packets or UDP packets.

Conclusion and Thoughts

This research focuses on a malware that is definitely in its early stages, a development or testing version, if you will. This version probably wasn’t supposed to come to light in its current state.
Its ability to cause damage is still in doubt, its encryption methods are simple and although protection mechanisms exist, they are easily defeated. Its capabilities are mainly a Launchpad for installation of other malware into the infected system rather than being a full-blown malware. However it is safe to assume that more work will be put into this program by its authors and we will likely see it appear in the wild somewhere in the future.

The post ArdBot: A Malware Under Construction appeared first on Breaking Malware.