cyberwart

In a recent security mailing list I was asked what I meant by ”Dynamic HTTP Callbacks”. I think this is a cool technology that maybe not a lot of non-offensive security people are aware of. So I’ll summarize the technique here.

The general idea of a Dynamic HTTP CallBack is to place an implant/rootkit on a target machine and have the traffic look like valid HTTP traffic. The dynamic part refers to using dynamic DNS.

The basic idea is to use MS API to create Internet connection. This emulates what IE does and sets up the auto proxy and such. It’s best if you can hook IE  by creating a remote process thread, but that isn’t really necessary in most cases. The MS API is about the same as a socket but it does a little lifting for you.

Over the actual socket, connect to remote port 80. It’s best if it’s an actual web server. I use php pages on regular Apache servers and specialized scripts. My implant issues a GET to get info from the page and a POST to post to the page. Sites that pretend to be email type pages look the best for sending lots of posts. Foremost though, everything transmitted is valid html.

There should be a “cover” page associated with the communication. So most of the page is a regular page that someone might look at. It’s better if it’s something that they might look at fairly often…the weather, news, sports, email, etc.  

Inside the webserver/script is a means of hiding a message. Stego is way beyond this post. For me the php on the webserver knows how to find the hidden messages in the html and grabs them out for me. The simplest mechnism is to use specialized tags, misspelled words, etc that points to the data.

It’s important to obfuscate the data. You don’t want to send directory listing or get commands plaintext. There are several ways to handle this. Here’s what comes to mind:

1.  Encrypting the message. I want to caution against this. Crypto to news sites, weather, or other bland type stuff is very obvious. If you start encrypting lots of messages IDSs will notice too much entropy and trigger. Then there is clearly a problem.
2. Encrypting the Comms.By this I mean use an SSL (HTTPS) connection. This keeps the message secret and generally looks benign. Keep in mind though, most people don’t use SSL everywhere and it needs to be targeted.
3. Encoding.XORing is wonderful. It doesn’t increase entropy and it looks “encrypted”. It’s very nice for hiding data when you don’t need to ensure data confidentiality. The downside is that it’s fairly trivial to break

For the dynamic dns:

Inside the implant you need to put a DNS name for a host or hosts. There isn’t really a way around this. You have to have some box to call back to. The problem is that if someone discovers your implant and you’re a “nasty bad guy” you don’t want it calling you! So to solve this we use a DNS name from a dynamic dns server like dyndns.com. This is useful as it lets you change the IP address the of the webserver the implant will talk to without communicating with the implant. That’s good as you can reduce your exposure if you’re an evil badguy and change the IP address if you run into problems.

This entry was posted on Monday, April 23rd, 2007 at 2:01 pm and is filed under , . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.