Debian Honeywall howto

Abstract

This howto will describe how to set up a honeywall acting like a hidden gateway typically used to secure a honeynet environment from an production environment. Operating system used in this article is Debian 6.0 installed as a vm-guest.

Introduction

Honeynets are designed to get a better understanding of how an attacker exploits vulnerabilities on a network-device and to develop a better knowledge in the latest security threats.

Vulnerable devices in a honeynet, commonly called honeypots, are intentionally set up to be vulnerable to many different attacks, or by using a clean install of an OS and wait for an attacker to perform probes and hopefully perform unknown attacks on a system. The latter is often referred to as High Interaction Honeypots, while emulating services often is called Low Interaction Honeypots.

A honeywall is a hidden device acting like a bridge between different networks and are commonly used to seperate a honeypot from an production environment, with the capabilities of controlling data sent in and out as well as monitoring network traffic. It can also be used to analyse traffic during a live malware analysis to mention a few of its workspaces. The honeywall is a crucial device in a honeynet to get as much information regarding malicious activity - both before and during an actual attack.

In order to secure a honeynet network, Honeynet Project has developed several standards and requirements regarding honeynets such as data control, data capture and data collection to lower the risk of exploitation of the production environment.

You can read more about honeynet's here and to meet the requirements I followed “Honeynet Definitions, Requirements, and Standards”.

Environment

To meet the requirements in a honeynet there are several things one should keep in mind:
First the honeywall it self need three Network Interface Controllers (NIC), one connected to the external network (Router -> Internet) and one connected to the internal network (honeynet).
These two NIC's are setup as a hidden bridge, so there will not be assigned any IP-addresses to them.

Therefor to remotely control this honeywall we need another NIC for remote-management, to easily administer and get wanted information provided by the honeynet.

NICs

• eth0 - Bridged - External network (internets)

• eth1 - Vboxnet1 - Internal network (honeypots)

• eth2 - Vboxnet0 - Remote management (safe network)

Data Control

Once the attacker has gained access to your honeypot one need to prevent attacks on unwanted devices, such as your production network and external devices outside your own network (eg. the internets ). To prevent this we use at least two layers of protection, as described in the "Definitions, Requirements & Standard"-link above.

To control the network-flow we will use

• IPTables as firewall with connection limit.
• Snort as Intrusion Prevention System (IPS) to drop malicious packets.

Data Capture

To capture probes, malicious activity and other information on the honeynet we need to set up logging capabilities.

• TCPDump to capture all network traffic.
• IPTables logging to capture conditions met by firewall rules.
• Snort as Intrusion Detection System (IDS) to log malicious network traffic.
• P0f to identify host information like applications and OS based on network packets.

Download the howto from google drive.

A botnets compromise - Pt 2

After i unpacked h2.exe i was able to do static analysis and get a good understanding of what was going on without execute the file. It has various tricks to obfuscate the malware and made analysis harder. When executed it will connect to an irc server, join a channel and await further orders which are typical for RAT or a bot if you want.

h2_unpacked.exe

md5sum: 8359679bbfedeb343f105a1490b992ef
sha1sum: dcc583732e7e00a8f64e873bea6445742d9cd7f2


Imports:
KERNEL32.DLL: lstrcmpiA, GetProcAddress, ExitProcess, GetSystemTime, GetTickCount, lstrlenA, GetCurrentProcess, LoadLibraryA, CloseHandle,

ADVAPI32.dll: LookupPrivilegeValueA, AdjustTokenPrivileges, OpenProcessToken,

Based on the imports-table we could expect some sort of process injection as it use LookupPrivilegeValueA, AdjustTokenPrivileges, OpenProcessToken from the ADVAPI32 library.

When i first ran strings utility i got a pretty good idea of what was going on but those findings didn't add up with the imports-table above. Based on the output i would expect the malware to use privilege escalation with SeDebugPrivilege and that the bot has the ability to flood. Further on we could expect persistence by hiding it self somewhere on the harddrive with the name avmngs.exe. It will also connect to a domainname as shown in the picture below. And again, since the imports table looks quite incomplete one should lookout for  decryption loop to import library functions.




When i opened the file in IDA Freeware i found privilege escalation with SeDebugPrivilege and a Decryption loop to get encoded library strings. It calls the decryption loop with "f424" as argument. Below we can see the difference before it decrypt library names and after.


Immediately after this the malware starts to inject it self into a new process, this will make the malware harder to analyse as well as it will be much harder to detect when a machine is compromised. It parses through running processes with the help of CreateToolhelp32Snapshot and process next etc, which is pretty easy to identify. It injected small portions into explorer.exe so in order to analyse the file further i renamed the process, set a breakpoint on CreateRemoteThread and injected it into a non system process and attached OllyDBG.

Now i could continue to analyse the file and it will repeat the step to decode functions and library names as well as path's to make the malware persistent were obfuscated. Next it created a Mutex with the name cniv,s and i learned how the malware made it self persistent; namely by copying it self into C:\RECYCLER\R-1-5-21-1482476501-1644491937-6820003330-1013\avmngs.exe  and added a new entry into windows registry with the name Taskman.



The bot then tries resolve an IP to the domainname we saw in the strings-output earlier and connects to it on port 3322. The IRC server it is connecting to accepts custom made commands as we can see below. It goes through several loops to generate nickname and user information to send. The malware sends PASS eee, KCIK(NICK) nickname, and ssrr(user) and automatically joins a channel by name #dpi. When the bot has joined the channel it gets commanded to download a file with the command !dl <location>, and join another channel - namely #}. Now it just idles those channels and awaits for further instructions.




I started a netcat session listening on port 3322 and used a fakedns ruby script to simulate a real network connection to get the supported commands. The commands i found are similar to this post, as are rest of the bots functions and behavior.

In part 3 i will analyse hj3 executable that got downloaded by this bot.