I was talking breaches last week when a very high-up joined the conversation in mid-stream.
“Start over, Dave.”
“OK. I’m talking about breaches.”
“I know what you’re talking about,” he said, knowingly and very clearly interested.
The then-popular story about the attack on Anthem was that an administrator saw a query running as his credentials, but he hadn’t launched that query. The story I had heard was that this administrator gave up his credentials as part of a social engineering attack.
The director who asked me to start my story over was incensed with the idea that someone with administrator rights could be coaxed into giving up a password.
He’s right, things like that shouldn’t happen. But they do. Here’s the trick.
Security professionals call it “social engineering,” but that’s really just jargon for plain old-fashioned manipulation or con artistry.
I am anything but an accomplished social engineer, but here’s how I could go about getting logon credentials that I shouldn’t be able to get. (That’s besides the ones people give me without me asking. Someone e-mailed me a username and password last week. I about fell out of my chair.)
Assuming the attacker is having a bad day and nobody sent him any usernames and passwords without him asking, the first thing he would do is try to learn something about the company and its contractors. Maybe the company just signed a big contract with IBM or HP. What the attacker could then do is build a simple but official-looking web page that claims to be a bridge between the two companies.
Then, the attacker needs to find some targets. These days it’s not hard to harvest that kind of information from Linkedin. With a few names in hand, the attacker just needs to start sending e-mails, since most companies use a format like firstname.lastname@example.org, email@example.com or firstname.lastname@example.org. Spoofing a return address at ibm.com or hp.com or anywhere else is trivial.
All the content of the e-mail really needs to say is that you’re attempting a trial run, so could you please visit this web page and enter credentials for an account that has administrator rights.
That’s one possible scenario. Depending on an organization’s security training program, something that blatant may or may not work. But it’s likely to be a first try, since it’s relatively low-risk.
If that initial effort fails, the attacker will probably follow up by sending an Adobe Acrobat PDF to certain individuals inside the company, again, attached to something that looks official and credible. The document contains malware using an exploit in Acrobat Reader. The victim opens the attachment, Acrobat Reader opens, then Acrobat crashes and the attacker gains access to the victim’s computer.
What about antivirus software? It blocks attacks like this about 20% of the time. If you get tired of people like me hounding you to update Adobe Reader, this is why. Being a version behind on Reader is deadly–given a choice between deploying Adobe updates or Microsoft updates any given month, I’d place a higher degree of importance on the Adobe updates.
Once the attacker is on the network, it’s a matter of getting some tools in place. The attacker could install a keylogger in hopes of recording some administrator credentials. Another option is to use a tool like mimikatz to locate credentials stored in the system’s memory. Once the attacker has some administrative credentials, it’s just a matter of finding an interesting server–but if you’re sitting on an administrator’s workstation, you can probably find interesting servers just by watching what the administrator connects to. And at that point, the ballgame isn’t totally over, but the attacker definitely has an advantage.
And it can happen without the administrator/victim having any idea that anything out of the ordinary occurred.
So, maybe the administrator gave up those credentials freely. But it’s just as possible that he or she didn’t. We may not ever know that detail.