Staying undetected post-exploitation

July 28, 2011 by Esteban Guillardoy


Once you have control over a target and go into the post-exploitation phase, you start thinking on how to keep future access and most importantly how to stay undetected.

This article will present some insight on the talk “The Listening” presented at Infiltrate 2011. For that presentation a Thunderbird backdoor was developed to allow remote control over the target box. This was recently added as part of the latest CANVAS release (July 2011).

Although the research was focused on Thunderbird, the same basic idea can be applied to other applications which could better suit different scenarios.

The problem

Several approaches exist in order to maintain control on a target by using backdoors or trojans which in most of the cases need to bind to some port or make external connections. Also to make these backdoors persistent, some new services may be installed or some startup scripts deployed, just in case the target is rebooted. All of these changes in the system may be detected, and of course as attackers we want to be as stealthly as possible. Keeping noise down is really important during post exploitation phase.

Rootkits are often used in order to hide processes, ports, etc. but this means more things to deploy on our target and dealing with anti-virus or rootkit detectors, so lets rule out this option for now.

Not only is hiding our backdoor on a system important. There are some other common issues that need to be covered:

  • Not all the targets are 24×7 servers. If we owned a common user, the target may go on an off.
  • Not all targets have a static IP address and may connect from different places (laptops being carried from one place to another). This means “routing” connections could give use trouble sometimes.
  • Companies have firewalls and IPS/IDS solutions. We need to fool traffic analysis in order to avoid being detected or filtered.

The strategy

The idea to tackle some of the mentioned items is to “piggyback” a commonly used application and take advantage of its usual network traffic to simply disguise the activity.

Nowadays many applications provide some kind of extension or plug-in architecture to deliver additional functionality but most importantly this provides developers with a complete framework to control many aspects like networking, system access, access to application internals, etc.

This is the kind of thing that enable us to add hidden features to remotely control the application behavior and even use it as a “proxy” to execute other programs on the system. Even if execution is performed with a low privileged user, we all know there are ways to locally escalate privileges.

For “The Listening” we used Mozilla Thunderbird as the application to host our backdoor. Here are some of the reasons that led us to select it:

  • Emails are a perfect incoming & outgoing communication channel to a target.
  • If we control the email client, there’s no need to open ports to listen or send data.
  • There’s no need to install services or startup scripts. Email clients are used on a daily basis. This means that our backdoor control is “asynchronous” but it works for us.
  • Routing data is no longer an issue. We just send an email and it will get to its destination, no matter where the target is connected. We may be facing some anti-viruses or scanner or spam detection, but I will go into that later.
  • Thunderbird is multi-platform, meaning our backdoor is too!
  • Mozilla add-ons development is easy to learn.
  • Add-ons can be developed quickly and are easy to test.
  • The Mozilla platform gives the developers access to a lot of features and most importantly to our interests allows program/command execution.

As you can see, there are plenty of good reasons for choosing an email client, but you could extend this logic to any other application with some plugin architecture and apply the same idea to it.

We are not talking about spreading a backdoored addon to “infect” computers, but to implement a backdoor and deploy it as part of a post-exploitation activity in order to keep control when needed.

We could even try to design something more or less generic to easily port to different languages and re-use it when implementing a backdoor for other applications.

Hiding your C&C

We mentioned before things like IDS/IPS solutions, anti-viruses and anti-spam solutions and that is why we need some traffic analysis resistance. We need to avoid our payload being detected and filtered.

The first thing we may think of is encrypting the data somehow. However, this has a drawback because it is likely to generate very distinguishable patterns, making it easier to spot and thus raise suspicions.

That’s when steganography kicks in to help us.

Basically the idea behind steganography is to hide information in such way is not suspected to be there. There are a lot of good resources, research, and studies around this subject, using different algorithms and a wide selection of techniques involving text files, audio, images, etc. as a medium to transport data.

With an encryption algorithm and a steganography technique applied together, you could be able to avoid some common signatures and pattern recognition used by the mentioned solutions.

There are techniques to perform steganalysis on objects in order to find if some kind of hidden information is present, but this is not commonly applied to everything that comes in an email. And even if something is detected, the real payload would be encrypted.

This being said, we now have all the ingredients needed to create a strong backdoor.

Email attachments are normally scanned and filtered, depending on the file type, so choosing an image as our “steg object” is a good idea in order to blend in with normal email contents and traffic.

There are quite a few different algorithms to apply steganography on images, so we had to select one. The Least Significant Bit (LSB) algorithm was chosen, because it is may be the easiest one to implement and also because Mozilla addons are developed in JavaScript which allow us to use HTML5 canvas elements to work with images colors and bits.

Depending on the application for which the backdoor is being implemented, some other restrictions could appear, and different steganography and encryption algorithms may have to be used, but the same results can be achieved.

Hiding your addon/extension

Besides hiding your command and control channel traffic, you need to hide the add-on or extension from the final user. Commonly you will find some menu option or a dialog showing a list of installed extensions which could easily reveal the backdoor to the user. The solution for this situation heavily depends on the application used, so it’s a new challenge you will have to face and work out by carefully studying the application model.

For the particular case of Thunderbird, hiding the extension was fairly easy since one is able to change the behavior of almost every GUI component, allowing in this case to remove items from the “Extensions Manager” dialog.


As applications evolve and provide better technical features that allow developers add new features with some kind of SDK, new opportunities and scenarios appear for attackers too.

We’ve presented a simple idea that could be used to keep access to a target making it look as normal and daily traffic. We’d like to think of this as a way of fast trojan or backdoor development.

Hijacked extensions or plugins are hard to detect for a normal user, and we are not aware of any anti-virus or scanner that checks application extensions which makes all this an appealing idea and is likely to keep us undetected.

Posted: July 28, 2011
Esteban Guillardoy
View Profile

Esteban is an Informatics Engineer from the Universidad de Buenos Aires. He is an experienced Python developer working for Immunity Inc. Esteban is experienced with monitoring tools, platforms, reverse engineering, and IT Security.