By the end of 2021, we are all pretty familiar with the script when it comes to ransomware attacks.
These types of attacks have been running rampant during the era of remote work, taking advantage of the confusion to do their dirty deeds.
In this story, I will talk about foreign groups extorting their victims in ransomware attacks from the safety of foreign territory. Think Russia and other spots without extradition treaties with the US or other countries that top the targeting list.
Not Everything is as it Seems
In December 2020, technology company Ubiquiti found itself the victim of a ransomware attack. According to the reports, gigabytes of proprietary data from their AWS and GitHub had apparently been stolen and the thief was demanding 50 Bitcoins (roughly $2 million) for its safe return. The icing on the cake was that the thief would tell the victim where the other backdoors were located.
To their credit, the company refused to pay the extortion. Instead, they called the Feds who investigated and in short order tracked down a suspect in the case. In their sights was Nickolas Sharp, a software engineer on the company’s cloud team whose credentials had been used in the attack.
Ironically, as a member of the team that had been impacted by the hack, Sharp was added to the incident response group. Not knowing that he was behind the extortion, the company had accidentally given him a chance to hide his tracks. He allegedly even changed the logs from the attack to erase evidence of his involvement.
As the investigators began to close in on the alleged hacker, Sharp attempted to push harder against his employer in what we can only assume was an attempt to cause damage.
Whereas most folks in a hole would stop digging, Sharp decided to reach out with an anonymous tip to famed cybersecurity writer Brian Krebs to tell them about the breach. Posing as a whistleblower, he told Krebs that the situation was catastrophic and the story spread widely.
A publicly-traded company, the false stories caused Ubiquiti to lose 20% off their stock price. This translated into a $4 billion market cap loss. Not a good day.
Despite his best efforts, Sharp was arrested just a few months after the attack. Apparently, his VPN that he used for the attack not only dropped service long enough to identify his IP, but he also paid for it with his PayPal account. A not-so-perfect mix of intelligence, luck, and stupidity that brought it all crashing down hard.
Sharp was officially charged in November and may find himself spending the next 37 years in confinement, banging his head on the wall for everything that he did wrong.
Managing Risks from Insider Threats
For security teams thinking about how to prevent this kind of incident where a trusted member of your organization decides to abuse their privileges for malfeasance, this story should serve as a warning.
Privilege Abuse is the leading cause of breaches according to the Verizon Data Breach Report for 2021. This makes sense since a person who already has the keys in the form of their credentials can access the target data without encountering any of the obstacles that an external attacker would since they have the rights to access it.
Most of us don’t abuse our access because we’re either aware that we shouldn’t steal, or at least that we know that it’s not that hard to tie a hack with your credentials back to you.
This was a difficult case because not only was our baddie a highly privileged user with rights to multiple systems — their AWS and GitHub accounts at a minimum — but he was part of the security team brought in to investigate the breach. I don’t envy Ubiquiti’s security team in the slightest.
Nobody ever wants to discover that the attacker is someone within the organization, but it should be a possibility in their minds. Given this risk — especially considering that legitimate employee creds were used in this data loss incident — we need to think about how to reduce this risk and respond to it when it does occur.
3 Tips for Stopping and Responding to the Insider Attack:
- Bring in an Outside Incident Response Team With hindsight being 20/20, we can say that the company should maybe not have put someone with pre-existing access to the compromised systems onto the investigative team. It’s like asking a small child to investigate who knocked over the blocks or ate all of the pretzels.
But this would not be fair to Ubiquiti. Most organizations would probably call in members of their team to help in the investigation because they are likely to be intimately familiar with the impacted systems.
The right course of action would likely be to call an incident response team to take lead on this and report directly to leadership. Without knowing all the details in this case, we shouldn’t make assumptions about whether or not Ubiquiti engaged with an external IR service provider or not from the start.
By the looks of how the case got wrapped up pretty quickly, it is evident that they brought in some pretty competent folks to work alongside law enforcement and finger Sharp for the crime.
2. Get the Whole Story with User and Entity Behavior Analytics Alongside Logging
When it comes to understanding why your workload crashed and burned, logging is essential. However, it only tells a portion of the story. Logging on its own is not a security tool and should not be regarded as such.
If you are relying on your own internal logging system, then you risk having your valuable records being abused. Anything that can be internally controlled can be changed.
Instead, make sure to have an externally managed platform with User and Entity Behavior Analytics (UEBA) capabilities to keep track of who is doing what and when.
Despite reading through the available materials on this case, there’s no good explanation why Sharp used his own credentials for the hack. Even Wikileaks-infamous Edward Snowden had the good sense to trick his colleagues into letting him use their creds for doing his dirt.
3. Detect and Prevent Data Exfiltration with Data Loss Prevention Tools
Even for a person using legitimate credentials to log into Ubiquiti’s accounts, there’s no good reason why that person should be allowed to download gigabytes of proprietary data without some kind of red flags popping up.
By the looks of it in this case, Sharp seems to have spread his data downloads out over time so as not to attract unwanted attention. That was smart not to do it all in one smash and grab kind of attack. Most anyone who has to comply with GDPR, HIPAA, PCI DSS, or ISO 27001 needs to have some kind of solution in place for monitoring data security. So chances are that they had something in their environment, but it was easy enough for Sharp to get around.
However, the security team should have had a data loss prevention tool in place that would have noticed that one person was downloading some pretty important stuff at a rate that probably didn’t make sense.
And even if there was cause for someone in Sharp’s role to be doing many of these downloads, there would have been no harm by having someone on the security team receive an alert that these downloads were happening.
You know, just in case it became an issue later.
Strange Case, Good Lessons
In the months to come as Sharp heads off to trial, we may end up getting some answers to this weird case.
Why did he use his own credentials for the attack or make any of the million other mistakes? He was apparently smart enough to cover up the logs but couldn’t have some common sense about not tying himself directly to the crime?
What is for sure is that this story highlights the challenges of managing privileged employees, emphasizing the point that they need to be identified and monitored closely.
Hopefully, this case will serve as a warning for potential criminals that you’re never as smart as you think you are.