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_eventsAPI 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 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 travellogin_fail— High volume against a single account = brute-force signaltfa_change_status— 2FA disabled 🚨password_change— Especially outside business hours or from a new IPsign_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 namespacefile_delete— Correlate with departing member timelinesfile_download— High velocity in a short window = exfiltration signalfile_move— From team folder to personal namespace is a red flagfile_copy— Staging data before exfiltrationfile_get_copy_reference— Precursor to cross-account file transferfile_permanently_delete— Bypasses trash; potential evidence destruction
Sharing & External Access:
shared_link_create— Check access level: public vs. team vs. password-protectedshared_link_view— Includes the accessor's IP, even for non-team membersshared_link_remove_expiry— Someone just extended indefinite access to a linkshared_link_settings_change_access_level— Link opened up to publicshared_content_add_invitees— Watch for external or personal email domainsshared_content_change_invitee_role— Viewer quietly promoted to editorshared_content_copy— Non-team member copying your content to their own Dropboxshared_content_download— External invitee bulk-downloading content
App & Integration Events:
app_link_user— Personal app linked; baseline and alert on new app namesapp_link_team— Team-wide OAuth grant 🚨 alert on every occurrenceapp_unlink_team— App removed (could indicate covering tracks)
Member & Team Management:
member_add— New invite; flag external domainsmember_remove— Offboarding; check for link persistencemember_change_admin_role— Privilege changemember_change_email— Account email changed (account takeover indicator)member_transfer_account_contents— Content moved between accountsgroup_add_member— Grants all group-shared folder access; watch for lateral movementgroup_change_management_type— Group admin control shifted to user-managed
Admin & Policy Changes:
team_folder_permanently_delete— Irreversible; potential evidence destructionsharing_change_link_policy— Team-wide link policy loosenedsharing_change_member_policy— External sharing policy changedtfa_add_exception— Member exempted from 2FA requirementtfa_change_policy— Team-wide 2FA policy changeddevice_delete— Device unlinked; normal during offboarding, suspicious otherwise
Suspicious patterns to detect
Velocity-based anomalies:
Burst of
file_downloadorshared_content_downloadevents within a short window, especially after hoursRapid sequence of
file_copyacross multiple team folders →shared_link_createwith public accessMultiple
shared_link_createevents across diverse folder paths within minutes of each other
Time-based anomalies:
login_successfrom a new country followed immediately byshared_link_createorapp_link_teamsign_in_as_session_startoutside business hours with no associated IT ticketHigh-volume
file_downloadevents in the 48 hours precedingmember_remove
Correlation patterns:
tfa_change_status(disabled) →password_change→login_successfrom new IP — the classic account takeover chainmember_remove→shared_link_viewfrom an external IP — link persisting post-offboardingsharing_change_link_policy(loosened) →shared_link_create(bulk) — policy change used as a staging actionapp_link_teamfrom 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. Some names differ from the Admin console UI labels. The Dropbox developer blog's CEF integration post and Panther's Dropbox log schema documentation are useful companion references.
Last updated

