On 24 April 2024, Dropbox detected unauthorised access to the production environment of Dropbox Sign, its eSignature service formerly known as HelloSign. Its investigation found that the attacker had gained access to an automated system configuration tool and compromised a back-end service account, which Dropbox described as "a type of non-human account used to execute applications and run automated services." That account had privileges to act within Sign's production environment, and the attacker used it to reach the customer database. The data exposed included email addresses, usernames, phone numbers and hashed passwords, along with authentication information: API keys, OAuth tokens and multi-factor authentication details. People who had only received or signed a document also had their names and emails exposed. Dropbox found no evidence that documents, agreements or payment information were accessed. It reset passwords, logged users out, restricted API keys until customers rotated them and coordinated the rotation of all API keys and OAuth tokens.
Key takeaways
- An attacker compromised a Dropbox Sign back-end service account through an automated system configuration tool.
- The service account's production privileges let the attacker reach the customer database.
- Exposed data included hashed passwords, API keys, OAuth tokens and MFA information, plus names and emails of non-account signers.
- Dropbox reset passwords, logged users out, restricted API keys until rotated and asked authenticator app users to reset MFA.
- The identity lesson: automation accounts often carry broad production rights, and when one is taken the customer credentials it can reach must all be rotated.
At a glance
| Organisation | Dropbox Sign (formerly HelloSign), part of Dropbox |
|---|---|
| When | Detected 24 April 2024; disclosed 1 May 2024 |
| Attacker | Unattributed |
| Entry point | An automated system configuration tool in Dropbox Sign's back end |
| Identities abused | A back-end service account with production privileges |
| Impact | Customer data exposed, including hashed passwords, API keys, OAuth tokens and MFA information; no documents accessed |
| Category | NHI. Incident class: confirmed NHI breach (compromised back-end service account) |
What happened
Dropbox wrote: "On April 24th, we became aware of unauthorized access to the Dropbox Sign (formerly HelloSign) production environment." Its investigation found that "a third party gained access to a Dropbox Sign automated system configuration tool. The actor compromised a service account that was part of Sign's back-end, which is a type of non-human account used to execute applications and run automated services. As such, this account had privileges to take a variety of actions within Sign's production environment. The threat actor then used this access to the production environment to access our customer database."
The data accessed included "Dropbox Sign customer information such as email addresses, user names, phone numbers and hashed passwords, in addition to general account settings and certain authentication information such as API keys, OAuth tokens, and multi-factor authentication." For people who received or signed a document without an account, names and emails were exposed. Users who signed up with Google had no password stored. Dropbox said it "found no evidence of unauthorized access to the contents of customers' accounts (i.e. their documents or agreements), or their payment information," and that the incident was isolated to Dropbox Sign's infrastructure.
In response, Dropbox said its security team "reset users' passwords, logged users out of any devices they had connected to Dropbox Sign, and is coordinating the rotation of all API keys and OAuth tokens." BleepingComputer reported that it also "restricted how API keys can be used until they are rotated by the customer." Users of authenticator apps were told to delete and reset their MFA entry. Malwarebytes noted that Dropbox reported the incident in a government filing and to data protection regulators and law enforcement.
Timeline
| Date | Event |
|---|---|
| 24 April 2024 | Dropbox becomes aware of unauthorised access to Dropbox Sign production. |
| 1 May 2024 | Dropbox discloses the incident; BleepingComputer reports it. |
| 2 May 2024 | Malwarebytes reports on the incident and Dropbox's filing. |
How it happened: the identity attack path
- Automation tool accessed. The attacker gained access to an automated system configuration tool.
- Service account compromised. A back-end service account used to run applications was taken over.
- Production privileges. The account could take a variety of actions in the production environment.
- Customer database reached. The attacker accessed customer data, including authentication secrets.
- Credential reset. Dropbox reset passwords and sessions and coordinated rotation of API keys and OAuth tokens.
Impact
- Data: emails, usernames, phone numbers, hashed passwords, account settings, API keys, OAuth tokens and MFA information.
- Non-account users: names and email addresses of people who received or signed documents.
- Not affected: documents, agreements, payment information and other Dropbox products, according to Dropbox.
What this means for NHI governance
Dropbox named the problem directly: a non-human account used to run automation had privileges across production. Service accounts like this are rarely logged into by a person, so they tend to accumulate access and escape the scrutiny that human admin accounts get. Once taken, the account let the attacker read customer secrets, which then had to be rotated by customers themselves.
The fix is least privilege for automation, strong protection of the tools that use it, and customer secrets stored so that even a production account cannot read them in bulk. See our Service Account Security Guide and API Key Management Guide.
Recommendations
- Scope automation accounts tightly. A configuration tool's account should not be able to read customer data. See our Service Account Security Guide.
- Protect the tools that hold service credentials. Restrict and monitor access to configuration and deployment tooling. See the CI/CD Pipeline Identity Security Guide.
- Hash or encrypt customer secrets. Store API keys and tokens so a database read does not reveal usable values. See the API Key Management Guide.
- Rotate API keys and OAuth tokens after exposure. Restricting keys until rotation, as Dropbox did, limits misuse. See the Leaked Credential Response Playbook.
- Alert on service account behaviour changes. Bulk database reads by an automation account are a red flag. See the ITDR Guide.
Frequently asked questions
How was Dropbox Sign breached?
An attacker gained access to an automated system configuration tool and compromised a back-end service account with production privileges, then used it to access the customer database.
What data was exposed in the Dropbox Sign breach?
Emails, usernames, phone numbers, hashed passwords, account settings, API keys, OAuth tokens and MFA information. Dropbox found no evidence that documents or payment data were accessed.
What did API customers need to do?
Generate a new API key, configure it in their applications and delete the old one. Dropbox restricted API key functionality until then.
Related NHI Mgmt Group resources
Okta Support System Breach 2023 · Sisense Breach 2024 · Service Account Security Guide · API Key Management Guide · Leaked Credential Response Playbook
How NHI Mgmt Group can help
Automation accounts often hold the widest access in production. We help teams scope them, protect the tools that use them and rotate customer secrets quickly. See our NHI and AI agent security training.