Using twitter as a C&C channel for a bot

[digininja]

I had what I thought was a mad idea the other day, why not use Twitter as a C&C channel for a botnet. I kept thinking about it and swung between attack and defence so asked a few people and decided that it could be done. So I've written up my thought and created a proof of concept bot and posted them to see what people think.

TwitterBot

Have a read and give me your feedback.

[vector]

interesting idea

[g-ram]

site is down?

maybe its just me.

[Tarbizkit]

no, it not just you, the site is down.

[dr0p]

It's definitely interesting concept, but as soon as twitter was notified, they could take the c&c center down, which would be a huge problem for anyone running a botnet. Maybe if it was distributed across multiple accounts it would be better, but it could still be shut down very quickly. Oh well, still a fun concept and can be used for good purposes too, not necessarily running a malicious sort of botnet.

[DingleBerries]

I like it, but an http bot would be just as good. Im not at home right now but I will have a look at your sauce within the next day or so. I think a better idea would be to use a newer twitter clone that doesnt do all the checks and what not, or use facebook status xml to send commands. Im sure if twitter happens to look over your twats and sees nothing but get, ping, ect commands they are going to get a bit suspicious, where as facebook has >1000000 users and cant be bothered by one persons twat. Still looking forward to reading what you have put together.

[digininja]

no, it not just you, the site is down.

My hosting company moved all their servers across London last night, it was a massive move and all seemed to go ok so the site is back up and running again now in its new home.

[digininja]

It's definitely interesting concept, but as soon as twitter was notified, they could take the c&c center down, which would be a huge problem for anyone running a botnet. Maybe if it was distributed across multiple accounts it would be better, but it could still be shut down very quickly. Oh well, still a fun concept and can be used for good purposes too, not necessarily running a malicious sort of botnet.

My initial idea was to use a single account but then changed it because of the reason you give. I'd post commands to random accounts from random accounts and use the search facility for the bots to find the commands.

If the commands are then encrypted/encoded they won't see loads of pings and execs they will see either streams of random characters or maybe even something like:

"Watch Hak5.org @ 7"

which would mean start your DOS attack on Hak5 at 7AM. The more "English" you could make the control language the harder it would be for Twitter to work out how to block it without upsetting other users.

As you are at the mercy of Twitter then they will always have ultimate power over your botnet but as they are large and getting larger the amount of time it would take to get code written, checked and rolled out would give you chance to get established and maybe get what you wanted done.

This could also be used as a backup channel to another C&C as an emergency way back into the bot.

[digip]

"Watch Hak5.org @ 7"

If you had custom phrases to hide your efforts, you wouldn't really have a need for multiple accounts. Where something like "watch $site @ $time" basically said "DoS $site @ $time", you more or less achieve the same thing. Obviously the twitter post wouldn't use $site and $time, but these are variables in your commands to parse for. You could also have something like, "Hey user@site.com, email me the info we discussed" where it then email bombed whoever user@site.com was. This is scary to think how something like this can get carried away with an abused, but probably even easier than some script kiddy using IRC bots for similar abuse.

[digininja]

The multiple accounts would just prevent twitter from killing the whole thing by taking one account down.

[digip]

The multiple accounts would just prevent twitter from killing the whole thing by taking one account down.

Agreed...

[will-wtf]

Nice concept, but lets remember that twitter is a public, social site, and available for the whole world to see, so the more plain english used the better. This would also make it harder to close down.

[MAdams]

My initial idea was to use a single account but then changed it because of the reason you give. I'd post commands to random accounts from random accounts and use the search facility for the bots to find the commands.

If the commands are then encrypted/encoded they won't see loads of pings and execs they will see either streams of random characters or maybe even something like:

"Watch Hak5.org @ 7"

which would mean start your DOS attack on Hak5 at 7AM. The more "English" you could make the control language the harder it would be for Twitter to work out how to block it without upsetting other users.

As you are at the mercy of Twitter then they will always have ultimate power over your botnet but as they are large and getting larger the amount of time it would take to get code written, checked and rolled out would give you chance to get established and maybe get what you wanted done.

This could also be used as a backup channel to another C&C as an emergency way back into the bot.

If you are posting from random accounts and searching to identify the commands couldn't the bot be controlled by a 3rd party? if someone tracking your botnet figured out your command structure (probably would be hard to do that) then couldn't they post random messages and have control over this botnet? some kind of unique authentication phrase wouldn't be a bad idea

[digininja]

I was thinking of having some kind of salted hash to authenticate the message.

[endeavormac]

<edit>

After reading your http://www.digininja.org/twitterbot/ I like mubix's ideas.

I guess the idea would be to make what you are looking for in the public timeline so close to what other people are writing that twitter will be apprehensive to write a filter for it, as they would deny too many regular tweets.

</edit>

I'm just going to weigh in here, and say no, I would not use twitter.

The reason I would not use twitter is because you do not have very much control over the API or how twitter works. There is also a single point of failure here: twitter.

If you have a relatively small botnet, then ok, maybe you will not run into problems.

If your botnet became a problem/noticed, ways I would shut it down, were I twitter:

Identify the offending twitter account.

Identify IPs which were doing lookups on that account's feed.

Contact the ISPs of those accounts. Hopefully, one of those IPs would belong to a company with a dedicated/informed IT department, whom I could A) inform and B) ask for a copy of the offending trojan.

Take the trojan, and discover how it selects twitter accounts.

Deny those twitter accounts.

Block the offending IPs.

Twitter being what it is, I'm sure they already have an incident model/plan for these things already in place.

Worse case scenario, twitter could just change the way the API works. Imagine how easy something such as conficker would be to shut down if it was based off of something that the botnet creators had such little control over such as twitter.

Here is what I think would be your best bet.

Pick an algorithm which will create a predictable string based off of time. Say, each day it hashes the current unix timestamp / (60 * 60 * 24) to give you the number at the beginning of the day. Take the first characters of this hash, and now you have something that will change predictably.

Now pick some free hosting sites, and some free dns services (.tk domains ring a bell). Have your bot request a page at *random_string*.*free_dns* or free_hosting_site.com/*random_string*

You have created A) multiple points of failure. If one site begins blocking your bots, you can still use another. B) You are now in more control the protocols your botnet is using. Twitter API changing, it could happen. HTTP and DNS? No (sorry kaminsky).

Make sure to scramble up your strings, and keep your bot dependent on as few external factors as possbile.

</done weighing in>

how was that?

[digininja]

<edit>

After reading your http://www.digininja.org/twitterbot/ I like mubix's ideas.

I guess the idea would be to make what you are looking for in the public timeline so close to what other people are writing that twitter will be apprehensive to write a filter for it, as they would deny too many regular tweets.

</edit>

I'm just going to weigh in here, and say no, I would not use twitter.

The reason I would not use twitter is because you do not have very much control over the API or how twitter works. There is also a single point of failure here: twitter.

If you have a relatively small botnet, then ok, maybe you will not run into problems.

If your botnet became a problem/noticed, ways I would shut it down, were I twitter:

Identify the offending twitter account.

Identify IPs which were doing lookups on that account's feed.

Contact the ISPs of those accounts. Hopefully, one of those IPs would belong to a company with a dedicated/informed IT department, whom I could A) inform and B) ask for a copy of the offending trojan.

Take the trojan, and discover how it selects twitter accounts.

Deny those twitter accounts.

Block the offending IPs.

The counter to most of these is that, as I said in the paper, I wouldn't use a single account for either hosting the commands or posting them. I would post from randomly created accounts to randomly chosen accounts and then use the search feature to find the posts. Having the posts in the public timeline removes the ability for Twitter to either block a host account (because there isn't one) or the searchers (as they would be doing a generic public timeline search).

My counter argument to this working is that once Twitter works out the method the bot uses to spot the message it can then start doing regexp checking for those messages itself, a counter to that is to create a control language that was generic enough that the filter Twitter would have to put in place could also block legitimate traffic.

Twitter being what it is, I'm sure they already have an incident model/plan for these things already in place.

They do but it takes them some time to work out that the bot is there, reverse engineer the bot, work out the fix, test it and roll it out. If you built the bot well you could have a rotating command structure where you could easily send down a new command language which, if you got in before the Twitter filters, would make them useless.

Worse case scenario, twitter could just change the way the API works. Imagine how easy something such as conficker would be to shut down if it was based off of something that the botnet creators had such little control over such as twitter.

They can't change the API, it would kill too many apps that are already out there, the public outcry when their favourite Twitter client died would be too much.

Here is what I think would be your best bet.

Pick an algorithm which will create a predictable string based off of time. Say, each day it hashes the current unix timestamp / (60 * 60 * 24) to give you the number at the beginning of the day. Take the first characters of this hash, and now you have something that will change predictably.

Now pick some free hosting sites, and some free dns services (.tk domains ring a bell). Have your bot request a page at *random_string*.*free_dns* or free_hosting_site.com/*random_string*

You have created A) multiple points of failure. If one site begins blocking your bots, you can still use another. B) You are now in more control the protocols your botnet is using. Twitter API changing, it could happen. HTTP and DNS? No (sorry kaminsky).

Make sure to scramble up your strings, and keep your bot dependent on as few external factors as possbile.

</done weighing in>

how was that?

This last idea is just what Confiker does. That is a very good idea but someone already thought of it, we are trying to come up with something novel here.

I think this method would be probably best employed as a backup channel in the same way confiker has p2p built in. If it is obfuscated enough in the bot then people won't really know what it does until it has been used to regain control and after that it can be burnt and a new backup put in place.

[endeavormac]

I'm just arguing for the sake of brainstorming here/carrying on a conversation. nothing meant to be taken personally/offensively/flamishly

The counter to most of these is that, as I said in the paper, I wouldn't use a single account for either hosting the commands or posting them. I would post from randomly created accounts to randomly chosen accounts and then use the search feature to find the posts. Having the posts in the public timeline removes the ability for Twitter to either block a host account (because there isn't one) or the searchers (as they would be doing a generic public timeline search).

When I said block IP, I meant the IPs of the specific bots, not the IPs posting messages. In your explanation, you have the bots eventually looking up the user by his username. By having the bots look up by username, you give twitter a way to identify with great accuracy the bots. If they can find one of your botnet controlling accounts, they can just go ahead and block IPs that use(|d) the API to look up those accounts, and then contact the relevant ISPs (blocking the bots, not the controller (well in addition to the controller)). Perhaps twitter would be viable as one of several command mechanisms, but you can't have it as the single control mechanism in your botnet.

<edit>I see later you respond to this</edit>

My counter argument to this working is that once Twitter works out the method the bot uses to spot the message it can then start doing regexp checking for those messages itself, a counter to that is to create a control language that was generic enough that the filter Twitter would have to put in place could also block legitimate traffic.

As I think of this, here is what I would propose. Again, I'm not 100% sure of the twitter API, I've only played around with it somewhat, but if you can search the public timeline for certain words, here's what I would do:

1) I would pick several popular words searched on twitter. For this example, we'll say the three most searched words are ["dog", "cat", "tiger"]

2) Have your twitter bot search the public twitter timeline for these words on a pseduo-random time schedule. For example, at 2400, 0600, 1200 and 1800 GMT, but have a one hour lee way after the time, and randomize whether or not you're going to pull commands. So, out of the day, you may randomly only pull commands at two of the times.

3) Include the word dog, cat or tiger somewhere randomly in your command. "ping dog <hostname>", "dog ping <hostname>", "ping <hostname> dog" would all be valid.

4) Go through all the entries you pull down from twitter, up to the past hour, strip out the word you used, and check to see if the result is a valid command, IE "ping <hostname>"

- This makes your bots harder to distinguish from regular users. You are shifting some of the locating of the individual commands to the bot machines, instead of through the twitter API.

- This assumes they won't change the twitter API, but I give in to you on this one later in this post.

- It also makes your botnet fairly easy to hijack. You may want some way of signing your messages.

Here's an interesting idea. Hash the original command PLUS a salt known to you and bots. Take the first 8 chars of the hex digest, giving you 2^32 combinations. Use this, plus the salt again, as a key to encrypt each individual word, then base64 encode it. Throw your word in there ["dog", "cat", "tiger"], and your 8 hash chars (not the salt).

Now look for your word ["dog", "cat", "tiger"], and then search for all 8 char words 0-9a-f (chances are there will be only one, but just in case). Unbase64 encode each word and try this 8 char hash plus salt to decrypt it. Take the 8 char hash out of the result, and hash the result with your salt. If the first 8 characters equal the 8 characters of the hash you found, you should be good.

Now obfuscate your salt as well as you can in code. Until twitter can deduce your salt and this crazy algorithm, I have no idea how they would write a filter to block this crap. It will appear as a jumble of letters split up into words. If you had just a symmetric key, ping would appear the same everytime, but because of the 8 hex chars, you have 2^32 different possibilities for ping. You also A) keep others from seeing commands sent, and B) bots are assured you are the one issuing commands.

Once the salt/key and algorithm are deduced it's game over. Just make things crazy.

Sorry this post is so long. So I don't think I did a good job of explaining the code above, so I went ahead and implemented it in python. Here's a link: http://myw3b.net/~endeavormac/files/hak5twitterbot.tar

I didn't feel it necessary to add the words (dog|cat|tiger) in, because this part is trivial. This handles everything else.

Here's the output:

>>>
encoding
enter some text > ping yahoo.com
enter a salt    > hellohak5
47dd1f40 xiALPQ 0siKpTfGDrhG
>>> 
encoding
enter some text > ping hak5.org
enter a salt    > hellohak5
E6T5NQ 383f81c3 6JUtf3nTZf8
>>> 
decoding
enter the text > E6T5NQ 383f81c3 6JUtf3nTZf8
enter the salt > hellohak5
plaintext found: ping hak5.org
>>> 
decoding
enter the text > 47dd1f40 xiALPQ 0siKpTfGDrhG
enter the salt > hellohak5
plaintext found: ping yahoo.com
>>>

They do but it takes them some time to work out that the bot is there, reverse engineer the bot, work out the fix, test it and roll it out. If you built the bot well you could have a rotating command structure where you could easily send down a new command language which, if you got in before the Twitter filters, would make them useless.

I like this

They can't change the API, it would kill too many apps that are already out there, the public outcry when their favourite Twitter client died would be too much.

I guess this was just a scenario for if your botnet was large and hard to lock down. They couldn't change the API over night, but they could announce a change. Say, in 30 days our API will be changing. However, if your bot could modify itself to adjust for the new API changes (like you mentioned above), then this would indeed be impractical, regardless of botnet size, so I'm going to have to concede API changes as trivial to you.

I think this method would be probably best employed as a backup channel in the same way confiker has p2p built in. If it is obfuscated enough in the bot then people won't really know what it does until it has been used to regain control and after that it can be burnt and a new backup put in place.

Ok, I like this too

[digininja]

Its late here so a few quick answers....

You still haven't got the idea for the control system. It would post to a random account, BBC today, Steven Fry tomorrow, the bots would search the public timeline using a regexp to match commands it knows about which it will then act on. In this way Twitter can't look at which IPs are accessing certain accounts, they are hitting the public timeline, and either pulling down all messages then filtering locally or doing a vague search to cut down fluff then filtering locally.

For the format of the commands, there are two ways to go, either encrypted in some way or obfuscated in some way. The encryption makes it hard for Twitter to read what is said but gives them something to look for, they can drop any tweets which are just strings of random stuff. If you obfuscate by using English phrases to mean things then it becomes a lot harder to drop messages. The message "Go to the beach" could be innocent or could be a command to dump the SAM and send it home. Twitter couldn't drop "Go to the beach" type messages as this is their bread and butter. To protect against hijacking a salted hash added as a hash tag would prevent others from creating similar messages, if the salt contained a timestamp then replay attacks would also be avoided.

I've got a working concept for doing language rotation so even if Twitter spotted that "Walk the dog" meant something today, with a single command and maybe a tinyurl to an encrypted new command file, it will mean nothing tomorrow.

For the API changing, I'm guessing you've not done much dev work like this. If Twitter wanted to change their API then I'd expect a good 3 months (probably 6) between announcement and change and probably some backward compatibility for a while. There are way too many apps out there that rely on that API and Twitter would be more concerned with keeping users using the site than killing off a botnet which because of its reliance on Twitter can't actually do it any damage. The botnet isn't affecting them but loosing a chunk of their user base when applications X, Y and Z suddenly stop working will hurt them badly.

Even if they did say they would change in 30 days, a good bot developer is just as good as a good app developer and if an app developer could update their app in the 30 days the bot developer could. All good bots are built to mutate with time so moving to a new API wouldn't be an issue either way.

Twitterbot 2 is in the pipelines and will hopefully be launched to coincide with a Defcon talk by Tom, assuming his CFP gets accepted.