Steganographic Command and Control:
Building a communication channel that withstands hostile scrutiny

Adrian Crenshaw
 

Introduction

        Botnet command and control channels have traditionally been carried over protocols such as IRC (Internet Relay Chat) or the various P2P (Peer To Peer) networks. If an incident response investigator knows where to look, they could potentially discern a command and control channel, if not by plain-text content, then at least by statistical methods. Organizations could also attempt to filter these protocols at their borders since their business use, in the cases of IRC and P2P, is questionable at best. As time has progressed work has been done to use less obvious protocols like HTTP and websites with user generated content to pass messages to a botnet's nodes. Projects like Robin Wood's KreiosC2 have demonstrated using social media systems like Twitter, advancing the idea of using Web 2.0 media as "blind drops" to help obfuscate who is controlling the botnet, as well as making it harder to block since the command and control channel is something that may have a legitimate use to the organization (web traffic, either for business or incidental use by employees).

        In related matters, encryption may also be used by some botnets to conceal what commands are being issued. While encryption may keep the messages (and thus the intention of commands) secret, statistical analysis based on destinations and rate of contact may still reveal that a bot exists on particular network hosts . If an administrator knows a system is "owned" then they will seek to eliminate the threat, even if they don't know what instructions a bot is carrying out, by rebuilding the system from know good media.

Original Research Intent

        The purpose of this project was initially to advance the concept of using steganographic techniques to hide the existence of a covert command and control communications channel inside of user generated content on the Internet. Merely knowing the bot (or some other distributed system trying to pass data) is there could lead to more investigation and the removal of the infection. In the future, to increase the longevity of individual nodes in a network, malware authors may begin to use steganography to conceal the fact that communications with the botnet are even occurring. The original goal of this research project was to construct a simple botnet that uses Social Media/Web 2.0 apps for "blind drops" as part of the command and control channel. A blind drop is essentially a place where data can be stored for later retrieval by another party, hopefully without exposing the entity that dropped the data off to the risk of being identified by opposing observers. Content at these blind drops were to use steganography so that the posts made to the user generated content / social network sites did not obviously appear to be botnet command and control traffic, but instead appear to be just normal user generated data.

Expansion Of Concept

        I've since branched out my interest in the subject. Besides their use in botnets, steganographic channels would also be of great use to the field of "darknets" (anonymizing encrypted networks). Many darknets exist that support very robust anonymizing abilities if used properly. If all a darknet user had to fear was remote attackers discerning their identity, then current darknet technologies like Tor, I2P and FreeNET might be enough. However, someone directly monitoring a darknet user's node may still be a threat. While a network snooper may not know the contents of the messages being sent into the darknet, the mere knowledge of the existence of the messages may be enough to bring unwanted attention from hostile parties. Not all governments or organizations like it when individuals are trying to hide their communication and the mere use of an anonymizing system may lead to trouble. If steganographic techniques could be used alongside the encryption and proxying that current darknets provide, then these darknets would be that much closer to allowing for the free exchange of information.

Advantages And Disadvantages Of A Steganography Communications Channel

        There are many advantages to using social media and steganography for anonymizing communication channels. First, the blind drop approach that utilizes user generated content obfuscates who is communicating to the botnet. Services like Twitter and Facebook do not belong to the bot herder, and cannot be directly tied to them (assuming that they do not sign up to the websites using credentials or information that can be tied to their real identity). It's also possible to use the SSL support provided by the web host of the blind drop for the command and control channel, adding a level of security against observers who do not control one of the endpoints. Second, because the communications are happening over HTTP/HTTPS, a protocol not as likely to be blocked at the borders as IRC or a P2P based protocol, the communications are more likely to get through. HTTP also has the advantage of being common and "chatty", so it would be relatively easy to hide extra data in verses other more sparse protocols. Social media web sites like Twitter or Facebook are not as likely to be blocked as IRC or P2P, depending on the type of organization involved. Third, HTTP, SOCKS or Tor proxies can be used for web traffic to further obfuscate the identity of the bot herder. Fourth, steganography plus encryption makes the channel hard to detect, and even if it is detected, hard to read. The level of inspection needed to detect if steganography is in use would be quite resource intensive, making it less likely that organizations would attempt to search for it unless they had significant reason to suspect its use. Many of these advantages also hold true in the case of darknets wishing to use social media and steganography to remain covert.

        Of course, a steganographic blind drop communications channel has a few disadvantages as well. More data has to be sent to get a message though than if no attempt was made to conceal the contents of the real message. Convincing cover data will take up most of the space in the communications channel, and the higher the steganographic data content the higher the chance of the hidden message being detected via statistical analysis. As with any technical scheme, the more complicated something becomes, the more bugs it will have. With social networks such as Twitter and Facebook, the implementer has to worry about the host of the blind drop making changes to the submitted content that might have little effect on the cover media's readability, but totally destroys the hidden data. For example, in the case of least significant bit encoding, a mere change in the color pallet or re-size of the image could destroy the hidden message. In the case of a botnet's command and control channel we could simplify the command syntax so that fewer bytes have to be encoded, but this makes the steganography less adaptable for other applications. Still, aiming to make the hidden message more concise will help with the bandwidth and detectability issues.

The Potential Anonymizing Power Of Social Media

        While my research started off as merely focusing on using social media technologies to conduct botnet command and control channels, darknets are a far more interesting use for the idea. Darknet services like Tor, I2P and FreeNET provide anonymity, and while eavesdroppers may not be able to read the message or know who it is being sent to, they know a message exists. Just knowing the message exists could lead eavesdroppers in oppressive regimes to employ "Rubber-hose cryptanalysis" to come after the user. If user generated content could be made that appears to be innocuous, but contains hidden data, suspicion can be avoided.

        Ideally, to build a steganographic communications channel, one would need to choose a cover communications channel that would look innocuous to outside observers. Generally speaking, steganographic systems are wasteful of space since the real message must be contained in a cover media that takes up more space that the hidden message, and for the hidden message to be non-obvious it can only be a small percentage of the whole data package. Luckily (for the person trying to hide data at least), modern web/Internet applications are so wasteful of space that it should be easier to find places to hide data in content than it was back in the time of dialup. Gone are the days of black text on gray backgrounds being the majority of web sites. With the explosion of broadband to the home, media such as Flash, MPEG 4 videos, poorly compressed images and large files to download have become commonplace.

Steganographic Possibilities

        There are many ways steganography can be carried out. Hiding data in other data has a long history. For my research, I've mostly been experimenting with LSB (Least Significant Bit) encoding, Unicode homoglyphs, and Microsoft Office XML file ZIP embedding. I've written some simple example code for each of these steganographic techniques, which I will link to at the end of this paper. In the following paragraphs I will give short overviews of these steganographic techniques and how they can be implemented.

Least Significant Bit Encoding (LSB)

        Least Significant Bit encoding generally uses a lossless image file format (BMP or PNG for example) and modifies the least significant bit (or bits) of the pixels the image is comprised of. We can modify these least significant bits in such a way as to hide arbitrary data if we so wish. First, let me explain that in the RGB (Red Green Blue) 24 bit color space, each pixel's color is defined by three integers with values between 0 and 255 (or if expressed in hexadecimal, 00 to FF). Each of these integers corresponds to either the amount of red, green or blue in the pixel's color. The human eye would have a hard time telling the difference between the RGB color value FF9999 (light red) and FF9899 (which encodes the binary value 101 on the least significant bit of the red, green and blue values respectively), but a computer program has no problems discerning this subtle difference. Using a lossy algorithm would make this tougher so my illustrative code only uses PNGs (For JPEGs, look up the application "StegHide"). Also, some sort of XOR based encryption to the payload would be an easy option to add so that the contents cannot be easily read if the observer knows the steganographic method being used. Since this code was implemented for the sake of learning I've opted for simplicity of concept. In a real world application the binary values should be encrypted before they are steganographically encoded using any of the systems I outline in this paper.

Steganographic Unicode Homoglyphs Encoding (UHE)

        The Unicode method is a little more novel than LSB encoding. Unicode is used for expressing text, and has an advantage over ASCII in that you can encode characters from many different languages. In Unicode there are multiple ways to encode characters that look more or less the same to the human eye (homoglyphs), but have different numerical values in the Unicode character space. I thought this would be a great way to try to hide data in user generated content as many web forms allow Unicode input. I did some searching around for an existing implementation, but did not find any code to do Unicode Homoglyphs Encoding (UHE). A researcher named Antonio Alcorn had a demo page that demonstrated a version of UHE, which he may put up source code for at some later point in time. I looked at the results from Mr. Alcorn's work, but went a slightly different direction in how I do my encoding (subjectively, his results looks better, mine hides more data). As for my implementation, It seems that the characters:

!"$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

are represented in both the 0021-007E (Basic Latin) and the FF01-FF5E (Fullwidth Latin) ranges. This means we can use the lower range to represent zeroes and the higher range to represent ones. This makes changing from one encoding to another as easy as adding the decimal value 65248 to the lower range versions of the character. The exception to this rule is the space character; I have to do something special with spaces and encode them as Unicode number 8287 in decimal. With some effort, I should be able to encode more data or make the output look better by using other homoglyphs, but that will make the algorithm more complicated. Also, some sort of XOR based encryption to the payload would be an easy option to add. Since this first release is for learning, I've opted for simplicity of concept. A great thing about this steganographic technique is that it can hide your messages in Twitter or Facebook posts.

 

Microsoft Office 2007/2010 documents

        I've also done some looking into embedding files inside of Microsoft Office 2007/2010 documents (DOCX, XLSX, PPTX, etc). These document formats are so commonly emailed back and forth that they are good candidates for passing undetected as long as they are not scrutinized closely. Since the newer Microsoft Office docs are basically just ZIP files containing XML file s and resources, it's fairly simple to embed extra information in them. The steps are roughly as follows:

1. Add the file into the document by simply opening it as a ZIP file archive.

2. Edit the file [Content_Types].xml inside the archive so that Microsoft Office programs don't complain about it being a corrupted file.

        If you save any changes in the Office document after you hide a file in it, the embedded file will be lost. I wrote some sample code that makes carrying out these steps more convenient than doing it all by hand.

SnarlBOT Implementation

        To test out some of the steganographic communications concepts I've been researching I've implemented a simple bot which I call "SnarlBot". I chose AutoIt3 for my development language as it is easy to use for automating administrative tasks in Microsoft Windows, and it's easy to roll out executables with it that don't have missing dependences on Windows XP and newer hosts. I've done little to make SnarlBot stealthy as it is just meant as a proof of concept. To work in an automated fashion, SnarlBOT would need to be added as a task in the Windows scheduler. Since Unicode based steganography seemed the most novel, I decide to try to implement the command and control channel using this method of hiding data. I had a few options as to which user generated content site to use for the blind drop, but in the end I chose Twitter since it is so popular among the security community I am a part of. While trying to code SnarlBot to work with Twitter I noticed some decidedly difficult problems I had to overcome, problems that may be eliminated in future steganographic communications projects by switching the blind drop host to another Web 2.0 service.

        The first major problem I encountered was formatting the text properly so that the hidden data did not get mangled by Twitter. Since text is what is being submitted, Twitter takes liberties with how it decides to edit the text before storing or presenting it to the user. For example, leading and trailing spaces are removed, as are extra spaces between words. Carriage return and line feed control characters are also removed. All whitespace characters beyond simple spaces between words are dangerous to use for encoding data. There is a good chance that Twitter will decide to remove any whitespace that it sees as extraneous from the final post that will be viewed by a user.

        The second problem: one-hundred and forty characters is not a lot of room when trying to encode data steganographically into the Tweet. With the simple Unicode encoding I've been using, the Twitter command and control channel needs eight cover characters to hide one byte of hidden command data. This means you can only imbed seventeen characters maximum in each twitter post. My workaround for this problem is fairly simple. If the cover text required to embed the hidden text is longer than one-hundred and forty characters my parsing/encoding application takes the large section of cover text, breaks it into 137 character chunks, embeds the hidden data, then tacks on a series of periods to the end of the tweet (...) to let the receiving bot know that it has to read the next tweet to complete the command. The (...) suffix would be easy to spot if someone knows to look for it, but it is a common way in online communications for a human to indicate that the message is to be continued. This scheme could easily be replaced by another system for indicating that a command spans multiple Tweets.

        The third problem: depending on what browser or reader was used to view the Twitter feed, varying levels of stealth would be achieved. Firefox looked relatively normal when my implementation of the Unicode steganography technique was used. Internet Explorer however gave less than stellar results.

        Worse yet were the results if a user attempted to view the Twitter feed from a non web browser based client, such as a phone application like TweetDeck. Not only would some characters look "off" but the higher Unicode characters would appear as rectangles (used as place holders for unrecognized characters) since the Twitter reader would not display the higher Unicode characters.

        Despite these problems, SnarlBOT was an interesting project to implement. The core steps that SnarlBOT carries out are as follows:

1. Grab the Twitter feed specified.

2. Decode the steganographically hidden commands.

3. Check the Twitter post IDs and compare them against the list of ones that have already been ran.

4. Run any commands that have not been ran previously.

        As you can see, the program flow is fairly simple. Future versions will hopefully me more optimized. I'm thinking of using Google Docs as my next blind drop test platform as it gives the use more latitude as to input. Flickr would be a good candidate for hiding data using the Lease Significant Bit encoding scheme since it does little to modify the original images that are posted by users. Also, just finding a host for Microsoft Office documents and adding data into the ZIP archive before it's posted is an option. As I develop the tools further I need to experiment with having the bot nodes communicate back to the controller, as of right now the communications are in only one direction. Source code for SnarlBOT is available at the URL provided at the end of this paper.

How A Steganographic Darknet Might Be Implemented

        The overhead of cover media and the requirements of anonymity mean that a darknet using steganography is likely to have relatively high latency. Web pages with high levels of interactivity like AJAX applications would be hard to implement under such circumstances. That said, if a user prizes anonymity and staying under the radar, then some sacrifices should be acceptable. A scheme somewhat like the one FreeNET uses, where the darknet is more of a distributed file system than a direct communications network, may be the best call and a model to base future work on. Since much of the traffic would be web based, would it be possible to implement a large portion of the darknet directly in the web browser so that no client need be installed to utilize the anonymizing system? Some work has already been done in creating a darknet that runs in a web browser's Javascript engine, which would lower the barriers to entry since the core application would already be installed on most potential darknet nodes.

        To make a darknet around the idea of steganographic blind drops would be somewhat harder than implementing a botnet using the same techniques. With darknets more people are involved in the exchange of information. A darknet's implementation would be less private (in the sense of people being able to review how it works), and while security though obscurity is generally a bad thing to rely on, in a botnet it is easier to get away with it because of the limited user base (the bot herders). In a darknet where people would need more access to the app to verify it (source code review), better means will have to be taken to make sure the steganographic and encryption techniques that are being used hold up to close scrutiny.

        To join such a darknet, users may be required to add resources to the darknet that can be used by all participants - for example, opening accounts on social network sites that the network can use to exchange messages between clients. One of the failings of some darknets (or P2P systems for that matter) is that if some sort of "Quid pro quo" system is not implemented network performance will degrade greatly as more users join. By making the systems require users to add resources to the network in the form of accounts, proxy nodes, etc, this degradation of network performance can be mitigated. To encourage users to help build the darknet, a credit system could be implemented so that the more resources a user adds to the darknet, the better their service will become.

        Beyond just using user generated content sites for storing data, a scheme will need to be used that keeps the web host from knowing what the content is even if they join the darknet themselves to investigate it. Ideally, it should not be as simple as requesting data from the darknet and putting a network sniffer on the connection to see where the specific data is being hosted. This can be handled somewhat by bouncing the requests across multiple peer-to-peer nodes on the network and caching data in such a way that even the person that passes it on or stores it cannot read the contents. The FreeNET and I2P darknet implementations may be good references to look at for how this sort of proxying and secure caching could be implemented. When it comes to privacy system, most of the time it is best not to reinvent the wheel and to take advantage of the solutions that have proven robust under similar circumstances in the past.

Conclusion

        The concept of using steganographic techniques to hide the existence of a covert communication channel inside of user generated content on the Internet seems to have great potential. In environments where merely the presence of an encrypted message could lead to more investigation and unwanted consequences, steganographic techniques would greatly aid those wishing to maintain their privacy AND freedom. As Social Media/Web 2.0 apps use so much bandwidth already they make for very feasible cover media, with the added advantage that they can act as "blind drops" to lessen the chances of exposing the entity that sent the message into the channel. I will admit that my demonstration source code is rather crude. Still, I hope that it, along with this paper, will inspire others to do research into implementing such steganographic systems, especial in the field of darknets.

Source Code Downloads

SnarlBot Demo Code
http://www.irongeek.com/downloads/snarlbot.zip 

LSB and Unicode Steganography
http://www.irongeek.com/i.php?page=security/unicode-and-lsb-stego-code

Microsoft Office XML File Format Steganography
http://www.irongeek.com/i.php?page=security/ms-office-stego-code

References

Robin Wood, KreioSC2.
http://www.digininja.org/kreiosc2/index.php
(accessed April 29, 2010)

Jaideep Chandrashekar, Steve Orrin, Carl Livadas, Eve M. Schooler.
The Dark Cloud: Understanding and Defending Against Botnets and Stealthy Malware
http://search.ebscohost.com/login.aspx?direct=true&db=buh&AN=43972686&site=ehost-live

Adrian Crenshaw, Darknets: Anonymizing Private Networks
http://www.irongeek.com/i.php?page=videos/darknets-i2p-tor-phreaknic
(accessed April 29, 2010)

Schneier, Bruce (October 27, 2008). "Rubber-Hose Cryptanalysis". Schneier on Security.
http://www.schneier.com/blog/archives/2008/10/rubber_hose_cry.html 
(accessed April 29, 2010)

Antonio Alcorn, Steganography in Unicode text
http://www.cs.trincoll.edu/~aalcorn/steganography/
(accessed April 29, 2010)

Kelly Jackson Higgins, Researchers Build Anonymous, Browser-Based 'Darknet'
http://www.darkreading.com/security/encryption/showArticle.jhtml?articleID=217801293
(accessed April 29, 2010)