With the recently disclosed hacking incident inside Google and other major companies, much of the world has begun to wake up to what the infosec community has known for some time – there is a persistent campaign of “espionage-by-malware” emanating from the People’s Republic of China (PRC). Corporate and state secrets both have been shanghaied over a period of five or more years, and the activity becomes bolder over time with little public acknowledgement or response from the U.S. government.
Just finished a couple of back-to-back research pieces. First, a rundown on the C&C protocol encryption in the latest Virut, then a look at a new Firefox browser hijacker that carries out a clever scheme to defraud Google’s Adsense for Search program.
Also, I’m now posting my new research to Twitter as soon as it is available for public consumption. Follow joestewart71 to get these links as soon as they are posted.
If you’ve been reading any news at all on the Internet in the past week, you’ve probably heard that Conficker Armageddon is approaching, and it’s scheduled for April 1st, only a few days from now. The SecureWorks Counter Threat Unit has been receiving an increasing number of inquiries asking what one needs to do to prepare for the impending April 1st outbreak.
The truth is, there will be no April 1st outbreak, despite what some of the press stories have said so far. The only thing that will happen with Conficker on April 1st is that already-infected systems will begin to use a new algorithm to locate potential update servers. There, that’s not so scary, is it?
Recently, with the help of Spamhaus, we were given access to files collected from yet another Ozdok/Mega-D command-and-control server. Although we have seen the controller code before, it was surprising to learn that this variant was collecting screenshots from its victims’ computers, and that thousands of them were stored on the control server. Grabbing screenshots isn’t new for backdoor trojans, but it’s the first time we’ve seen this functionality in a spambot.
On October 23, 2008, Microsoft released an out-of-cycle emergency patch for a flaw in the Windows RPC code. The reason for this unusual occurance was the discovery of a “zero-day” exploit being used in the wild by a worm (or trojan, depending on how you look at it). The announcement of a new remote exploit for unpatched Windows systems always raises tension levels among network administrators. The fact that this one was already being used by a worm evoked flashbacks of Blaster and Sasser and other previous threats that severely impacted the networked world.
Writing good antivirus software is hard. Just ask the developer at a major antivirus company who was infected with the Coreflood trojan on his personal computer for over a year. Perhaps he was just testing their product, but it seems odd to have allowed the trojan to capture some of his personal information. Fortunately the antivirus developer was not a domain administrator on the company’s network, so Coreflood didn’t spread to every other system in the Windows domain like it did at several other businesses, hospitals and government organizations.
On Friday April 11th I’ll be giving a talk at RSA titled “Procotols and Encryption of the Storm Botnet”. I intend to give attendees a full understanding of the Storm botnet’s structure and how all the pieces of the puzzle fit together to make Storm one of the most resilient botnets known.
The latest Storm variants have a new twist. They now use a 40-byte key to encrypt their Overnet P2P traffic. This means that each node will only be able to communicate with nodes that use the same key. This effectively allows the Storm author to segment the Storm botnet into smaller networks. This could be a precursor to selling Storm to other spammers, as an end-to-end spam botnet system, complete with fast-flux DNS and hosting capabilities. If that’s the case, we might see a lot more of Storm in the future.
We’ve gotten some inquiries as to how to find users infected by the recent BBB/IRS/FTC/Proforma trojan scams on corporate networks where an IDS/IPS device that can detect the exfiltration traffic might not be in play.
If you keep logs of firewall/proxy or DNS server traffic, you may be able to spot infected users by traffic analysis. This activity has been going on since at least February, so it is prudent to go back in the logfiles at least until the beginning of 2007 when searching.