Botnet Distributed Command and Control. (DC&C)
Over the past four years we've seen a large number of law enforcement, ISPs, and hobbyists get involved with botnet monitoring. A side effect of the increased interest is that botnet operators will go to great lengths to keep their botnets hidden. That includes encryption, hiding in plain sight, use of undocumented/new protocols and distributed control structures. As law enforcement arrests more offenders, we see more of them using TOR, or their own botnets to hide their true identity. While I personally don't feel it will ever be the super-bug theory that Paul Vixie and Gadi Evron imagine, it is a concern we need to be aware of.
The following post may help drive some botnet operators deeper underground, but the concepts are not new. In many cases these concepts are in use today. I presented on these topics a year ago at the 5th Botnet Task Force conference. For a year security researchers and law enforcement have had the chance to reflect on my presentation and develop mitigation.
Distributed Command and Control is simply a term we use to identify botnets where the operator has learned that directly controlling a large botnet is a big risk to himself and his network. Large scale botnets still exist today, however the operators are wisely breaking these networks up into many smaller networks - or using peer to peer communication. Since the networks are spread out, its harder to eliminate the threat of one attacker.
For example, if a botnet operator takes his 50,000 bots, and spreads them out into 10 networks, each net could have 5,000 drones. By spreading his network out, he mitigates some of the threat from rival operators, botnet hunters, ISPs, and law enforcement. Even if one controller node was taken offline, the botnet operator has 45,000 bots to retaliate with. In many circumstances this gives an operator the heads up he needs to update his 45,000 other bots and protect his empire.
As recent as two years ago, we've started seeing botnets using a pyramid structure, like the simplified image below.
A botnet operator is represented at the top of this flow chart. He communicates with a smaller botnet of only a couple dozen drones. Those drones then communicate with many larger botnets, who perform the stated action. This provides the botnet operator a layer of protection. Now the experienced researchers or law enforcement must find the smaller net, to identify the botnet operator. This is time consuming work, and with out the cooperation of ISP's, its hard work. Even if a controller node is found, it is much easier to snoop on a net with 5,000-10,000 drones than it is one with less than 100 drones.
This distributed structure also helps if the botnet operator wants to rent out or sale portions of his bot. One chunk can be used for spam, while another may perform better in Denial of service type activities.
Another example of distributed structure is the P2P scenario, where the botnet operator issues a command, which is passed to a number of supernodes, whom then pass it to the single peers.
Mapping peer to peer and other types of DC&C's are still possible. It was done with Stormworm and will continue to be done with future P2P botnets. I wont highlight how researchers are doing this mapping, simply because we need to weigh teaching public (including bad-guys) and keeping an ace up our sleeves. I'm hoping this post will spark many closed door conversations to help investigate other methods for tracking and identifying.
As part of the BTF presentation I gave, I wanted to outline additional C&C vectors that could be used. The idea that really caught my eye was based on hiding in plain site. Using protocols that are commonly used by millions of users every day. CME711 (Stormworm) has been easy to keep on top of, because of the mistakes they make in maintaining their DNS (fast flux), registering their domains and using UDP P2P traffic. Because of that UDP P2P traffic many large corporations have been immune - they disable UDP outbound.
The number of infected machines would increase dramatically if the used a connection model similar to Skype.
So back to hiding in plain sight - What would you say to a bot that received its commands over RSS? News readers use RSS to gather headlines and a few lines of news. Users are able to quickly choose articles that interest them, while ignoring those that do not. Millions of people subscribe to RSS feeds, and many of those feeds are of blogger or comment pages. Many news sites allow comments on their website, which can then be retrieved via RSS. Since RSS is simply http requests wrapped in a pretty new interface (XML) bots could easily parse this data to receive commands. An anonymous poster could post a command, and bots could be scheduled to pull the feed every 10-15 minutes. The request would look like legitimate RSS traffic and it would be hard to tell which visitors were bots and which were legitimate.
Using a form of encryption the botnet operator could even protect his botnet so others were unable to issue commands. High profile news and blogging sites might not be so helpful with requests to disable portions of their website because a botnet used it as a command and control vector. They might be more willing to assist law enforcement though, certainly more willing than some ISP's.
So how do users protect themselves, and the rest of the internet community?
First, users should use common sense. Don't click links in email or instant messenger! If the email contains a link, use the cut and paste function to visit URLs. If you're offered a picture or video in instant messenger, verify the sender sent the file and only then use your best judgment before proceeding.
Don't download untrusted software. Even if its recommended by your neighborhood computer genius (highschool student) - do research with an internet search engine. What do others say about it?
Don't surf as an administrator. Even if you do pick up a piece of malware, if you're logged in with limited privileges you will be less likely to install harmful malware.
Online banking should be done from a secure location. Do not access your bank account from hotspots like coffee shops or restaurants. Avoid doing so from work as well - remember in the United States you have no right to privacy on your corporate PC, which likely means your boss is watching where you surf. He or she might just be using a keystroke logger.
Never give your personal information on the internet. Your bank will not notify you of account problems via email - and in the event that changes over the next few years, bank pages are usually encrypted. Watch for "https://" at the beginning of your URL bar. Watch for the padlock icon on most browsers. If you're presented with an expired or self signed certificate, cancel the connection and notify the webmaster immediately.
Consider using a Sandboxer for programs that access the internet. SandboxIE is a great piece of software that will wrap around web browsers, email clients, instant messengers, just about any application that accesses the internet. It uses temporary user space to protect you from hostile code.
Don't consider "known" sites trusted. No site is ever trusted. Sites are compromised every day. Many times these compromises point to code that will attempt to compromise your PC.
If possible, disable Javascript for sites you casually visit. Using the NoScript Firefox plugin is an excellent idea for most users. This is becoming increasingly harder as poor coders are hired to develop websites.
Use firewalls at both the router and operating system level.
Turn your pc off when not in use. Even if your machine is infected, the damage it can do would be limited to the time you spend on your system. Most users are on their home computer for only a few hours a day.
Keep your Antivirus definitions and application patches up to date. Remember many third party applications will not update every month like your operating system. You should do this manually or work with the vendor to schedule updates.
Alternative operating systems are no excuse for poor security practices. Linux has malware, OSx has malware, BSD has malware. Keep your security hat on even if you don't run the targeted OS of the month.
Report suspected botnet activity and spam. CastleCops and Shadowserver have excellent resources available to help report malicious activity. DISOG staff always welcomes submissions via email (staff [-at-] disog.org).
The following post may help drive some botnet operators deeper underground, but the concepts are not new. In many cases these concepts are in use today. I presented on these topics a year ago at the 5th Botnet Task Force conference. For a year security researchers and law enforcement have had the chance to reflect on my presentation and develop mitigation.
Distributed Command and Control is simply a term we use to identify botnets where the operator has learned that directly controlling a large botnet is a big risk to himself and his network. Large scale botnets still exist today, however the operators are wisely breaking these networks up into many smaller networks - or using peer to peer communication. Since the networks are spread out, its harder to eliminate the threat of one attacker.
For example, if a botnet operator takes his 50,000 bots, and spreads them out into 10 networks, each net could have 5,000 drones. By spreading his network out, he mitigates some of the threat from rival operators, botnet hunters, ISPs, and law enforcement. Even if one controller node was taken offline, the botnet operator has 45,000 bots to retaliate with. In many circumstances this gives an operator the heads up he needs to update his 45,000 other bots and protect his empire.
As recent as two years ago, we've started seeing botnets using a pyramid structure, like the simplified image below.
A botnet operator is represented at the top of this flow chart. He communicates with a smaller botnet of only a couple dozen drones. Those drones then communicate with many larger botnets, who perform the stated action. This provides the botnet operator a layer of protection. Now the experienced researchers or law enforcement must find the smaller net, to identify the botnet operator. This is time consuming work, and with out the cooperation of ISP's, its hard work. Even if a controller node is found, it is much easier to snoop on a net with 5,000-10,000 drones than it is one with less than 100 drones.
This distributed structure also helps if the botnet operator wants to rent out or sale portions of his bot. One chunk can be used for spam, while another may perform better in Denial of service type activities.
Another example of distributed structure is the P2P scenario, where the botnet operator issues a command, which is passed to a number of supernodes, whom then pass it to the single peers.
Mapping peer to peer and other types of DC&C's are still possible. It was done with Stormworm and will continue to be done with future P2P botnets. I wont highlight how researchers are doing this mapping, simply because we need to weigh teaching public (including bad-guys) and keeping an ace up our sleeves. I'm hoping this post will spark many closed door conversations to help investigate other methods for tracking and identifying.
As part of the BTF presentation I gave, I wanted to outline additional C&C vectors that could be used. The idea that really caught my eye was based on hiding in plain site. Using protocols that are commonly used by millions of users every day. CME711 (Stormworm) has been easy to keep on top of, because of the mistakes they make in maintaining their DNS (fast flux), registering their domains and using UDP P2P traffic. Because of that UDP P2P traffic many large corporations have been immune - they disable UDP outbound.
The number of infected machines would increase dramatically if the used a connection model similar to Skype.
So back to hiding in plain sight - What would you say to a bot that received its commands over RSS? News readers use RSS to gather headlines and a few lines of news. Users are able to quickly choose articles that interest them, while ignoring those that do not. Millions of people subscribe to RSS feeds, and many of those feeds are of blogger or comment pages. Many news sites allow comments on their website, which can then be retrieved via RSS. Since RSS is simply http requests wrapped in a pretty new interface (XML) bots could easily parse this data to receive commands. An anonymous poster could post a command, and bots could be scheduled to pull the feed every 10-15 minutes. The request would look like legitimate RSS traffic and it would be hard to tell which visitors were bots and which were legitimate.
Using a form of encryption the botnet operator could even protect his botnet so others were unable to issue commands. High profile news and blogging sites might not be so helpful with requests to disable portions of their website because a botnet used it as a command and control vector. They might be more willing to assist law enforcement though, certainly more willing than some ISP's.
So how do users protect themselves, and the rest of the internet community?
First, users should use common sense. Don't click links in email or instant messenger! If the email contains a link, use the cut and paste function to visit URLs. If you're offered a picture or video in instant messenger, verify the sender sent the file and only then use your best judgment before proceeding.
Don't download untrusted software. Even if its recommended by your neighborhood computer genius (highschool student) - do research with an internet search engine. What do others say about it?
Don't surf as an administrator. Even if you do pick up a piece of malware, if you're logged in with limited privileges you will be less likely to install harmful malware.
Online banking should be done from a secure location. Do not access your bank account from hotspots like coffee shops or restaurants. Avoid doing so from work as well - remember in the United States you have no right to privacy on your corporate PC, which likely means your boss is watching where you surf. He or she might just be using a keystroke logger.
Never give your personal information on the internet. Your bank will not notify you of account problems via email - and in the event that changes over the next few years, bank pages are usually encrypted. Watch for "https://" at the beginning of your URL bar. Watch for the padlock icon on most browsers. If you're presented with an expired or self signed certificate, cancel the connection and notify the webmaster immediately.
Consider using a Sandboxer for programs that access the internet. SandboxIE is a great piece of software that will wrap around web browsers, email clients, instant messengers, just about any application that accesses the internet. It uses temporary user space to protect you from hostile code.
Don't consider "known" sites trusted. No site is ever trusted. Sites are compromised every day. Many times these compromises point to code that will attempt to compromise your PC.
If possible, disable Javascript for sites you casually visit. Using the NoScript Firefox plugin is an excellent idea for most users. This is becoming increasingly harder as poor coders are hired to develop websites.
Use firewalls at both the router and operating system level.
Turn your pc off when not in use. Even if your machine is infected, the damage it can do would be limited to the time you spend on your system. Most users are on their home computer for only a few hours a day.
Keep your Antivirus definitions and application patches up to date. Remember many third party applications will not update every month like your operating system. You should do this manually or work with the vendor to schedule updates.
Alternative operating systems are no excuse for poor security practices. Linux has malware, OSx has malware, BSD has malware. Keep your security hat on even if you don't run the targeted OS of the month.
Report suspected botnet activity and spam. CastleCops and Shadowserver have excellent resources available to help report malicious activity. DISOG staff always welcomes submissions via email (staff [-at-] disog.org).
Labels: Botnet monitoring, Botnet Task Force, CME711, DC and C, javascript, p2p botnet, SandboxIE, Skype, Stormworm, Superbug, supernodes
posted by Nicholas at
05:57
0 Comments
