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.

"Operation Aurora" is the latest in a series of attacks originating out of Mainland China.  Previous attacks have been known as – "GhostNet" and "Titan Rain." Operation Aurora takes its name directly from the hackers this time – the name was coined after virus analysts found unique strings in some of the malware involved in the attack. These strings are debug symbol file paths in source code that has apparently been custom-written for these attacks. The paths were left behind in the compiled binaries as shown below:

Although the code behind Operation Aurora has only recently been discovered, and the known samples of the main backdoor trojan (called Hydraq by antivirus companies) appear to be no older than 2009. It appears that development of Aurora has been in the works for quite some time – some of the custom modules in the Aurora codebase have compiler timestamps dating back to May 2006. This date is only a year or so after the Titan Rain attacks, which largely used widely-available trojans that were already known to antivirus companies. As a result of using completely original code and then only in highly-targeted attacks, the Aurora code seems to have escaped detection for quite some time.

The compiler often offers other clues to a malware sample’s origin. For instance, if the binary uses a PE resource section, the resource’s headers will often provide a language code. The Hydraq component does use a resource section, but in this case, the author was careful to either compile the code on an English-language system, or they edited the language code in the binary after-the-fact. So outside of the fact that PRC IP addresses have been used as control servers in the attacks, there is no "hard evidence" of involvement of the PRC or any agents thereof.

There is one interesting clue in the Hydraq binary that points back to mainland China, however. While analyzing the samples, I noticed a CRC (cyclic redundancy check) algorithm that seemed somewhat unusual. CRCs are used to check for errors that might have been introduced into stored or transferred data. There are many different CRC algorithms and implementations of those algorithms, but this is one I had not previously seen in any of my reverse-engineering efforts. Below is the raw assembly code for the CRC algorithm in Hydraq:

The first thing that is unusual about this CRC algorithm is the size of the table of constants (the incrementing values in the left pane of the assembly listing). Most 16 or 32-bit CRC algorithms use a hard-coded table of 256 constants. The CRC algorithm used in Hydraq uses a table of only 16 constants; basically a truncated version of the typical 256-value table. By decompiling the algorithm and searching the Internet for source code with similar constants, operations and a 16-value CRC table size, I was able to locate one instance of source code that fully matched the structural code implementation in Hydraq and also produced the same output when given the same input:

This source code was created to implement a 16-bit CRC algorithm compatible with the implementation known as "CRC-16 XMODEM", while requiring only a 16-value CRC table. It is actually a clever optimization of the standard CRC-16 reference code that allows the CRC-16 algorithm to be used in applications where memory is at a premium, such as hobby microcontrollers. Because the author used the C "int" type to store the CRC value, the number of bits in the output is dependent on the platform on which the code is compiled. In the case of Hydraq, which is a 32-bit Windows DLL, this CRC-16 implementation actually outputs a 32-bit value, which makes it compatible with neither existing CRC-16 nor CRC-32 implementations.

Perhaps the most interesting aspect of this source code sample is that it is of Chinese origin, released as part of a Chinese-language paper on optimizing CRC algorithms for use in microcontrollers. The full paper was published in simplified Chinese characters, and all existing references and publications of the sample source code seem to be exclusively on Chinese websites. This CRC-16 implementation seems to be virtually unknown outside of China, as shown by a Google search for one of the key variables, "crc_ta[16]". At the time of this writing, almost every page with meaningful content concerning the algorithm is Chinese:

This information strongly indicates the Aurora codebase originated with someone who is comfortable reading simplified Chinese. Although source code itself is not restrained by any particular human language or nationality, most programmers reuse code documented in their native language. To do otherwise is to invite bugs and other unexpected problems that might arise from misunderstanding of the source code’s purpose and implementation as given by the code comments or documentation.

In my opinion, the use of this unique CRC implementation in Hydraq is evidence that someone from within the PRC authored the Aurora codebase.  And certainly, considering the scope, choice of targets and the overwhelming boldness of the attacks (in light of the harsh penalties we have seen handed out in communist China for other computer intrusion offenses), this creates speculation around whether the attacks could be state-sponsored.

###

On April 1, 2009, while the rest of the cybersecurity world was largely focused on the Conficker worm, Senators John (Jay) Rockefeller and Olympia Snowe introduced the Cybersecurity Act of 2009. Since the hype over Conficker has died down now, I’ve had a chance to review the text of this somewhat controversial bill and add my two cents to the discussion. There are 23 sections to the bill, a few of which have raised some alarm in the infosec community.

The two most often-seen complaints in the blogosphere are:

1. The bill gives the President of the United States the power to "turn off the Internet" in an emergency.
2. The bill requires mandatory licenses for practicing infosec professionals.

Complaint number one seems like FUD to an extent; the bill as worded reads "The President– …may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network."

Some have taken "critical infrastructure" to mean communications networks, i.e. the Internet backbone providers. Unfortunately, the bill defines critical infrastructure as whatever the President says is critical infrastructure. So the criticism of the ambiguity here is valid.

But this idea that the White House could shut down the Internet shows a largely U.S.-centric bias when it comes to thinking about what the Internet actually is. Further, such a move during an emergency would likely have worse unforeseen consequences than whatever attack might have prompted it. And it’s unlikely that such an order would be given without consulting technical experts as to the alternatives for mitigating a large-scale attack. I happen to know several Internet infrastructure experts, and I can’t think of any that would say "Hey, let’s just shut off the Internet! That will solve everything!"

Complaint number two has more validity in my book – licensing of security professionals is just plain unnecessary and just creates more bureaucracy. The security industry already has numerous certification programs, all of which already fill the perceived need to have standards in knowledge and practice. If one argues whether a certification proves anything at all, those same arguments could be applied to government licenses as well.

And who gets licensed? According to the bill, this applies to a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President’s designee, as an infrastructure information system or network. I happen to work for a company that provides such services. Do I have to be licensed? Does everyone who works at the company have to be licensed? Where is the delineation?

Despite these and other shortcomings, there are several programs in this Cybercrime bill that I approve of, such as the creation of the Cybersecurity Advisory Panel and the Federal Cyber Scholarship-for-Service program. However, some other provisions seem to be potential boondoggles, such as the state and regional cybersecurity enhancement program.   Throwing money at the problem, at a regional level as opposed to a national level, is not the answer when the majority of skilled security professionals are located in a handful of metropolitan areas.

However, the primary problem with this bill (and any bill put forth by a single government) is that it does nothing to address the larger problem of cybercrime, malware, and the massive outflow of stolen cash from U.S. and European banks to organized crime networks. This is the biggest threat we face on the Internet today, and it won’t be solved by any single piece of legislation (although I wouldn’t mind seeing a Senate bill mandating BCP 38).

The bottom line – until networks everywhere are held responsible for the abuse coming from their systems, the problem won’t get any better.  Note to the Obama administration—if the US government really wants to accomplish something, begin work on a global treaty against Internet and computing abuse, and put an end to the safe havens that cybercriminals currently enjoy in some countries.

The 2009 RSA conference kicks off next week in San Francisco. It looks like a busy week for me – I’ll be presenting first on Tuesday, April 21st at the SecureWorks booth on the showfloor at 1:00 PM PDT. This will be a “Conficker Q&A” session. I’ll be answering questions with the knowledge I’ve gained from reverse-engineering Conficker and also from my participation in the Conficker Working Group. So, if you have any burning questions about the threat posed by the Conficker worm, drop by the booth at that time and I’ll try to answer them.

On Wednesday at 9:10 AM, I’ll be participating in a panel discussion called “Deconstructing The Modern Online Criminal Ecosystem” along with panelists Lawrence Baldwin (MyNetWatchman) and Dr. Robert Bruen (KnujOn). This should be a very interesting discussion, offering some behind-the-scenes insights into the cybercrime economy from experts who are in the trenches fighting it every day. The work being done by my co-panelists is amazing, but rarely do you get to hear about it in a public forum. The panel will be led by Patrick Peterson of Cisco’s IronPort division. Patrick is a Cisco Fellow and a renowned speaker and security expert, so I expect we may reach the highest potential of panel discussions.

Finally, on Thursday I’ll be delivering my own presentation entitled “Demonetizing Botnets” at 2:10 PM. This talk outlines my ideas for how we should restructure our efforts at fighting not just botnets, but cybercrime in general, both long and short-term. In this presentation, I will introduce a concept I call “offense-in-depth”, which I believe is the only approach that can address most of the cybercrime problems we are currently facing, given the current environment with respect to law enforcement’s challenges in cyberspace and pervasive vulnerabilities in computing and networking. I’m not saying my plan is any kind of silver bullet, but I hope it becomes part of the arsenal of everyone out there who is attempting to stem the tide of malicious software and computer intrusion. If you are interested in hearing my take on these matters, please attend. If anything I say inspires you to action, please meet up with me after the talk, and we can discuss the issues further. Hope to see you there!

Don’t panic. If you’re reading this, you’re probably not infected with Conficker.C. If you were already infected, you wouldn’t be able to access any page on secureworks.com, due to the worm author’s apparent dislike for the removal instructions we posted for earlier Conficker variants. So we have joined the list of over a hundred sites Conficker.C victims just can’t visit. (Of course, the worm still doesn’t block any sites if you are using an HTTP proxy, but this could change after its author reads this blog post).

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?

So why all the fuss over the 1st? It all started over a massive increase in the number of domain names being used by the worm to find control servers. In the A and B variants, there were only 250 possible domain names each day at a handful of top-level domains (TLDs) for the worm to utilize. Then, along came the Conficker Working Group (nee Conficker Cabal) who set about learning the algorithm and disabling the domain names ahead of time. This didn’t sit well with the Conficker author(s), so Conficker.C was released with some additional features.

First, it would now use its own peer-to-peer protocol to allow infected nodes to update each other without the use of a centralized command-and-control server. (One might think this could allow other parties to gain control over the botnet created by the worm, but the author included digital signature checks into the code – no updates will be accepted by Conficker unless they are signed by the author’s private encryption key.)

Second, Conficker.C will use a new algorithm to generate 50,000 unique controller domain names at 110 different TLDs every day. This activity is set to start on April 1st, and since it seems too large a problem for even the Conficker Working Group to handle, the press is worried that this massive botnet might finally be unleashed to wreak havoc upon the world’s networks.

But you should not fear April 1st, 2009, and here’s why:

1. Conficker.C is already able to receive updates via its P2P protocol today, so focusing on the April 1st date is misguided.
2. Don’t underestimate the reach of the Conficker Working Group. These are the security industry’s heavy-hitters, and you can be sure they are working diligently to mitigate the domain issue.
3. Even though there are 50,000 domains to look at, they are being closely monitored, and if any malicious servers do appear, they will likely be taken down or null-routed very quickly.
4. If the author(s) of Conficker planned some massive update of malicious code, they certainly wouldn’t do it on the one day everyone is watching for it.

My personal opinion is that the April 1st activation of the new algorithm may simply be a distraction, a kind of practical joke on the part of the worm author(s). Conficker may not be something to laugh about, but it’s also not quite as serious as one might believe from reading about it in the press.

If you’ve already taken steps to protect your network against Conficker and similar network worms, you’ll have plenty of time on April 1st to read all the same old fake news stories/blog posts and prank your co-workers.

Earlier this week, reports began to circulate in the media about Chinese hackers selling $200 USD iTunes gift cards online for 17.90 RMB (about $2.60 USD). It was explained that these hackers were able to acheive the remarkable feat of cracking Apple’s algorithm for generating the gift voucher codes, and were thus able to generate as many cards as they liked, all of which would be redeemable in the iTunes store.

This would be a pretty clever hack if it were true – however, something just isn’t quite right here. Nowhere in these articles does it explain one simple thing – how do they manage to generate activated iTunes gift voucher codes? When you purchase an iTunes gift card, it has to be activated before it will work, otherwise you will get an inactive code message from the iTunes store when attempting to redeem it. If this were not the case, anyone could simply walk into any of the numerous retail outlets that stock iTunes cards, grab a hook-full and run out of the door with hundreds to thousands of dollars in iTunes money. This would be a shoplifter’s dream! But, much to the dismay of those who have already tried this, the cards are simply worthless plastic until they are activated at the point-of-sale. Since this system works well and doesn’t require a “secure” algorithm to generate the numbers, it stands to reason that the same system would be used for the online gift certificate vouchers.

But, third-party reports have confirmed that the voucher codes being sold by the Chinese hackers are in fact redeemable in iTunes (not sure how they verified this without exposing themselves to criminal charges however). So what is actually happening here? I see two likely scenarios: either the Chinese hackers have managed to penetrate Apple’s internal network and/or iTunes gift card database and are directly stealing activated numbers before they can be used, or they are simply using stolen credit card numbers to purchase the cards.

Chinese hackers are certainly no strangers to penetrating networks via targeted attacks (although a targeted attack against Apple would not fit their previous modus operandi of using 0-day Windows exploits). They are also quite adept at SQL injection attacks, so a database hack isn’t an unreasonable suggestion either.

But Occam’s razor suggests that this is more likely to be a case of the hackers using stolen credit card numbers to purchase the gift voucher codes from iTunes and then reselling them. Finding a way to “cash out” stolen credit card numbers is always a primary problem for credit card theives, also known as “carders”. Sometimes carders buy goods online and resell them, but it requires a real-world “drop” where the delivery of the physical items can be made without leading the police to their door. But transferring iTunes codes can be done electronically and anonymously, and since it is something with almost world-wide demand, there is never going to be a shortage of persons willing to buy the discounted codes without asking questions. And they can explain away the mystery of where the codes come from by simply saying “Oh, we hacked the algorithm. Yeah, that’s the ticket…”

Since Apple has yet to comment on this, we can only speculate about these matters until the Chinese government takes some sort of action and arrests are made. In the meantime, if you know anyone whose credit card number has been used to make an unauthorized purchase of a large dollar value of iTunes gift codes, make sure to tell them to report it to the Internet Crime Complaint Center (IC3) right after they notify their credit card company of the fraud.

We’ve done a lot of analysis on the Ozdok (aka Mega-D) trojan botnet in the past. Even now it is one of the biggest botnets of 2009, despite having its primary sponsor shut down by court order in October 2008.

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.

What can be seen in these screenshots is mostly what you’d expect: people checking up on social networking pages, looking at videos, reading their email, browsing porn sites, and a fair number running anti-spyware tools (not that they helped at all). One might ask, “why would a botnet spammer be interested in people’s desktop screenshots?” It could be for a couple of different reasons.

One reason could be to search for interesting machines in order to further probe them for financial credentials or intellectual property. This theory could be supported by the fact that we found a WinVNC server binary on the controller that could be pushed to remote machines, giving the spammer full access and control over the computer desktop.

Another reason might be self-preservation: Many malware researchers utilize virtual machines like VMware in order to do analysis of malicious software. Lately we’ve seen a trend of malware authors switching from detecting VMs in the client code to detecting them server-side. For instance, the Pushdo trojan sends the serial number of the computer’s hard drive back to the controller. VMware has a very recognizable serial number pattern, so it is trivial for the controller to be programmed to give different instructions to these bots. Other threats, like the Gimmiv worm, send the MAC address of the infected machine’s ethernet card to the controller. This also is a good way to differentiate between virtual and real machines.

So, it could be that the Ozdok spammer is trying to figure out what IP addresses might be attempting to join the botnet in order to spy on it, and is using screenshots to help make that determination. It would be a manual process, but it didn’t take us very long looking through the screenshots to pick out these four images, all showing advanced auto-analysis tools being used on the Ozdok sample as it connects to its control server:

Note to researchers: If you are doing automated analysis, there’s no reason to have a window displaying what you are doing. Hide your tools better, and try not to have your honeypot desktop look like a brand-new install of Windows!

Also, a note to the gentleman searching for images of nude preteen girls: You can run all the anti-spyware tools you can find, and employ the best anonymity tools in your web browser – it’s not going to help you if you get infected with an advanced trojan like Ozdok/Mega-D or one of the many others that allow hackers to take screenshots of your computer desktop. Don’t worry though, you probably won’t need a computer in the near term, as we’ve notified the authorities of your name and location (which you conveniently provided in a series of screenshots).

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.

But, unlike these past worms, Gimmiv turned out to have infected scarcely any networks at all. One reason for this is that the scanning done by Gimmiv looking for vulnerable hosts is limited to the local subnet, meaning it can only jump networks if an infected computer is moved from one network to another. Even if this were not the case, by default Windows XP SP2 (and above) restricts connections to the RPC ports to the local subnet only. So although future trojans and worms might utilize the same exploit, the window of opportunity for a globally impacting worm using this vector has passed for the most part.

Because of some mistakes made by the author(s) of Gimmiv, third parties were able to download the logfiles of the Gimmiv control server. Although most of the data in the logs is AES-encrypted, we were able to find the key hardcoded in the Gimmiv binary and decrypt the data.

Although it has been reported that Gimmiv is a credential-stealing trojan, this functionality is actually not used – the gathered data is never sent. What is sent is simply basic system information, such as the Windows version, IP and MAC address, Windows install date/time and the default system locale. Using this data we were able to track exactly how many computers had been infected prior to October 23rd (after this time infection counts are somewhat skewed due to malware researchers all over the world investigating Gimmiv). As it turns out, only around 200 computers were infected since the time Gimmiv was actively deployed on September 29, 2008.

By converting the decrypted log data into KML format, we were able to use Google Maps and Google Earth to take a look at the global impact and spread of Gimmiv. Only 23 countries had infected users, and Southeast Asia appeared to have the greatest number of infections:

Each computer on the maps above represents a Gimmiv-infected location – due to NAT, this may include dozens of computers. For example, two networks in Malaysia had the most infections:

While Malaysia was the hardest hit, it appears that the “in-the-wild” spread of Gimmiv may have started in Vietnam on September 29:

But, looking in the logs, we actually see that Gimmiv appeared first on August 20, 2008 – but we don’t count this as being in-the-wild. This is because logs were seen from only two IP addresses, only briefly. One of these IP addresses, located in Korea, we can tell was running Gimmiv in a VMware virtual machine – exactly the kind of thing you might expect someone testing a piece of malicious mobile code to do:

Additionally, a zip file left behind on one of the control servers contained Korean characters in the compressed folder name. For these two reasons, we believe Gimmiv’s author is probably from South Korea.

The KML file used to generate the maps above can be downloaded into Google Earth and is available here.

We all get phishing emails. Some of us more than others, so it’s no surprise that sometimes people take out their frustrations on the phishing form, letting the phisher know just what they think of him or her.

While it might make you feel better, it isn’t always a good idea. For instance, if you were to do this on a phishing page hosted by the Asprox botnet, you might get more than you bargained for. The Asprox phishing form backend has a bit of extra logic added to it. If the form looks like it has been filled out with legitimate data, you get redirected to the main page of the bank website.

However, fill it out incompletely or use certain words like “phish” or NSFWUYAS (Not Safe For Work Unless You’re a Sailor) language, and your browser will be subjected to a number of exploits. If you are running Windows and haven’t recently installed your security updates and patched all your browser plugins/ActiveX controls, you might find yourself infected with your very own copy of Asprox.

Not only do you then get the opportunity to unknowingly send phishing emails on behalf of the botnet, you will likely get some extra goodies, since Asprox is also a downloader trojan. You won’t notice it running, but you might notice some of the things it downloads and installs.

For instance, you might find your desktop wallpaper changed to a “spyware alert” type of message, and now all your screensaver shows is scary blue-screens-of-death. Of course, if you’re familiar with the Windows desktop properties dialog, you can change all that back, right?

Oops. the rogue antivirus program has removed that functionality for you. But hey, at least it gives you a chance to look over the license agreement, right?

Except you’ll notice the lack of a “I disagree” or even a “close window” button at the top of the dialog (which can’t be minimized, and stays on top of all your other windows). So there’s no easy way to continue using your computer without clicking on the “Agree and install” button. But don’t worry, Antivirus XP 08 has already installed itself, whether you click through the license agreement or not. Eventually you will see this:

Of course, you’re not infected with everything this program says you are – it’s scareware, designed to get you to fork over $50 or $100 in order to clean your system of all these nasty threats. But it doesn’t actually detect or clean anything, especially not the Asprox bot you’re hosting now.

And at any time, Asprox might deliver another malicious payload and install it for you – and it could be much worse: we’ve seen the Zbot banking trojan installed by Asprox in the past. So instead of a dealing with a nuisance program, you might be silently sending your banking and credit card information to the botnet owners. Something to think about before venting your frustrations on the bad guys. Sometimes phish bite back.

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.

One might assume that by now, that the antivirus company, employing the developer, would detect the specific version of Coreflood that he was infected with on February 23, 2007. Sadly, they still do not. The reason probably stems from the overarching problem that all antivirus companies face, and Coreflood is as good an example as any. There have been dozens upon dozens of Coreflood variants over the last six years. Virus and trojan authors these days are in it for the money, and more infections equals more money. And less detections equals more infections. So constantly rebuilding the Coreflood trojan to evade detection is part of the bad guys’ business model. And it’s easy – programs that scramble a trojan’s code to avoid anti-virus detection are available everywhere and most of them are free. The antivirus industry is really fighting a losing battle – they have to invest as much effort in reverse-engineering executable packers as the whole of the criminal underground spends in writing them, and this translates into a lot of time spent (and profits lost), since it always takes longer to reverse-engineer something than it did to engineer it. Therefore it’s not surprising that AV detection rates for new variants of most malware are simply abyssmal.

But while the packed Coreflood code might change weekly, it is interesting to note that the network traffic pattern that Coreflood uses when checking in with the controller has not changed substantially in the last two years! The intrusion (really extrusion) signatures we wrote for our clients back in 2006 are still effective at locating Coreflood infections today. It goes to show that fighting malware requires a multi-faceted approach: defenses against the infection vectors (exploits and social engineering), system-level protection, and extrusion detection to fill the gaps. Increasingly we are using our iSensor(™) intrusion prevention platform to do just this. Every day our malware research department analyses a large number of malware samples in order to improve our clients’ security posture and prevent information leakage by botnets like Coreflood.

Of course, we’re not alone in recognizing extrusion detection as a key part of defense-in-depth. For example, the Emerging Threats project maintains sets of extrusion-detection rules for the open-source Snort IDS platform. Since Snort operates in detection (instead of prevention) mode, using it won’t stop data leakage or malicious commands from being downloaded by infected systems, but it can at least alert network administrators of infected workstations so that they can respond, and hopefully re-evaluate their defenses based on the frequency and types of infections occuring on their network.

At its core, the determination of malware versus non-malware with 100% certainty can only be accomplished by knowing the intent of the author, something that can’t always be divined by scanning the bits and bytes of the code. Thus, no product can ever provide a 100% solution against past, present and future malware infection. However, extrusion detection and prevention continue to be invaluable tools in today’s world, where botnets lurk in the shadows and siphon data from every corner of the network.

If you saw the following browser window pop up on your desktop today for no apparent reason, you are: