Ubiquiti’s Insider Attack is a Textbook Case for Stronger Authorization Security Management

16/12/2021 • Gabriel Avner

Stories about hacking usually involve some shady characters and a bit of skullduggery. In most cases, it’s just criminal or state actors being up to no good business. 

But then some yarns end up being truly twisted. This is one of those stories.

Authorities in the US announced early this month that they had arrested an Oregon man named Nickolas Sharp on charges of hacking and extortion among others. Sharp had been employed by Ubiquiti Networks as a developer in their cloud division when he carried out his dastardly doings in December 2020.

According to the excellent reporting by Catalin Cimpanu, he used his credentials to log into the company’s AWS and GitHub accounts, stealing gigabytes of their data while he was still employed at the company. Then, seeking his payday, Sharp allegedly sought nearly $2M in Bitcoin from his employer for the ill-gotten data and the promise of revealing his other backdoors that he used for his thefts. 

Up to this point, this all fits into a pretty classic insider attack where a privileged user with access to multiple cloud services abuses their entitlements to steal/damage the org’s resources.

Where it gets weird is when Sharp is brought in by the company as part of the incident response team and was able to manipulate the AWS logs to only keep a single day’s worth of activity in an attempt to hide his crimes. 

Throughout this process, rightly or wrongly, Ubiquiti was playing their cards close to their chest in talking with the public. But there was apparently enough evidence in March for the Feds to decide that Sharp was a suspect, leading them to execute a warrant at his residence. 

That’s when he decided to double down on kicking his employer in the soft parts with some misdirection and leaked details to Brian Krebs, pretending to be a whistleblower. The result of the leak was a 20% loss in stock valuation, estimated to run them about $4 billion off their market cap. 

Despite his attempts at being clever, using a VPN and tampering with evidence, in the end his amateur opsec did him in. He paid for the VPN account with his own PayPal account and his home IP leaked when the VPN took a momentary break.   

But beyond dunking on this dude for his comedy of errors, this story is almost the perfect storm of just about everything that can go wrong in Authorization Security Management.

5 Authorization Mistakes to Avoid

In hopes of avoiding similar mistakes, let’s do a quick rundown of what went wrong at Ubiquiti based on the information available. 

This will be fun

  • The Insider Posing as an Outsider Pretending to be an Insider
    When Ubiquiti’s team first detected that the attacker was downloading proprietary code, their first assumption was that an external hacker had compromised the credentials of an employee.This is a pretty fair assumption given how it happens all the time.According to research by the Identity Defined Security Alliance (IDSA), “79% of organizations have experienced an identity-related breach in the past two years.” Identities have become the new perimeter, acting as our protection and keys to access our valuable resources as we’ve moved away from the network and more towards the cloud. Always keeping up with the trends, attackers have shifted their focus to exploiting insufficiently defended identities and assets.

    As a member of their cloud division, it makes sense that Sharp would have entitlements for many of the different services that his company was using.

    The question is if he was still over-privileged with his rights within each of these services? Were his privileges in line with best practices like Least Privilege?

    An over-privileged user is a potential threat since an attacker can use their wide reaching access to move laterally inside the organization from one resource to another. These highly privileged users need to be limited in number and closely monitored for potential abuse.

    We need to constantly aim to limit the blast radius when an account becomes malicious — no matter who is in control of it.

  • Assets Need Attention Too — Breaking the Silos
    In the Identity-First Security moment that we’re in, we can forget that identities don’t operate in a vacuum. Many Access Control tools focus on “securing identities”, but don’t take the asset side into account like they should.Sharp should not have been able to download gigabytes over the few weeks that he did without some kind of alarm bell going off. If we have security policies around our assets, then we should be able to know when someone is accessing it regularly and doing quite a bit of activity.
  • Getting the Whole Picture
    Part of the challenge of the highly distributed services in the cloud is that far too many people are using tools that only cover their IaaS or SaaS. If you’re not looking at everything in play, then you may be missing critical warnings.Sharp was abusing his creds for both AWS and GitHub, IaaS and SaaS respectively.
  • Don’t Let the Fox in the Henhouse
    It’s still a bit unclear from the reporting if Ubiquiti knew from the get go that it was Sharp’s credentials that were used to carry out the hack. But the speed that they seemed to have moved on him with the warrant may imply that they were on to him pretty quickly.Assuming that they knew that it was his credentials that were used, why did they allow him to be part of the incident response team? Even if the initial indicators pointed to his identities for those services being compromised by an outsider, caution may call for keeping him off the case.

    Think about how we have Separation of Duties where a person making the payments can’t also be the payment approver. If Ubiquiti wasn’t able to identify this as a potential conflict, then that’s a problem.

  • Looking for Evidence in All the Wrong Places
    Logs are a logical place to start an investigation during incident response, but they only tell part of the story. Especially after Sharp cut their effectiveness by limiting how long they retained data.What would’ve been more effective if they were using the right tools, would have been to look at the permission layer that tracks who is using which permissions and how.



Sharp is now looking at 37 years as a guest of the US Dept. of Corrections if convicted on all charges. Play stupid games, win stupid prizes and all that, but he saw an open opportunity and took it.

Ubiquiti made its own share of unforced errors here. Though they are far from the only ones to make these kinds of mistakes. Nearly a decade into the cloud and two years into remote/hybrid work on speed, organizations are still making the adjustments for securing their data and ops in the cloud. 

Rates of success may vary, but most are behind where they should be and we as an industry can do better. This should start with a focus on managing privileged users, ensuring that we have the visibility and control over their accounts that can allow them to be used for doing us harm.

As we move into the new year, we need to make a real push to close the gaps in our threat surface that attackers can exploit, implementing the practices and tools to deny them opportunities for compromising us in the year to come.

Next read

Solution Brief

Learn how Authomize's solution is changing the way companies are managing authorizations