A Ubiquiti employee used shared cloud admin credentials to steal gigabytes of data, then posed as an anonymous hacker demanding a ransom. When everyone knows the password, nobody can be held accountable. Generic and shared accounts are the accountability gap that auditors close.
Marco Cavani
Cybersecurity Analyst
In January 2021, Ubiquiti Inc., a networking equipment manufacturer, disclosed a breach of its third-party cloud provider. The company described the incident as involving access to its customer account credentials. The announcement triggered a significant drop in Ubiquiti’s stock price.
What Ubiquiti did not disclose at the time was the true nature of the incident. A subsequent FBI investigation, a whistleblower account from Ubiquiti’s security team, and an eventual criminal prosecution revealed that the breach was an inside job.
Nikolas Sharp, a senior developer at Ubiquiti, had used his legitimate access to the company’s AWS and GitHub environments to clone gigabytes of proprietary data and source code. He then posed as an anonymous outside attacker and sent an extortion demand to Ubiquiti for EUR 50 Bitcoin (approximately USD $1.9 million at the time) in exchange for not releasing the stolen data. He also attempted to conceal his identity by routing his activity through a VPN.
The VPN failed on one occasion. His home IP address was captured in a server log. When federal agents visited his home, they found the cloned repositories on his computer. He was arrested, charged, and subsequently convicted of multiple federal crimes.
The investigation was complicated by the fact that Sharp had shared admin credentials that were not uniquely tied to his own identity for all his activities. Generic and shared account usage had created a forensic attribution challenge that he exploited as part of his concealment strategy.
Generic accounts, shared accounts, and inadequately governed service accounts create two distinct but equally serious risks:
No accountability: A shared account cannot be traced to an individual. If five people know the password to a shared admin account and something goes wrong, forensic investigation cannot determine who took the action. This is the foundation of Sharp’s concealment attempt.
Broad, persistent access without oversight: Generic and service accounts are often provisioned with broad access and minimal review. They may have been created for a specific purpose years ago, that purpose may no longer exist, and the access may be far broader than was ever justified.
The categories of concern include:
Shared interactive accounts: Multiple users log in to the same named account (e.g., “admin,” “sysadmin,” “root”). Activity in that account cannot be attributed to an individual.
Orphaned service accounts: Service accounts created to run automated processes that are no longer active, or whose password has never been changed, represent a latent attack surface.
Default accounts: Out-of-the-box admin accounts (e.g., “Administrator” on Windows, “sa” on SQL Server) that have not been disabled, renamed, or had their passwords changed.
Generic email accounts: Shared mailboxes or team email addresses used to authenticate to systems, preventing individual accountability for email-triggered actions.
Sharp’s access to Ubiquiti’s AWS environment was a function of his role. His use of shared administrative credentials reduced the forensic footprint of his activity: the access logs reflected the shared account name rather than his personal identity.
When he downloaded the repositories and source code, he used the shared admin credentials. When he sent the extortion email, he used a privacy-focused email provider and routed traffic through a VPN. He then participated in the company’s internal investigation, adding recommendations to bolster security and further obscuring any trail that might lead to him.
The investigation was ultimately successful because of a single VPN failure: one log entry captured his residential IP address. Without that accident, the shared credential usage would have made definitive attribution significantly more difficult.
Sharp was convicted of transmitting a programme designed to damage a computer, wire fraud, making false statements to the FBI, and obstruction of justice. He was sentenced to six years in prison.
The case is cited in discussions of both insider threat and generic account risks because it illustrates exactly what shared credentials enable: activity that cannot be attributed without ancillary evidence.
Shared administrative credentials for cloud environments: Ubiquiti’s AWS environment was accessible via shared credentials rather than individually attributed IAM accounts. Cloud environments should require individual IAM accounts for all human access. Shared credentials are incompatible with accountability.
No just-in-time or just-enough access model: Sharp’s access to clone the full repository set was a function of broad standing access rather than access provisioned for a specific task and then revoked. Just-in-time access models would have made the volume of data accessed more conspicuous.
No detection of anomalous data volume: The download of gigabytes of proprietary data should have triggered a DLP or SIEM alert based on volume alone, regardless of the account used.
Service accounts as an afterthought: In many organisations, service accounts accumulate over time with inadequate ownership assignment, stale passwords, and access far broader than needed for the service they support.
Individual accounts for all humans: No human logs into a shared or generic account. Every person has a uniquely attributed account. Shared accounts are for automated processes only, and only where no alternative exists.
Named ownership for all service accounts: Every service account has a named owner, an assigned system, and a documented business purpose. Service accounts without an owner are disabled.
Regular service account reviews: Service accounts are reviewed at least annually. Accounts whose associated services no longer exist, or whose passwords have not been changed within the rotation period, are disabled or remediated.
Default account management: All default accounts on newly provisioned systems are either disabled or have their passwords changed before the system is connected to the network. A process for tracking default account status is maintained.
Privileged access for service accounts: Service accounts that require elevated permissions are subject to the same privileged access management controls as human privileged accounts: limited scope, password rotation enforced by a PAM tool, and activity logging.
Prohibition on credential sharing: Policy explicitly prohibits sharing of individual account credentials. Technical controls, such as PAM tools that check out credentials on behalf of users without revealing the password, enforce this policy for high-risk accounts.
When auditing Generic and Shared Accounts (Control C.4), an IT auditor will typically:
Identify shared and generic accounts: Request a user account export from the Active Directory, cloud IAM, and key applications. Flag accounts that are not uniquely attributed to a named individual (e.g., “admin,” “backup,” “svc_report”). Each requires investigation.
Confirm individual account usage: For a sample of shared accounts identified, determine whether multiple individuals use the account. Interview relevant staff. Review access logs for concurrent sessions or access from multiple IP addresses as evidence of sharing.
Review service account register: Request a register of service accounts. For each, confirm that a named owner is assigned, the business purpose is documented, and the associated system is active. Accounts without owners or without active associated systems are findings.
Test service account password management: Confirm that service account passwords are managed by a PAM tool or are subject to a documented rotation schedule. Test whether passwords have been rotated within the defined rotation period.
Test default account status: For a sample of newly provisioned servers or applications during the period, confirm that default accounts (Administrator, sa, root) were disabled or had passwords changed before production deployment.
Assess cloud IAM: In cloud environments, confirm that human access is provisioned through individual IAM accounts with named users, not through shared credentials or access keys distributed to multiple people.
Nikolas Sharp’s conviction was only possible because of an accidental VPN failure that exposed a single log entry. In the absence of that accident, the shared credential environment he exploited might have made attribution impossible.
Eliminate shared human accounts. Every person must have an individual account. Shared accounts are an accountability gap that protects bad actors and complicates incident response.
Own every service account. A service account with no owner is an unmanaged access right waiting to be exploited. Assign owners, enforce reviews, disable orphans.
Use a PAM tool for privileged accounts. Privileged Access Management tools broker access to privileged accounts without revealing credentials. They enforce rotation, provide session recording, and create attribution evidence even where shared credentials might otherwise obscure activity.
Monitor for anomalous access volumes. Regardless of the account used, downloading gigabytes of data from a code repository is anomalous. DLP and SIEM detection of access volume spikes provides a detection layer that is account-agnostic.
Disable default accounts before go-live. Every unmanaged default account is a latent attack surface. Make default account review part of the system deployment checklist.
The MarcoWeb ITGC Tool covers Generic and Service Accounts as part of the Group C control set, with structured assessment templates for shared account identification, service account review, and default account testing.
Written by
Marco Cavani
Cybersecurity analyst and IT governance professional. Author of digital reports on threat intelligence, critical infrastructure security, and IT audit frameworks.
In 2017, a Bupa Global employee with broad database access downloaded the health insurance data of half a million customers and attempted to sell it. Application database access controls determine whether a single authorised user can reach every record in your finance and health systems, or only the records they need.
In July 2020, a teenager convinced Twitter employees to hand over access to an internal admin tool that could control any account on the platform. Obama, Biden, Musk, and Apple were among the victims. Privileged access management is the control that limits the blast radius when an insider is compromised.
Christopher Dobbins was terminated by Stradis Healthcare and used retained credentials to delete thousands of records needed to ship personal protective equipment during a global pandemic. Access termination is not an HR process. It is a security control.
Get the latest cybersecurity reports, threat intelligence, and IT governance insights delivered straight to your inbox. No spam. Unsubscribe any time.
No spam. Unsubscribe at any time.
The RACM ITGC SaaS platform helps audit professionals manage IT General Controls assessments, from risk and control mapping to workpaper generation and evidence tracking.
