PC Business And Marketing Reviews

Over the past few weeks, I’ve been putting together test hacking scenarios for a customer. They wanted to see copies of the RSA attack, the Google attack, advanced persistent risk (APT) simulations, social engineered Trojans, worms, remote buffer overflows, and more. The objective: to test what they could do to prevent all of those assaults on their predominately Microsoft Windows environment. Spyware removal at its best.

I place the customer’s environment through its paces, and as expected, it was splendid fun. It certainly beats filling out paperwork and reading security policies. But something unexpected happened along the way, although I shouldn’t have been surprised as I am a full-time principal security architect at Microsoft: I found that Windows 7 and other Microsoft programs were significantly harder to hack than most anyone would believe. It was hard to perform nearly any hack without disabling manifold default defenses and ignoring one or more additional warnings.

Now, many readers will paint me as a shill for Microsoft, but if you don’t believe me, try it yourself. Until then, please don’t waste my time and yours reading me the Riot Act diatribe. I’ve walked the walk, and the results were startling.

For example, simulating the RSA and Google attacks only worked if I was by software many years ancient; neither of them worked if I was by Microsoft software built in the past three to four years. In the RSA attack, employees were sent a spam email claiming to be a recruitment list. It proscribed an Excel spreadsheet with a link that opened a malicious zero-day Sparkle file (containing vulnerability CVE 20110609). The zero-day vulnerability could grant a hacker remote access, and the rest would be history.

First, as with the real attack on RSA, all spam emails were caught and placed in spam folders. Thus, employees had to first leap that small glide over, which they willingly did. When the Excel file was opened in nearly any version of Microsoft Office made in the past 10 years, the user was given a warning that the file contains a macro or script and, depending on the version, a link to an external file. The user was warned that the file may contain a malicious item. A user would have to ignore all of that to even give the malware a chance to launch. Microsoft Office 2010 opened the file in its new Protection Mode, which involuntarily disables the malicious code, by default.

In order to get the exploit to work, I had to disable most of the protections that Office gives, or I had to act — as is very reasonable — like an employee who ignores manifold warnings on purpose. In nearly every exploit, I had to disable User Account Control (UAC) and Data Execution Prevention (DEP) in Windows, Office, and Internet Explorer. Most of the exploits did not work with Internet Explorer 7 or 8.

Even when I disabled all the memory protections, application protections, and so on, warnings continued to pop up. I’ve always known that a fully patched Windows system was a tough opponent, but I’m here to tell you it’s much more resilient than it used to be.