Credential Stealing as an Attack Vector

Traditional computer security concerns itself with vulnerabilities. We employ antivirus software to detect malware that exploits vulnerabilities. We have automatic patching systems to fix vulnerabilities. We debate whether the FBI should be permitted to introduce vulnerabilities in our software so it can get access to systems with a warrant. This is all important, but what's missing is a recognition that software vulnerabilities aren't the most common attack vector: credential stealing is.

The most common way hackers of all stripes, from criminals to hacktivists to foreign governments, break into networks is by stealing and using a valid credential. Basically, they steal passwords, set up man-in-the-middle attacks to piggy-back on legitimate logins, or engage in cleverer attacks to masquerade as authorized users. It's a more effective avenue of attack in many ways: it doesn't involve finding a zero-day or unpatched vulnerability, there's less chance of discovery, and it gives the attacker more flexibility in technique.

Rob Joyce, the head of the NSA's Tailored Access Operations (TAO) group -- basically the country's chief hacker -- gave a rare public talk at a conference in January. In essence, he said that zero-day vulnerabilities are overrated, and credential stealing is how he gets into networks: "A lot of people think that nation states are running their operations on zero days, but it's not that common. For big corporate networks, persistence and focus will get you in without a zero day; there are so many more vectors that are easier, less risky, and more productive."

This is true for us, and it's also true for those attacking us. It's how the Chinese hackers breached the Office of Personnel Management in 2015. The 2014 criminal attack against Target Corporation started when hackers stole the login credentials of the company's HVAC vendor. Iranian hackers stole US login credentials. And the hacktivist that broke into the cyber-arms manufacturer Hacking Team and published pretty much every proprietary document from that company used stolen credentials.

As Joyce said, stealing a valid credential and using it to access a network is easier, less risky, and ultimately more productive than using an existing vulnerability, even a zero-day.

Our notions of defense need to adapt to this change. First, organizations need to beef up their authentication systems. There are lots of tricks that help here: two-factor authentication, one-time passwords, physical tokens, smartphone-based authentication, and so on. None of these is foolproof, but they all make credential stealing harder.

Second, organizations need to invest in breach detection and -- most importantly -- incident response. Credential-stealing attacks tend to bypass traditional IT security software. But attacks are complex and multi-step. Being able to detect them in process, and to respond quickly and effectively enough to kick attackers out and restore security, is essential to resilient network security today.

Vulnerabilities are still critical. Fixing vulnerabilities is still vital for security, and introducing new vulnerabilities into existing systems is still a disaster. But strong authentication and robust incident response are also critical. And an organization that skimps on these will find itself unable to keep its networks secure.

This essay originally appeared on Xconomy.

EDITED TO ADD (5/23): Portuguese translation.

Posted on May 4, 2016 at 6:51 AM • 38 Comments

Comments

BruceMay 4, 2016 9:18 AM

"And the hacktivist that broke into the cyber-arms manufacturer Hacking Team and published pretty much every proprietary document from that company used stolen credentials."

From the English version of Phineas Fisher's document:

"A 0day in an embedded device seemed like the easiest option, and after two weeks of work reverse engineering, I got a remote root exploit. [...] I wrote a backdoored firmware, and compiled various post-exploitation tools
for the embedded device."

Clive RobinsonMay 4, 2016 9:42 AM

With regards,

As Joyce said, stealing a valid credential and using it to access a network is easier, less risky, and ultimately more productive than using an existing vulnerability, even a zero-day.

Or the "seed" of an RNG used in a token such as the RSA fob, or the master key of a key generator (used in some smart cards) or knowing how to break a weakly implemented crypto / authentication system that a user (subscriber) has know knowledge of or ability to change (DES badly implemented in SIMs and payment cards). Or how about creating PKI certs because various CA's to save cost did not protect the process so it could be easily hacked...

The attack surface is so large that even trying to manipulate humans via social engineering is to risky.

As always unless you are very knowledgeable and do it all yourself you are open to others foibles and thus their failings become yours...

And offten the root of all this is money, or more correctly short sighted cost cutting by those who realy do not care about security but next quaters profits...

GrowingUpInTechMay 4, 2016 10:04 AM

Lets be honest, computer nerds like me might have strong passwords, but I don't think society does, and when we do, what about password reuse.

We still have passwords like abc123 and asdfghj

Nick PMay 4, 2016 10:06 AM

@ Bruce Schneier

I'll add that this attack vector was a known issue going back to Orange and Red Books. The Orange Book required a trusted path for entering credentials that was immune to interception by apps or spoofing. They also required private data like credentials or encryption keys to be specifically labeled as such with OS checking any access against a subject's security level or something.

The CMW's with watered down assurance that were produced for more industry adoption still had these features. Over time, even these were dropped due to no demand outside a few sectors. Argus Pitbull and Trusted Extensions for Solaris 10 still serve such customers. One in Korea too.

Old, old requirement people ignored to their peril.

George HumphreyMay 4, 2016 10:09 AM

Stuxnet leveraged multiple zero days, and hundreds of millions of botnet zombies currently exfiltrating data all over the globe attest to the efficacy of flawed software.

This article comes across more like an attempt to move the spotlight away from companies and their secret collusion with spies (thank you Ed Snowden). It's not a bug, it's a [spy] feature. Did the Snowden documents not make this obvious?

And anyone who caters to the "good guy" narrative of the tech industry billionaires will be celebrated and showered with speaking engagements, awards, and news coverage.

UnkownMay 4, 2016 10:11 AM

nobody wondered what SAI messages over SS7 can be used for? Or AIR diameter for that matter. Then over the air interception implications hold suddenly also not only for 2G.

AverageSecGuyMay 4, 2016 10:29 AM

it's so embarrassing that most admins and even security guys still don't know how credentials are stored in microsoft environment, don't know SSO consequences, not aware to mimikatz and still focus on their job security and buying security products from the compliance check-list :-(

MiguelMay 4, 2016 10:45 AM


Email the most porous border. Social media channels gaining traction.

There is practically blind attacks, which can be pretty loud and compromise the malware and email.

And there are extremely studied attacks where they have a specific target of value in mind, maybe a handful, and have performed the research necessary to know how to get their trust. Where social media can be the mined field. :-)


There are other commonalities to these attacks, however. One is if they do use custom malware/"zero day malware"/"previously unseen malware". There are a wide number of systems today designed to detect that with very high detection rates.

A number of these are systems that are good at that, and good at detecting non-malware usage intrusions.

There are very strong micro/segmentation systems at play, today, as well.


So, I do believe heuristic like systems are at play for these attacks. The same sort of systems that tend to be good at protecting against zero day.


But, zero day guard should not be down. It does depend on the target. Zero day can do a lot of things you can never do with phishing and social engineering alone.

We should not forget some of those catastrophes from the past three decades.


Watering hole/drive by zero day really diminishes the overhead for research on targets. If properly handled, extremely low risk for discovery. And they can get anyone they want if they have it in a major system.

Instead of clicking on "yes, run this despite that it could compromise my entire company's network", they just receive an email, sms, phone call that never even rings.

They walk by the wrong place with bluetooth or wifi turned on.

They have joined the wrong online social group.


Software vendors have to improve their products against zero day in their products. Very many companies, of course, have at the least, their own written web applications. Nobody wants to end up like what happened with chipotle. Headline news. Your flagship application was used to hack millions of systems in a devastating...


Some critical networks require zero day for thorough penetration.


paulMay 4, 2016 11:08 AM

Does it matter for this discussion which credentials are actively stolen (e.g. intercepting a connection or getting someone to enter the credential in the wrong place or installing a keylogger or finding a password file) versus those that are discovered by brute force? Some of the attack surfaces may be different, but they're all a problem.

Also, what does this say about finer-grained access controls? Could some privilege-escalation steps be slowed down by keeping better track of what people (especially outside vendors or lusers of some kind) are doing?

Green SquirrelMay 4, 2016 1:10 PM

I am a bit meh about this.

Yes, credential stealing is the easy way in but it is rarely the only part of an attack. As mentioned above the fantastic write up of the Hacking Team breach showed that the 0day was used to get access so mimikatz could do its magic.

With lots of breaches, having a set of credentials can assist the attacker but they need to both be able to get the credentials (malware? phishing?) and then once in, the merciless pivoting has to take place.

When it comes to big ticket breaches, there is often an 0day somewhere in the attack path/kill chain (or whatever phrase du jour you like). As others have mentioned - stuxnet was a bit bathtub of 0days, target (once the attack was underway) needed 0days and so on.

Added to which, companies are absolutely rubbish at patching. I visited a client site last week where Bruce's new employers manage services and they have pushed the client to a contract saying patches will be applied within 180 days of release with a 95% SLA target. This means most 0days are 0days for months and months and months and months............

MiguelMay 4, 2016 1:52 PM

@George Humphrey

I agree there is likely deception in the statement.


This article comes across more like an attempt to move the spotlight away from


I doubt they have compromised major foreign governmental networks simply from phishing.

The likely motive here, and he wouldn't feel so much like he is lying. Because most people listening to him, what he stated would apply. Even if he knows in the most valuable cases, the game is entirely changed.

zMay 4, 2016 1:55 PM

The worst part is that most of the time login credentials aren't even necessary. The "Create an account" culture has got to stop. Forcing people to create accounts just to buy $9 worth of stuff one time is just begging for an exploit that steals those credentials. People have to create so many accounts these days that they A.) inevitably pick crappy passwords since they have to enter them constantly, and B.) use the same ones everywhere. Thus, even if the account contents themselves don't give an attacker anything interesting, the password itself is worth the effort to steal.

This might be kinda sorta okay if passwords were stored properly, but we still can't get that right even after 20 years of people banging the table in opposition to unsalted MD5 as a password hashing scheme. We still can't secure databases either. We're forcing people to create accounts, encouraging them to pick the worst password they can think of, encouraging them to use it everywhere, and then botching the storage of it. What could go wrong?

The most hilarious thing about it is that customers hate creating accounts. They really really hate them. Making people create an account is famously a $300 million dollar mistake: https://www.fastcompany.com/1147825/300-million-continue-button

Jesse ThompsonMay 4, 2016 3:54 PM

I have to side with Green Squirrel on this one.

It's easy to say that use of stolen credentials and stolen login channels are the primary way to safely hack something (and in turn to clarify that detecting these specific shenanigans are the low point in most people's security profiles which need to be raised) but IT IS NOT kosher to claim that this should be THE PRIMARY security concern.

Why? Because nobody can use a stolen credential or abuse a login channel without first employing some kind of vulnerability to initially get their hands on the credential!

So, somebody uses my password to log into an asset somewhere. Question: where did they get my password? Somebody hijacks my login channel. Question: how did they gain access to my login channel in order to hijack it?

It's fine if you want to claim that credentials are secrets and secrets simply can't be kept forever anyway, or that the attack surface is so large and the credential such a small and valuable target to use for escalation that how they get it begins to lose relevance (be it software exploit or social engineering or spearphishing or brute forcing the weakest link, etc), but I am saying that this is a fight you literally cannot give up without ultimately rendering the credential obsolete from the get go.

If it really doesn't matter how the credential gets stolen, then that immediately means that the credential cannot be made secure, which in turn means that the login system becomes utterly inappropriate. You want to try to strengthen it with an added factor? I'm sorry, but the first factor stopped mattering.

For example: want to use a smartphone for 2 factor? Smartphones are much easier to hack than any moderately carefully used PC. I've got this problem with Steam right now: they expect me to use their mobile app for 2 factor login, use my mobile app to confirm every time I take a piss to prevent somehow getting my valuable TF2 hats stoled: but all of the *first* factor issues can be initiated from the phone as well. So? All somebody has to do is hack my phone and they can pilfer all of my shit, and that's easier to hack than my PC. So what am I squinting and poking at this tiny 6" touchscreen for again?!

Want to use a dedicated hardware fob for 2 factor? Great: you get to trust that neither the NSA nor your firmware designer nor your Chinese hardware manufacturer didn't backstab the RNG in a way that tomorrows thieves don't figure out how to exploit, and you get to trust that your X509 chain to receive firmware updates never gets janked.

Not to mention carrying around a janitor's keychain of fobs to get anything done, and good luck getting dedicated keyfobs to access resources secured by any company worth less than a $Billion.

What I'm getting at is that perhaps a better way to approach this, especially for the public or for employees at a mid-sized or above company, would be: today, Lastpass.. tomorrow, hopefully some open-source alternative that offers the same services as Lastpass via completely open sourced software but you get to either run the vault server or else your client software just abuses dropbox or something to get that job securely done.

And if your main concern is preferring time-sensitive or use-sensitive credentials (like the second factor in yubi-key or Google Auth) over the replayable nature of passwords, then Lastpass or it's successor could conceivably handle that right on your PC instead of requiring a second, cumbersome device to get that job done, too.

Both passwords and one-time-use credentials can be automatically input via browser extension so that not even keyboard or clipboard monitoring malware could eavesdrop, from a vault which is stored encrypted on disk and only decrypted in RAM so that disk-stealing malware are at a disadvantage.. not that I'd recommend trying to use any of your credentials on a compromised machine, but again just so that a single, thin layer of undetected compromise still isn't enough to easily penetrate your single-pc auth scheme.

To address "z"'s concern about poor server-side hashing, this method also encourages non-reused passwords (so that a compromise of one account with un-hashed passwords doesn't leak to other accounts you hold at other places of business) with high entropy (so that even accounts with unsalted, unstretched, MD5 or worse hashing still have to be brute forced for ages upon ages to be cracked, which even then only gains them access to the one account). So, it's nice not to fret too much how secure "every password database you ever interact with" is.

NateMay 4, 2016 4:53 PM

The potential for silent, bulk credential stealing is what worries me most about compute clouds.

It seems to me that it would be pretty trivial for a large cloud compute company hosting millions of Windows or Linux images to quietly add some traps to the hypervisor to dump known contents of RAM that contain system login credentials and certificates, and quietly save this information on the backplane of the cloud infrastructure to a database for later use.

This information would be relatively low-volume and easy to copy and store.

It would also be of EXTREMELY high value for the sorts of agencies whose mission is to 'get root login access to every system in the world'.

This information, being stored in RAM, bypasses every kind of encryption. It's not 'data in transit' or 'data at rest'. It's 'data in the VM RAM' and we currently have no viable encryption model for this.

And the extraction of this information would be utterly silent and invisible to both the VM user, and to most employees of the cloud company itself, since they usually implement very strict internal security protocols that don't allow employees to view or audit the hypervisor code. It could be automated and done routinely in bulk, 'just in case we ever need a back door'.

The major cloud compute firms do in fact have working relationships with the intelligence agencies. Amazon, for instance, runs classified clouds for the CIA. I'd be surprise if IBM and Microsoft don't also also have defense customers for their clouds.

ISIS is probably using cheap throwaway cloud servers for some of their activity, so there must surely be some kind of internal corporate mechanism at all of these companies for 'this server is doing suspected terrorist/illegal activity, gain access to it - and the credentials of its users - by any means necessary'. There would in fact be huge governmental pressure to provide such means of access from all the agencies from FBI on up to CSA/NSA.

We also know that although hypervisors are often open source projects (to which the NSA among others contribute, so know the systems intimately), the cloud companies don't use stock hypervisors, but modify them in unknown ways. They don't release their hypervisor source code for audit, in fact they keep it as a secret crown jewel of their enterprise. They often require security clearances for hypervisor engineers.

So there's motive, method, opportunity, premade test cases, a vast payoff if successful, governmental incentive to do this and in fact pressure at the National Security Letter level to keep such a mechanism hidden, and a very low chance of being observed doing it. The only way we'd ever find out would be if a hypervisor engineer leaked exactly what their _running_ hypervisor code did.

The logical response from a cloud company would be to implement such a backdoor mechanism and do it in such a way that it was silent, and could either be switched on and off for individual servers, or just done in bulk.

If done in bulk, there would also be management elements of these companies who realise that they are occasionally competing directly with their customers, and it would be _very_ commercially useful if they could sometimes read what a potential competitor was doing. That would of course be violating at least the spirit of their customer contract (but perhaps not even its letter - some cloud contracts state that the company can read your data if it might cause economic loss for them... )

I'm wondering when the shoe will drop and people will notice that we've built the ultimate panopticon here. Cloud hypervisor sees everything, including your passwords and private keys in cleartext. Therefore, your passwords and keys on all your clod nodes are _gone_. Burned. That's it. Game over.

But for some reason nobody sees this as a problem?

albertMay 4, 2016 7:03 PM

@z,

Indeed. Every company/organization act like theirs is the only web page you'll ever use. Certainly, one would expect some security for online purchases, and draconian security for banking, but I have to sign up to see things for free, or participate in discussions and forums. Particularly irksome are product support sites/pages. All are guilty, include FOSS companies.

On my list of things that need to go: Flash, Java, and websites with a plethora of scripts. My bank uses nothing, nada, zip, it's a professional looking site that's fast and easy to navigate.

. .. . .. --- ....

Nick PMay 4, 2016 7:14 PM

@ GreenSquirrel

You're vastly oversimplifying it. Remember what DSD said for Australia as it applies everywhere: whitelisting and fast patching countered 75% of so-called APT's. The whitelisting is especially helpful in stopping employees from being conned into running malicious executables. That's 75% of all hacks that were going on had nothing to do with 0-days. Matter of fact, quality can be so bad that one could in theory use a 3,207 day attack on LDAP if submitter was correct. ;) Add misconfiguration, esp default credentials, to that along with stuff running in network that's not documented. Especially add web attacks as many high-profile attacks start with hitting insecure, web apps connected to sensitive stuff. And then there's 0-days.

So, I think the TAO head was right in saying 0-days importance is overstated. I mean, we should also make the distinction of *where* the 0-days are. In web, specific types of problems are so common we often think of them differently from 0-days even though they technically are. Whereas, a 0-day in Linux is harder to both find and use. A 0-day in Windows kernel is increasingly rare given all the QA they did due to other thousand 0-days. So, we should differentiate but still many other attacks exist.

egoMay 4, 2016 7:44 PM

Millions of email accounts compromised in massive data breach that includes Google and Yahoo
http://www.telegraph.co.uk/news/2016/05/04/millions-of-email-accounts-compromised--in-massive-data-breach-t/

Millions of users of the Google, Yahoo, and Microsoft email platforms have also had their data stored in one of the largest databases of stolen credentials ever discovered, Mr Holden told Reuters.

Hold Security, his firm, found the trove of stolen data after a teenage Russian hacker boasted in an online forum that he had access to millions of stolen credentials.

медведьMay 4, 2016 8:06 PM

@Jeroen
"Kevin Mitnick"..?

Who is Kevin Mitnick? oh wait some guy who was temporarily famous over a decade ago.

Nick PMay 4, 2016 8:41 PM

re Mitnick

He conned people out of credentials repeatedly to gain access to systems. That's the significance. The Art of Deception was a fun read, too, with nice examples for real-world attacks on the weakest link.

DroneMay 5, 2016 3:21 AM

So... The NSA's Chief Hacker publicly says that the easiest way in is credential theft. Considering the source, you now know the exact opposite is true.

tyrMay 5, 2016 3:40 AM


@Nick P.

My favourite Mitnick moment was when Woz gave him
a shiny new Apple top product as a getting out of
jail present. It was like seeing Billy the Kid grinning
after recieving a Tommy Gun for his birthday.

I imagined the Feds cringing since they never caught
him, he was turned in by an associate. He's a pretty
good hacker with a great social engineering skillset.

DavidMay 5, 2016 3:55 AM

Reading the comments it's clear that the debate between 'sexy infiltration' and 'non-sexy infiltration' is as prevalent as ever. Seems to me that as long as the human remains the weakest link in the chain (and that's not going to change any time soon) obtaining credentials through social engineering will be the easiest way to get into any system. It has the advantage that you know the credentials are valid, you can target credentials that get you into the parts of the system you want, and by definition, no detection system looking for unauthorised access is going to be triggered by a valid user. Plus of course, all the encryption in the world is no defence if the 'person' accessing the data is allowed to read it.
Of course you have to patch and detect, but until we go back to basics and educate and support the users we've lost at least half of the battle.

Democratic Front for the Reunification of the FatherlandMay 5, 2016 6:50 AM

This is equally true on a macro societal scale. The secret police don't just steal passwords and certs from your boxes. They also steal the credentials for legitimate government authority: your elections.

http://www.madcowprod.com/2016/04/28/the-rigged-democratic-primary-in-new-york/

http://www.madcowprod.com/2016/04/28/election-company-in-ny-primary-has-arm-long-rap-sheet/

Just look at the crooked mobbed-up cesspool that is your electoral process. The system is shot through with technical and procedural overrides installed by organized crime, beltway bandits, NOCs - all the traditional CIA cutouts. Your democracy is fake.

ianfMay 5, 2016 7:03 AM


@ tyr's fave moment when Woz gave Mitnick a shiny new Apple top product as a getting out of jail present.

One of us misremembers things, could be me. As I recall—it's been a while, and, anyway, I might have conflated things—part of KM's conditions for release from prison was him keeping away from computers for some additional years. So what was it that Woz could have given him… a LaserWriter?

Nah, couldn't have been that either, as for a time around then-Mitnick fame, it was the most powerful and memory-laden Apple product. In fact, I used to astound onlookers at trade fairs by hooking up a VT100 terminal to an LW's parallel port, interactively type in a string of Postcript instructions to its onboard interpreter concluded by the 'showpage' command, and have it spit out a page with e.g. black square followed by an onlooker's first name █… Cheap Thrills City.

Nick PMay 5, 2016 9:40 AM

@ tyr

Oh yeah, that must have irritated the hell out of the Feds. Didn't know about Woz giving him a welcome back present. That's pretty cool. Aside from his book, only thing I saw on him was a show he did with TechTV's Leo Laporte right after release. He seemed like a fun guy to be around. I think he was on probation from computers for some time but directed others to do hacking for security consultations. Haha.

Clive RobinsonMay 5, 2016 10:49 AM

@ ianf,

I used to astound onlookers at trade fairs by hooking up a VT100 terminal to an LW's parallel port, interactively type in a string of Postcript instructions to its onboard interpreter...

You may be getting a bit confused here or not saying things correctly.

Postscript is a "Forth like" stack based language, early post script printers had bidirectional serial interfaces such that error messages could be sent back to the print control program. The problem with parallel interfaces is that data wise they are one way. So later printers had both a parallel interface for speed and a bidirectiona serial interface for error messages and the like.

The VT100 range of terminals were serial in nature and some (DEC) had a local printer port as well. From what I remember of the DEC printer ports they were serial as v
Well, and you had to fit a loopback interface onto the bidirectional serial line interface to be able to type reliably to the printer interface.

It is something like a third of a century since I messed around with Postscript (certainly it was before it became Level 1 when Level 2 came out in the early 90's) what I was trying to do was upgrade a "Cambridge Ring" box I had designed to talk to the IEEE instrument interface so that it could dump vector graph plots to the postscript printer without having to clog the network up. A few people showed interest but not enough so it died when I went to find better paid work outside of the academic environment.

JeroenMay 5, 2016 2:38 PM

Currently reading Ghost in the Wires. Can highly recommend the book, but I did not read The Art Of books so I cannot compare.

From what I gathered, Mitnick received the Powerbook G4 from Woz 3 years after he got out of jail (2003 and 2000 respectively) when "his ban from electronic devices" ended.

And yeah, its rather relevant in discussions like these. He never caused financial harm, but he was good at phreaking and especially social engineering. He used phreaking and social engineering to obtain the source code of SunOS, NetWare, VMS, and firmware for cellphones so he could modify them. He also used those techniques to stay ahead of the Feds.

ianfMay 5, 2016 3:15 PM


You're quite right, Clive, I mixed things up. It was a serial interface, a DB9 plug the way I remember it, which I somehow confused with the (more common in printers) Centronics interface. I learned that direct PS input technique at a MacWorld conference in SF 1987?, though it may have been access to a built-in test/demo routine, rather than to the rendering engine.

albertMay 5, 2016 3:58 PM

@Clive,

"...better paid work outside of the academic environment..."

The Devil you say!

College administrators are vastly overpaid. Six figures (seven for CEOs) in big schools, and just like their Corporate Counterparts, they are adopting the CCs greed as well.

. .. . .. --- ....

Nick PMay 5, 2016 4:21 PM

@ Jeroen

Wait a sec. I knew he conned his way into VMS systems. But he actually obtained its source code, too? And published that code... where? ;)

JeroenMay 6, 2016 5:42 AM

Still reading the book (Ghost In The Wires) which describes Mitnick's life story as a phreaker/social engineer(/hacker).

AFAICT he never published the source code of any of the software. He did it for the kick (and occasionally to find and write exploits), and moved on. VMS was also his favourite OS, btw.

Small snippets of info correlating with what I read in the book are also found here:

https://slashdot.org/story/03/02/04/2233250/kevin-mitnick-answers

JG4May 6, 2016 7:29 AM


seems like someone needs to point out the RSA hack via credential stealing

http://bits.blogs.nytimes.com/2011/04/02/the-rsa-hack-how-they-did-it/
...
In the attack on RSA, the attacker sent “phishing” e-mails with the subject line “2011 Recruitment Plan” to two small groups of employees over the course of two days. Unfortunately, one was interested enough to retrieve one of these messages from his or her junk mail and open the attached Excel file. The spreadsheet contained malware that used a previously unknown, or “zero-day,” flaw in Adobe’s Flash software to install a backdoor. RSA said that Adobe had since released a patch to fix that hole.
After installing a stealthy tool that allowed the hacker to control the machine from afar, he stole several account passwords belonging to the employee and used them to gain entry into other systems, where he could gain access to other employees with access to sensitive data, Mr. Rivner said.
Then came stage three: spiriting RSA files out of the company to a hacked machine at a hosting provider, and then on to the hacker himself.

that was just the warmup to grab the crown jewels

http://www.darkreading.com/risk-management/lockheed-martin-suffers-massive-cyberattack/d/d-id/1098013

when your country staggers from one multi-trillion dollar error to another, it is just a matter of time before it is in dire straits

Clive RobinsonMay 6, 2016 11:36 AM

@ JG4,

Seems like someone needs to point out the RSA hack via credential stealing.

I remember it well, but it is just one of many "seed" stealing attacks that I briefly mentioned above.

The thing is that it would be simple to raise an alert to warn against misuse. If the tokens had a button on them which displayed a second say four digit number that was a check sum of the number of times the token had been used, and the computer asked you to type it in as a second check any difference could be used to warn the user or send a message to the security admin etc.

But the second button and a cover would cost maybe 20cents a token... Oh then you don't want to wake the security admin up either, they might have to actually speak to users and look into things...

albertMay 6, 2016 1:59 PM

@Clive,
Errata re: big university CEO salaries: 7 to 8 figures in USD. No one has broken the $100M barrier yet, AFAIK.
. .. . .. --- ....

AndrewCMay 8, 2016 11:44 PM

@NickP

"But he actually obtained its source code, too?"

It was distributed on microfiche and every systems programmer had a fiche reader. I can't remember whether you had to license it specifically but getting access was no big deal. A few bits were left out but it was pretty much all there back in the day.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.