The company knew it had been breached.
The incident response was underway.
But the IR team was trying to figure something out: how did a hacker access the organization's AWS cloud to exfiltrate data and then proceed to copy more than 150 repositories from its GitHub account?
According to court records unsealed this week, one of the people on the Incident Response team could have answered that question because he was "the hacker" who did it.
And get this: while he was responding to the incident with his colleagues, he was attempting to extort his company for millions of dollars.
Are we going too far with our headline that calls this the ultimate IT betrayal? Read about this insider threat case and let us know what you think in the comments below.
Insider threat suspect: the software engineer and cloud lead
Nickolas Sharp was a software engineer and cloud lead at an American technology company called Ubiquiti.
According to the federal indictment against him, his responsibilities in his role included software development and cloud infrastructure security. And in this role, he had admin level access.
This included access to the company's AWS infrastructure, including servers that ran a portion of company operations and hosted certain systems, code, and credentials.
And Sharp also had the highest level rights to the corporate GitHub account, "which provided access to all or nearly all of Company-1's repositories on GitHub," according to court documents.
Insider threat case: middle of the night data downloads
Prosecutors say the insider threat scheme started unfolding on December 10, 2020. Sharp allegedly used his company-issued credentials to access a specific key in the company's AWS infrastructure. This happened at 2:55 a.m. and again at 3:16 a.m.
From the indictment:
"The Key accessed by SHARP permitted the user to, among other things, obtain access to other credentials within [company] infrastructure and to run searches through that infrastructure."
Shortly after that, a mysterious "hacker" appeared in the company's cloud account:
"Approximately two minutes later, on December 10, 2020, at approximately 3:18 a.m. an attacker connected to Company-1's AWS infrastructure using a masked IP provided by the Surfshark VPN.
The attacker used the same Key accessed by NICKOLAS SHARP, the defendant, two minutes earlier to connect to AWS and to run a command 'getcalleridentity.'
That command returns the username and account information for the AWS account for which it is run and can validate that the credential is usable."
This type of timing became a pattern in the scheme. The software engineer would use his legitimate credentials to access something, and then a VPN cloaked "hacker" accessed the same data just minutes later.
On December 21, 2020, prosecutors say Sharp logged into the corporate GitHub account at 9:58 p.m. And then, this happened:
"Approximately one minute later, on December 21, 2020, at approximately 9:59 p.m., NICKOLAS SHARP, the defendant, used the Surfshark VPN that masked his true IP address to connect into GitHub through SSH by using Company-1's high-level GitHub Account-1.2 SHARP used the SSH connection to execute a series of commands to clone Company-1's repositories of data to SHARP's computer."
This was the beginning of what you might call a downloading frenzy that lasted until the morning commute in Portland, Oregon, where the software engineer lives.
"Over the next several hours, on December 22, 2020, between approximately 3:04 to 5:31 a.m., NICKOLAS SHARP, the defendant, cloned approximately 155 repositories from [the company]
through GitHub Account-l, using the Surfshark VPN to once again mask his IP address."
More than 150 repositories of proprietary data, now in the hands of a rogue employee. Why would anyone do such a thing?
Insider threat case: employee tries to extort his own employer
The ransom note arrived at 4:01 a.m. It told a Ubiquiti employee about the hacker's demands. He wanted Bitcoin. He sent the note via email and also a messaging platform called Keybase. That message went to a senior member of the cybersecurity team.
Investigators say the "hacker" was actually Nickolas Sharp, who at that point was helping with the company's incident response:
"While working on a team remediating the effects of the Incident, SHARP sent a ransom note to [the company] posing as an anonymous attacker who claimed to have obtained unauthorized access to Company-1's computer networks.
The ransom note sought 50 Bitcoin, a cryptocurrency, which is the equivalent of approximately $1.9 million based on the prevailing exchange rate at the time, in exchange for the return of the stolen data and the identification of an existing 'backdoor,' or vulnerability to Company-1's computer systems."
The company refused to pay. At that point, the software engineer is accused of playing hardball.
"Three minutes before the ransom deadline was to expire, NICKOLAS SHARP, the defendant, sent an employee of Company-1 a message on Keybase, as the anonymous perpetrator of the Incident.
The message read 'No BTC. No talk. We done here.'
The message contained a link to a public Keybase folder on which the perpetrator had uploaded certain of Company-1's stolen proprietary data for public access."
The indictment says that when Sharp was questioned about possible involvement, he posed as a type of whistleblower. He anonymously told certain media he was involved in the remediation efforts and was sure the company, "...had been hacked by an unidentified perpetrator who had maliciously acquired root access" into the company's AWS accounts.
But the ruse was almost over. The extortion attempt failed. The redirecting of attention failed. And the FBI had the evidence it needed to reveal Ubiquiti Cloud Lead Nickolas Sharp as being a malicious insider threat.
IT insider threat case: covering tracks, getting caught
After reading through the 19-page indictment in this case, some words popped into my head. At a SecureWorld cybersecurity conference a couple of years ago, I interviewed top IT security researcher Larry Ponemon about the insider threat. His words apply in this case:
"The insider that is smart has the skills to hide the crime, for months, for years, sometimes forever."
And according to the court documents, Sharp nearly did that, using the following skills and strategies in an attempt to cover his tracks.
- "Sharp applied one-day lifecycle retention policies to certain logs on AWS, which would have the effect of deleting certain evidence of the intruder's activity within one day."
- He wiped and reset the laptop he used to download the corporate data.
- He used a VPN to conceal his IP address.
If these things are true, then how did the software engineer and cloud lead get caught?
For that part of the story, we must go back to the middle of the night data downloading frenzy. Something went wrong that has Sharp facing up to 37 years in prison: his internet needed a reboot.
"On December 22, 2020, at approximately 2:16 a.m., the attacker's exfiltration commands stopped. At around the same time, the internet service at the Sharp Residence went down.
At approximately 2:54 a.m., the Internet service at the Sharp Residence was reenabled, and approximately one minute later, the Sharp IP was logged, unmasked by any VPN, using GitHub Account-1 to continue sending clone commands."
In an instant, the steps Nickolas Sharp used to hide his digital tracks came crashing down.
Since then, the FBI has matched the data exfiltration times with activity from Sharp's IP address. And investigators discovered he'd used his own PayPal account to buy the VPN access used in the attack, and more.
FBI Assistant Director Michael Driscoll says it appears Sharp's motivation was money:
"We allege Mr. Sharp created a twisted plot to extort the company he worked for by using its technology and data against it. When confronted, he then lied to FBI agents.
Mr. Sharp may have believed he was smart enough to pull off his plan, but a simple technical glitch ended his dreams of striking it rich."
This leads us back to the question: would you feel like it was the ultimate IT betrayal if one of your colleagues was a malicious insider threat?
And do you think most companies are able to detect these kinds of threats?
Let us know in the comments, and they will appear after approval.
Listen to a recent SecureWorld Podcast episode that explores various angles of the accidental and the malicious insider. This includes how your executives can become accidental insider threats.