It's pretty simple - the attackers install backdoor trojans which phone home to various command-and-control (C2) servers. In some cases when the USG identifies a high-value (i.e. involved in corporate and/or government espionage) C2 in the U.S. they get a warrant to monitor all network traffic to and from that host at the upstream. Once you have netflow or pcap data you can pretty easily tell who the compromised companies are when you see their corporate firewall IP hitting the C2 at regular intervals.
Private-sector researchers do this as well sometimes, but you need cooperation from the upstream. Or in some cases, the attackers are sloppy enough to leave behind publicly-accessible server logs ala Shady RAT.
Hardly any of the trojans used by Chinese APT actors are sophisticated at all. All these sophisticated features you listed are fine if you're only looking to launch a single-purpose attack, like a Stuxnet. The Chinese APT actors want to maintain a long-term presence even after they are discovered on the network.
As the sophistication of the malware rises, so does the cost/time involved, so it limits how many trojans you can deploy at once. Once your super-sophisticated trojan with rootkit, traffic tunneling, AV circumvention, strong encryption, disk and network stealth features gets discovered, your capability to maintain a long-term presence ends and you have to develop another one from scratch. There are only so many programmers working at this skill level, you don't find them every day.
The Chinese APT actors' answer to the problem is simply to throw a ton of different entry-level programmers at the problem. Each one basically uses the same feature requirements list and comes up with a completely different malware codebase, each one by default undetected by AV since it is brand new. Then each actor group goes after their targets using a set of those malware families. If one is discovered, that's OK, because nine more are probably still live on the victim network.
You have a chicken-and-the-egg problem. You said: "1.) Recovery Console bootup 2.) listsvc command to spot offending bogus MBR protecting driver (hello_tt.sys)" - in this case you have prior knowledge. You knew there was a rootkit in play, and you knew what it was named.
What if it has borrowed the name of another legit third-party driver? What if the rootkit code is just a stub inside another legit driver? This technique has been used by malware for years now. Now, how do you tell which is the malicious driver and which is not? How do you even tell if there is a rootkit in play at all? The answer is: other tools and techniques and most importantly, a lot of time spent.
You missed the point. Yes, TDL4 malware can be cleaned manually, no one is disputing that. The entire system could be forensically sanitized - manually - using the recovery console or a liveCD. It could take a long time depending on how many payloads had been downloaded and how well they hide. But this is not enough to kill the botnet unless you do this to 4.5 million PCs all at once. I never said your TDL-4 removal steps were incorrect, I just said they would not "kill the botnet", which is what Microsoft is suggesting they can do.
While nothing is impossible in theory, trying to destroy this botnet "one rig at a time" as you suggest would take decades even if you had an army tracking them down and cleaning them. The botnet would die on its own by then because the hard drives of those systems would fail first. Again though, I am reply to Microsoft's claims here, not yours.
The part you are wrong about is being able to use ProcessExplorer to fully sanitize the PC of the remaining malware. The only thing that truly separates malware from non-malware is intent. That's it. A P2P filesharing client and a P2P bot could share 99.999% of the same code, with only a single hidden malicious function. Tell me where in ProcessExplorer you would see the difference.
I'm not sure if you truly understand rootkits if you think they can't hide from ProcessExplorer. Even the simpler kernel-mode rootkits can do this, removing the hidden process from the kernel's linked list of objects - the same list that ProcessExplorer has to request from the OS to show you that tree of parent/child processes.
Making a determination on whether or not a program is malware is very hard to do programatically and even for a human often takes hours poring over the code in a debugger trying to understand the program's intent. If it were so easy, antivirus programs would still be adequate protection in this day and age.
No one said TDL4 can't be cleaned from a single PC. Cleaning it from all of them near-simultaneously is what you would have to do to destroy this botnet. The MSRT tool is not capable of performing the steps you described.
BTW your steps could still leave malware on the system unless you are a forensic/malware expert and can tell good processes from bad in ProcessExplorer. It's not so easy as you make it seem. Even if you are that experienced in process analysis, there could still be other kernel-level rootkits hiding malicious processes from ProcessExplorer. It could take days to truly disinfect a TDL-4-infected system that had been downloading payloads for a while. That's why reformat/reinstall has become the best-practice for dealing with malware, even though it is anathema to most Windows users/admins.
Another thing to note is that Microsoft hasn't destroyed the Rustock botnet, they are merely suppressing it. They will never be able to clean all the infected Rustock PCs, because countless thousands of them don't get Windows updates (either because they are pirated copies of Windows or updates have been disabled by other malware) and thus will never run the MSRT tool. If MS ceases their efforts before every last machine is sitting in a dump somewhere, the botnet could return, however unlikely that the author would bother to restore control.
Have a look at Cronto - it's an out-of-band authentication system, similar to ZTIC but doesn't use an electrical connection to the computer that could be impacted by a malware infection on the PC. Instead it transfers encrypted/signed transaction details via visual code to the Cronto device (or Cronto app running on a camera-enabled smartphone). There are a few other similar systems from other vendors, but Cronto is the only one I've seen with a mobile app so far.
Yeah, that's why most banking fraud trojans that target U.S. banks are compiled on Russian-language PCs and connect back to Russian-developed webserver software. I'm afraid your "well-established" fact doesn't ring true with anyone that actually tracks banking trojans for a living.
Your scenario of corporate chaos isn't accurate when it comes to Storm. Storm isn't self-replicating; it doesn't spread to other internal systems. It can however steal email addresses and possibly other external systems will begin to send Storm social-engineering emails to the rest of the company. However, if you have a sane firewall policy that doesn't allow arbitrary high-port UDP traffic outbound and inbound, the Storm node will never be able to link up to the rest of the botnet, rendering it more of a noisy annoyance than a threat to the company's data.
Re:How are these numbers calculated?
on
Storm Worm Rising
·
· Score: 5, Informative
The estimate is based on the number of unique IPs we've seen attacking networks we monitor, coupled with our knowledge of how the Storm botnet works. We've seen up to 100,000 bots sending the attack (the ecard spam) in a single day. Storm is a multi-tiered botnet, meaning that not all the bots are tasked with sending the emails. Some are supernodes (first-tier), designed to serve up the ecard executables via HTTP and facilitate communication between the regular (second-tier) nodes. Another factor is that some second-tier nodes will never be seen attacking, since they may be behind firewalls that block port 25 outbound or at an ISP that is doing SMTP blocking, so they may be part of the botnet but difficult to count.
In reality, the only source that can give you a precise count for the Storm botnet is the Storm controller - and he/she's not talking. So we do the best we can at estimating its size given the data available.
I've noticed some comments to the effect that it's easy to spot because it is a.doc.exe extension on the attachment. Not so! The latest runs of these scams have been EXE files embedded within actual MS Word or RTF files. Inside the document is a PDF icon and a note telling the user to click on the icon to view the invoice (or complaint, depending on the scam). This is a different method of social engineering than we usually see. That plus the targeted nature of the emails is what makes this sophisticated. It may not fool the savvy user, but as many execs haven't seen something of this nature before, they are likely to click and open the embedded executable. Most are just trusting their AV to warn them if there is anything wrong with the file, which is a big mistake these days.
If you work corporate security, make sure you are watching for signs of the data exfiltration on the network. I've written some Snort IDS signatures which are available here:
http://www.secureworks.com/research/threats/bbbphi sh
I'm the author of the technical writeup detailing the attack on the rival spam group. But the only reason I was investigating the DDoS attacks launched by the Storm Worm/Peacomm/Nuwar is due to my own site being attacked after I detailed the pump-and-dump stock spam operation of the Rustock trojan. It is getting riskier to publish research on viruses and spam. I believe since spammers were able to take out Blue Security by DDoS attack, they are getting bolder in who they target. There's no downside for them.
It not like I'm the only one who ever figured out how to spy on botnet control channels. This has been going on for years. Some researchers only spy on the botnet to find out what the botnet is being used for. Some even take it upon themselves to try and "clean" the infected systems of the bots (Mocbot has a "remove" command, by the way, but you have to have the correct user@host mask). Botherders sometimes even spy on each others channels, to try and take control of less-protected botnets from other botherders.
We're not just talking about spyware here - you feel you've completely cleaned the infection because you no longer notice the intrusive symptoms of popup-ads, slowness, etc. However, how would you know the initial infection hadn't subsequently downloaded a keystroke logger (bought commercially, they can go months without being detected by AV) along with a rootkit to hide it? Rootkit scanners, like AV, are having to play a constant game of keep-up with the commercial malware writers.
If you're a malware expert, yes, you can find and kill all instances of malware on a system without a rebuild. It used to be easier, but the profit motive has really upped the ante for the malware writers, to the point where for 99.999% of the population, a rebuild is in order.
The actual quote in my analysis is "unless you are a malware expert..."
Running a liveCD with a rootkit scanner and an antivirus isn't going to cut it - you have to have the knowledge to know what to go after - you'd be surprised at how much malware doesn't get detected by scanners even months after its been released.
Although I might use liveCDs myself to do malware recovery, average users are going to be in over their heads. So I didn't mention it.
Yes, actually there is a remove command built in to Mocbot. However, you have to issue the command from the proper user@host mask; something you can't do unless you have admin access to the IRC server.
An alternative is to use DNS to redirect the bots to a blackhole IRC server where the remove command can be executed. Of course, this only works if you have control over the DNS (e.g. an ISP redirecting their own users). Getting someone responsible for the authoritative DNS server is not likely to happen given the Chinese origin.
Modern botnet command-and-control IRC servers don't give out information like who else is connected. In this Mocbot C&C, you join the channel, get an encrypted command (in the channel topic) which tells the bot to join another channel. In that channel, another encrypted command in the topic tells the bot to download and execute a trojan (which currently is detected by some AV as Trojan-Proxy.Win32.Ranky.fv).
The reason for all this subterfuge is, if the AV companies aren't spying on the control channel, they have no way to know about the second-stage infection, unless they get lucky - so even if they do clean the Mocbot infection, the proxy trojan still resides on the machine.
Slashdot Mirror
Well that's kind of hurtful...
It's pretty simple - the attackers install backdoor trojans which phone home to various command-and-control (C2) servers. In some cases when the USG identifies a high-value (i.e. involved in corporate and/or government espionage) C2 in the U.S. they get a warrant to monitor all network traffic to and from that host at the upstream. Once you have netflow or pcap data you can pretty easily tell who the compromised companies are when you see their corporate firewall IP hitting the C2 at regular intervals.
Private-sector researchers do this as well sometimes, but you need cooperation from the upstream. Or in some cases, the attackers are sloppy enough to leave behind publicly-accessible server logs ala Shady RAT.
Hardly any of the trojans used by Chinese APT actors are sophisticated at all. All these sophisticated features you listed are fine if you're only looking to launch a single-purpose attack, like a Stuxnet. The Chinese APT actors want to maintain a long-term presence even after they are discovered on the network.
As the sophistication of the malware rises, so does the cost/time involved, so it limits how many trojans you can deploy at once. Once your super-sophisticated trojan with rootkit, traffic tunneling, AV circumvention, strong encryption, disk and network stealth features gets discovered, your capability to maintain a long-term presence ends and you have to develop another one from scratch. There are only so many programmers working at this skill level, you don't find them every day.
The Chinese APT actors' answer to the problem is simply to throw a ton of different entry-level programmers at the problem. Each one basically uses the same feature requirements list and comes up with a completely different malware codebase, each one by default undetected by AV since it is brand new. Then each actor group goes after their targets using a set of those malware families. If one is discovered, that's OK, because nine more are probably still live on the victim network.
You have a chicken-and-the-egg problem. You said: "1.) Recovery Console bootup 2.) listsvc command to spot offending bogus MBR protecting driver (hello_tt.sys)" - in this case you have prior knowledge. You knew there was a rootkit in play, and you knew what it was named.
What if it has borrowed the name of another legit third-party driver? What if the rootkit code is just a stub inside another legit driver? This technique has been used by malware for years now. Now, how do you tell which is the malicious driver and which is not? How do you even tell if there is a rootkit in play at all? The answer is: other tools and techniques and most importantly, a lot of time spent.
You missed the point. Yes, TDL4 malware can be cleaned manually, no one is disputing that. The entire system could be forensically sanitized - manually - using the recovery console or a liveCD. It could take a long time depending on how many payloads had been downloaded and how well they hide. But this is not enough to kill the botnet unless you do this to 4.5 million PCs all at once. I never said your TDL-4 removal steps were incorrect, I just said they would not "kill the botnet", which is what Microsoft is suggesting they can do.
While nothing is impossible in theory, trying to destroy this botnet "one rig at a time" as you suggest would take decades even if you had an army tracking them down and cleaning them. The botnet would die on its own by then because the hard drives of those systems would fail first. Again though, I am reply to Microsoft's claims here, not yours.
The part you are wrong about is being able to use ProcessExplorer to fully sanitize the PC of the remaining malware. The only thing that truly separates malware from non-malware is intent. That's it. A P2P filesharing client and a P2P bot could share 99.999% of the same code, with only a single hidden malicious function. Tell me where in ProcessExplorer you would see the difference.
I'm not sure if you truly understand rootkits if you think they can't hide from ProcessExplorer. Even the simpler kernel-mode rootkits can do this, removing the hidden process from the kernel's linked list of objects - the same list that ProcessExplorer has to request from the OS to show you that tree of parent/child processes.
Making a determination on whether or not a program is malware is very hard to do programatically and even for a human often takes hours poring over the code in a debugger trying to understand the program's intent. If it were so easy, antivirus programs would still be adequate protection in this day and age.
No one said TDL4 can't be cleaned from a single PC. Cleaning it from all of them near-simultaneously is what you would have to do to destroy this botnet. The MSRT tool is not capable of performing the steps you described.
BTW your steps could still leave malware on the system unless you are a forensic/malware expert and can tell good processes from bad in ProcessExplorer. It's not so easy as you make it seem. Even if you are that experienced in process analysis, there could still be other kernel-level rootkits hiding malicious processes from ProcessExplorer. It could take days to truly disinfect a TDL-4-infected system that had been downloading payloads for a while. That's why reformat/reinstall has become the best-practice for dealing with malware, even though it is anathema to most Windows users/admins.
Another thing to note is that Microsoft hasn't destroyed the Rustock botnet, they are merely suppressing it. They will never be able to clean all the infected Rustock PCs, because countless thousands of them don't get Windows updates (either because they are pirated copies of Windows or updates have been disabled by other malware) and thus will never run the MSRT tool. If MS ceases their efforts before every last machine is sitting in a dump somewhere, the botnet could return, however unlikely that the author would bother to restore control.
Have a look at Cronto - it's an out-of-band authentication system, similar to ZTIC but doesn't use an electrical connection to the computer that could be impacted by a malware infection on the PC. Instead it transfers encrypted/signed transaction details via visual code to the Cronto device (or Cronto app running on a camera-enabled smartphone). There are a few other similar systems from other vendors, but Cronto is the only one I've seen with a mobile app so far.
Nope, I'm pretty sure it's a reference to guavas, considering the complete path was:
b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb
It's not. There's no exploit code sent, just random bytes and the replies are discarded.
I think they're attempting to evade brain-dead automated protocol inspection, not trying to fool a human.
They're not. The connections are far too infrequent (15 connections, then sleep for 30 hours).
Yeah, that's why most banking fraud trojans that target U.S. banks are compiled on Russian-language PCs and connect back to Russian-developed webserver software. I'm afraid your "well-established" fact doesn't ring true with anyone that actually tracks banking trojans for a living.
Ah yes, as hilarious as the first hundred times I've seen that joke posted about me. Maybe I _should_ just change my name to !jonstewart...
-Joe
Your scenario of corporate chaos isn't accurate when it comes to Storm. Storm isn't self-replicating; it doesn't spread to other internal systems. It can however steal email addresses and possibly other external systems will begin to send Storm social-engineering emails to the rest of the company. However, if you have a sane firewall policy that doesn't allow arbitrary high-port UDP traffic outbound and inbound, the Storm node will never be able to link up to the rest of the botnet, rendering it more of a noisy annoyance than a threat to the company's data.
The estimate is based on the number of unique IPs we've seen attacking networks we monitor, coupled with our knowledge of how the Storm botnet works. We've seen up to 100,000 bots sending the attack (the ecard spam) in a single day. Storm is a multi-tiered botnet, meaning that not all the bots are tasked with sending the emails. Some are supernodes (first-tier), designed to serve up the ecard executables via HTTP and facilitate communication between the regular (second-tier) nodes. Another factor is that some second-tier nodes will never be seen attacking, since they may be behind firewalls that block port 25 outbound or at an ISP that is doing SMTP blocking, so they may be part of the botnet but difficult to count.
In reality, the only source that can give you a precise count for the Storm botnet is the Storm controller - and he/she's not talking. So we do the best we can at estimating its size given the data available.
I've noticed some comments to the effect that it's easy to spot because it is a .doc.exe extension on the attachment. Not so! The latest runs of these scams have been EXE files embedded within actual MS Word or RTF files. Inside the document is a PDF icon and a note telling the user to click on the icon to view the invoice (or complaint, depending on the scam). This is a different method of social engineering than we usually see. That plus the targeted nature of the emails is what makes this sophisticated. It may not fool the savvy user, but as many execs haven't seen something of this nature before, they are likely to click and open the embedded executable. Most are just trusting their AV to warn them if there is anything wrong with the file, which is a big mistake these days.
i sh
If you work corporate security, make sure you are watching for signs of the data exfiltration on the network. I've written some Snort IDS signatures which are available here:
http://www.secureworks.com/research/threats/bbbph
I'm the author of the technical writeup detailing the attack on the rival spam group. But the only reason I was investigating the DDoS attacks launched by the Storm Worm/Peacomm/Nuwar is due to my own site being attacked after I detailed the pump-and-dump stock spam operation of the Rustock trojan. It is getting riskier to publish research on viruses and spam. I believe since spammers were able to take out Blue Security by DDoS attack, they are getting bolder in who they target. There's no downside for them.
http://www.secureworks.com/analysis/spamthru/
You make a good point. :)
-Joe
As long as they don't call me Stew... I really dislike that.
-Joe
It not like I'm the only one who ever figured out how to spy on botnet control channels. This has been going on for years. Some researchers only spy on the botnet to find out what the botnet is being used for. Some even take it upon themselves to try and "clean" the infected systems of the bots (Mocbot has a "remove" command, by the way, but you have to have the correct user@host mask). Botherders sometimes even spy on each others channels, to try and take control of less-protected botnets from other botherders.
-Joe
We're not just talking about spyware here - you feel you've completely cleaned the infection because you no longer notice the intrusive symptoms of popup-ads, slowness, etc. However, how would you know the initial infection hadn't subsequently downloaded a keystroke logger (bought commercially, they can go months without being detected by AV) along with a rootkit to hide it? Rootkit scanners, like AV, are having to play a constant game of keep-up with the commercial malware writers.
If you're a malware expert, yes, you can find and kill all instances of malware on a system without a rebuild. It used to be easier, but the profit motive has really upped the ante for the malware writers, to the point where for 99.999% of the population, a rebuild is in order.
-Joe
The actual quote in my analysis is "unless you are a malware expert..."
Running a liveCD with a rootkit scanner and an antivirus isn't going to cut it - you have to have the knowledge to know what to go after - you'd be surprised at how much malware doesn't get detected by scanners even months after its been released.
Although I might use liveCDs myself to do malware recovery, average users are going to be in over their heads. So I didn't mention it.
-Joe
Yes, actually there is a remove command built in to Mocbot. However, you have to issue the command from the proper user@host mask; something you can't do unless you have admin access to the IRC server.
An alternative is to use DNS to redirect the bots to a blackhole IRC server where the remove command can be executed. Of course, this only works if you have control over the DNS (e.g. an ISP redirecting their own users). Getting someone responsible for the authoritative DNS server is not likely to happen given the Chinese origin.
Modern botnet command-and-control IRC servers don't give out information like who else is connected. In this Mocbot C&C, you join the channel, get an encrypted command (in the channel topic) which tells the bot to join another channel. In that channel, another encrypted command in the topic tells the bot to download and execute a trojan (which currently is detected by some AV as Trojan-Proxy.Win32.Ranky.fv).
The reason for all this subterfuge is, if the AV companies aren't spying on the control channel, they have no way to know about the second-stage infection, unless they get lucky - so even if they do clean the Mocbot infection, the proxy trojan still resides on the machine.