# Hunting in Dropbox

Dropbox is one of the most widely deployed cloud storage platforms in the enterprise — which also makes it a prime target for data exfiltration, insider threats, and credential abuse. Let's do some threat hunting (and detection engineering) to get a handle on what's really happening in your team's Dropbox environment.

> Throughout this document, we'll list audit log event types of interest you can use as part of your hunting. There's a longer list at the bottom, but the ones listed in the main writeup are some of the most useful signals we've found. All event types come from Dropbox's `team_log/get_events` API endpoint, available to Dropbox Business, Advanced, and Enterprise customers.

***

### Thoughts on Dropbox

#### It's not just files

When most people think about auditing Dropbox, they think about files — who uploaded what, who deleted what. And yes, file activity matters. But Dropbox is also a sharing platform, an integration hub, and for many organizations, a de facto collaboration layer. That means the threat surface is much broader than it first appears.

Shared links are public URLs. Third-party app integrations can read everything a user can read. Team folder structures can expose the org chart and project portfolio to anyone with access. The goal of hunting in Dropbox is to understand the full picture: who has access, what they're doing with it, and what's leaving the building.

#### Plan tiers affect what you can see

This catches security teams off guard more than almost anything else. File-level activity events — `file_add`, `file_delete`, `file_download` — are only available on **Dropbox Business Advanced and Enterprise** plans. On Standard plans, you'll primarily see member management, sharing, and login events. Know what plan you're on before you start hunting, because it determines what you're blind to.

Dropbox's audit logs are accessible from the Admin console under **Activity**, or programmatically via the Business API by POSTing to `https://api.dropboxapi.com/2/team_log/get_events` with a scoped token carrying `events.read` permissions.

***

### What's in Dropbox (and why attackers care)

#### Shared links: The unlocked door

Dropbox's shared link feature is one of its most useful — and most dangerous — capabilities. A `shared_link_create` event means someone just created a link that, depending on settings, could be publicly accessible to anyone on the internet with the URL. These links don't always require authentication. They don't expire by default. And once created, they're hard to revoke at scale.

Watch for `shared_link_create` across sensitive folders, especially when the access level is `public`. Watch equally hard for `shared_link_settings_change_access_level` — a link quietly upgraded from team-only to public is a significant change worth investigating. The [Dropbox developer blog's CEF integration guide](https://dropbox.tech/developers/converting-the-dropbox-activity-log-into-common-event-framework-) calls sharing events out as "high security impact and severity," and they're not wrong.

#### App integrations: OAuth all the way down

Dropbox supports OAuth-connected third-party applications. The event `app_link_user` fires when a user links a personal app to their account — a PDF converter, an e-signature tool, a backup utility. Annoying but manageable. `app_link_team` is the far more dangerous variant: a team-linked app gets access across the entire team namespace. One compromised OAuth app with a `app_link_team` grant is a complete data exfiltration vector.

Hunting for new and unusual `app_link_team` events — particularly from application names you don't recognize — should be a standing detection rule in every environment.

#### Member management: The provisioning/deprovisioning gap

Every `member_add` event deserves scrutiny. Who invited this person? What's their email domain? A contractor with a personal Gmail being added to sensitive shared folders is a risk most orgs don't catch until after the fact.

The flip side matters equally: `member_remove` events that are *not* followed by revocation of shared link access create a persistent window. Dropbox does not automatically expire shared links when a member is removed. An attacker — or simply a departing employee — who extracted links before offboarding can still use them.

#### Two-factor authentication: The canary in the coalmine

`tfa_change_status` is one of the highest-signal events in the Dropbox audit log. When a team member disables two-factor authentication, it's either a security regression or an indicator of account compromise. It should always fire an alert. Full stop. 🚨

***

### How and what to look for

Dropbox's Admin console Activity page is functional — filter by date, member, event type, and content, click any row for a side panel showing the exact timestamp, file path, IP address, and device. It works. But it's linear. You're scrolling a timeline, not doing analytics.

For hunting at scale, pull from `team_log/get_events` directly and push into your SIEM or data lake. Events return a consistent schema: `timestamp`, `event_category`, `event_type`, `actor`, `context`, `origin`, and `participants`. The `origin` field is your pivot point — it carries source IP, access method (web, desktop, mobile), and geographic location, making it the cornerstone of impossible travel and anomalous session detection.

Dropbox exposes a cursor-based `team_log/get_events/continue` endpoint for pagination and continuous polling. Poll every 5–10 minutes, store the raw JSON, and you own your retention independent of Dropbox's 180-day (Business/Advanced) or 365-day (Enterprise) log limits. Panther's open-source detection library also ships pre-built rules for Dropbox `Dropbox.TeamEvent` logs that are worth using as a starting baseline.

Use Turngate

***

### Audit events of interest

**Authentication & Access:**

* `login_success` — Pivot on IP and geo; this is your foundation for impossible travel
* `login_fail` — High volume against a single account = brute-force signal
* `tfa_change_status` — 2FA disabled 🚨
* `password_change` — Especially outside business hours or from a new IP
* `sign_in_as_session_start` — Admin impersonating a team member; always review

**File Operations (Advanced/Enterprise only):**

* `file_add` — Bulk uploads of unusual file types to personal namespace
* `file_delete` — Correlate with departing member timelines
* `file_download` — High velocity in a short window = exfiltration signal
* `file_move` — From team folder to personal namespace is a red flag
* `file_copy` — Staging data before exfiltration
* `file_get_copy_reference` — Precursor to cross-account file transfer
* `file_permanently_delete` — Bypasses trash; potential evidence destruction

**Sharing & External Access:**

* `shared_link_create` — Check access level: public vs. team vs. password-protected
* `shared_link_view` — Includes the accessor's IP, even for non-team members
* `shared_link_remove_expiry` — Someone just extended indefinite access to a link
* `shared_link_settings_change_access_level` — Link opened up to public
* `shared_content_add_invitees` — Watch for external or personal email domains
* `shared_content_change_invitee_role` — Viewer quietly promoted to editor
* `shared_content_copy` — Non-team member copying your content to their own Dropbox
* `shared_content_download` — External invitee bulk-downloading content

**App & Integration Events:**

* `app_link_user` — Personal app linked; baseline and alert on new app names
* `app_link_team` — Team-wide OAuth grant 🚨 alert on every occurrence
* `app_unlink_team` — App removed (could indicate covering tracks)

**Member & Team Management:**

* `member_add` — New invite; flag external domains
* `member_remove` — Offboarding; check for link persistence
* `member_change_admin_role` — Privilege change
* `member_change_email` — Account email changed (account takeover indicator)
* `member_transfer_account_contents` — Content moved between accounts
* `group_add_member` — Grants all group-shared folder access; watch for lateral movement
* `group_change_management_type` — Group admin control shifted to user-managed

**Admin & Policy Changes:**

* `team_folder_permanently_delete` — Irreversible; potential evidence destruction
* `sharing_change_link_policy` — Team-wide link policy loosened
* `sharing_change_member_policy` — External sharing policy changed
* `tfa_add_exception` — Member exempted from 2FA requirement
* `tfa_change_policy` — Team-wide 2FA policy changed
* `device_delete` — Device unlinked; normal during offboarding, suspicious otherwise

***

### Suspicious patterns to detect

**Velocity-based anomalies:**

* Burst of `file_download` or `shared_content_download` events within a short window, especially after hours
* Rapid sequence of `file_copy` across multiple team folders → `shared_link_create` with public access
* Multiple `shared_link_create` events across diverse folder paths within minutes of each other

**Time-based anomalies:**

* `login_success` from a new country followed immediately by `shared_link_create` or `app_link_team`
* `sign_in_as_session_start` outside business hours with no associated IT ticket
* High-volume `file_download` events in the 48 hours preceding `member_remove`

**Correlation patterns:**

* `tfa_change_status` (disabled) → `password_change` → `login_success` from new IP — the classic account takeover chain
* `member_remove` → `shared_link_view` from an external IP — link persisting post-offboarding
* `sharing_change_link_policy` (loosened) → `shared_link_create` (bulk) — policy change used as a staging action
* `app_link_team` from unknown application → `shared_content_download` — OAuth app immediately harvesting data

***

### A note on gaps

Dropbox is explicit that some activity is not captured in the team log. Microsoft co-authoring session activity, certain Dropbox Sign workflows, and actions performed during some third-party integrations may not appear. Understand your blind spots — because an attacker certainly will.

***

*Event type names follow the Dropbox Business API v2 `team_log/get_events` schema and the* [*Dropbox Java SDK EventTypeArg reference*](https://dropbox.github.io/dropbox-sdk-java/api-docs/v3.2.x/com/dropbox/core/v2/teamlog/EventTypeArg.html)*. Some names differ from the Admin console UI labels. The Dropbox developer blog's* [*CEF integration post*](https://dropbox.tech/developers/converting-the-dropbox-activity-log-into-common-event-framework-) *and Panther's* [*Dropbox log schema documentation*](https://docs.panther.com/data-onboarding/supported-logs/dropbox) *are useful companion references.*