The VPN gap that unmasked an insider extortionist
Ubiquiti had a breach. Someone was inside the network, moving through GitHub and AWS, quietly copying confidential material. Then the emails started, not to a competitor, not to a foreign buyer, but to Ubiquiti itself: pay up, or the data goes public. Months later, an anonymous “concerned insider” started reaching out to security reporter Brian Krebs of KrebsOnSecurity, warning that the company was hiding something far worse than it admitted. The theft, the extortion note, and the whisper campaign looked, at first, like three separate problems. They turned out to be the same person, working three jobs at once. (Thief, extortionist, and anonymous tipster: an ambitious three-hat rotation for someone still drawing one paycheck.)
What actually happened
Nickolas Sharp was a senior software developer at Ubiquiti (Ubiquiti Networks renamed to Ubiquiti Inc. in 2019), its Cloud Lead, with legitimate, privileged access to the company’s AWS infrastructure and GitHub source-code repositories as part of his day job. Prosecutors say that over roughly three weeks in December 2020, starting December 9, he used that access to download an AWS admin key that unlocked further internal credentials and to clone around 155 of the company’s GitHub repositories, gigabytes of confidential data in all, while routed through a Surfshark VPN meant to make the activity look like it came from an outside attacker.
Weeks later, in January 2021, Ubiquiti received an anonymous ransom demand for 50 bitcoin, worth roughly $1.9 million at the time: 25 bitcoin to return the stolen files, 25 more to disclose an alleged “backdoor” in the company’s systems, with a threat to publish the data if the company refused to pay. Ubiquiti opened an internal investigation, and Sharp, in his day job, was part of the team assigned to it; prosecutors say he used that position to set some of the relevant AWS logs to auto-delete after a single day. (Investigating yourself is one way to guarantee the lead suspect never gets away. It just helps if that isn’t also the plan.)
The FBI searched Sharp’s Portland, Oregon home on March 24, 2021, seizing the laptop and other devices he’d used, the same laptop prosecutors say he had already wiped in an attempt to erase his tracks.
Then came the second act. Days after that search, someone using an anonymous identity told security reporter Brian Krebs that the breach was far larger than Ubiquiti was letting on, and that the company was downplaying it to protect its stock price. Krebs published the claims on KrebsOnSecurity on March 30, 2021 (he retracted the story a year and a half later, once his source’s identity became public). Ubiquiti’s share price dropped roughly 20% over the following two trading days, wiping out more than $4 billion in market capitalization. Prosecutors later said that anonymous “insider” tipping off the press was Sharp himself, already a search-warrant target, doubling down anyway. (A move straight out of the heist-movie playbook: rob the vault, then volunteer as the source explaining how bad the robbery really was.)
Ubiquiti fired him the following month. He was charged in December 2021, pleaded guilty in February 2023, and was sentenced to six years in prison, plus three years of supervised release and more than $1.5 million in restitution.
The artifact: not the stolen data, the log that placed him at both ends of the story
The stolen source code and the ransom note are the headline. What actually built the case was quieter: connection logs. Specifically, Sharp’s VPN session records, read alongside the ordinary connectivity logs from his own home internet service.
According to prosecutors, the Surfshark VPN masking his activity dropped during a brief outage at his home while he was in the middle of cloning Ubiquiti’s GitHub repositories, and for that window the traffic reaching Ubiquiti’s systems resolved back to Sharp’s home IP address, the same network he was using that day for his real, authorized work, logged alongside his usual Surfshark exit-node address in the same session. A masking tool is only as good as its uptime. A few minutes of failure is enough to attach a name to an anonymous session. (Anonymity is one of those things, like an alibi, that only works if it holds for the entire runtime, not just the parts you were paying attention to.)
That kind of log evidence is powerful, but it does not interpret itself. One IP address appearing once is a data point, not a verdict. It has to be tested: was the “leaked” session genuinely continuous with the masked one, or could two separate sessions have been read as one? Did the account’s activity on AWS and GitHub follow a consistent pattern (the same working hours, the same technical habits) across both the “authorized” and “unauthorized” windows? Investigators also cross-referenced that IP correlation against Sharp’s own administrative access patterns, and against his attempts to cover his tracks (the auto-deleted logs, the wiped laptop), which, once uncovered, became evidence in their own right. One coincidence proves nothing. A set of coincidences, tested and ruled out one at a time, can.
What a software expert witness actually tests in a case like this
This is where a software expert witness does the part a lawyer’s summary can’t: it doesn’t stop at “the IP matched.” It tests whether it should have.
That means pulling the VPN provider’s own connection logs and understanding the retention policy behind them, not just accepting a party’s summary of what they show. It means checking the home ISP or router logs for the exact window in question, and confirming whether the clocks across every system involved (the VPN client, the ISP, the cloud platform’s own audit trail) were synchronized closely enough to support the claimed correlation, or loose enough to leave real doubt. It means comparing the access pattern during the alleged theft against the account’s routine, authorized activity, because a working administrator’s log is full of innocent-looking entries that need to be told apart from the incriminating ones. And it means tracing the extortion email and the anonymous message to the journalist back through their own metadata (headers, sending infrastructure, writing style) to see whether they independently point to the same actor as the log correlation does.
None of that is exotic. It is patient, structured work: name the technical question, list the systems and logs involved, apply a method another expert could repeat, and state plainly what the evidence does and does not establish. That discipline is what makes a finding survive cross-examination instead of folding under the first hard question about clock drift or log retention.
Why this matters beyond one company
Sharp did not need to break in from outside. He already had a badge, a VPN token, and a legitimate reason to be in every system he touched. That is exactly what makes an insider threat harder to catch than an external one, and harder still to prove in court: the access itself is not suspicious, only what someone does with it. Any company that hands developers or administrators broad cloud and repository permissions is one bad month away from asking the same question a court eventually asked here: not whether someone had access, but whether the evidence, tested properly, shows what they actually did with it.
For Israeli tech companies running the same kind of sprawling AWS and GitHub permissions, and for the litigators who end up representing them, the real lesson has less to do with VPNs than with building, before any dispute exists, a log-retention and access-review practice detailed enough that if an insider ever tries this, the record cannot be read two ways.
The above is general information and not legal advice. Case facts are drawn from U.S. DOJ (SDNY) press releases and court filings in United States v. Nickolas Sharp, and from contemporaneous reporting by KrebsOnSecurity, The Register, CSO Online, BleepingComputer, and The Record.