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)

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 guidearrow-up-right 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_changelogin_success from new IP — the classic account takeover chain

  • member_removeshared_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 referencearrow-up-right. Some names differ from the Admin console UI labels. The Dropbox developer blog's CEF integration postarrow-up-right and Panther's Dropbox log schema documentationarrow-up-right are useful companion references.

Last updated