Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0882: Detection of Web Services

DET0882 is a detection strategy for identifying adversary use of compromised third-party web services as operational infrastructure, as linked to ATT&CK te...

EnterpriseDET0882Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0882 is a detection strategy for identifying adversary use of compromised third-party web services as operational infrastructure, as linked to ATT&CK technique T1584.006 Web Services. For leaders, the practical issue is that trusted external services can make adversary preparation harder to distinguish from normal business activity. This matters before an incident reaches malware or hands-on-keyboard activity: compromised or abused web service accounts may support targeting and later operations while blending into legitimate cloud and SaaS usage.

Executive priority

Prioritize this as a visibility and governance question around externally hosted services, SaaS accounts, and third-party web platforms used by the business. Executives should ask whether the organization can identify suspicious ownership, access, or administrative changes in web service accounts that matter to brand, communications, development, storage, or customer engagement. The decision value is in confirming whether SOC, incident response, identity, and cloud/SaaS governance teams have evidence to investigate abuse of legitimate services rather than only blocking known-bad infrastructure.

Technical view

The ATT&CK object has no official description, detection text, tactics, or platforms of its own, so implementation should be driven by the relationship to T1584.006 Web Services under Resource Development with platform PRE. Detection engineering should validate coverage for suspicious access to or changes within third-party web services that could indicate account compromise or takeover. SOC teams should correlate identity events, administrative actions, account recovery activity, API token changes, unusual logins, and external service usage patterns where logs are available. IR teams should be prepared to determine whether a web service account was merely accessed, had ownership or credentials changed, or was repurposed as infrastructure for later activity.

Likely telemetry

  • Third-party web service audit logs where available
  • SaaS and cloud identity sign-in logs
  • Administrative change logs for accounts, ownership, permissions, recovery settings, and API tokens
  • SSO, MFA, and identity provider logs tied to external service access
  • Email and account recovery notifications related to web service accounts

Detection direction

  • Inventory which business-relevant third-party web services can produce usable audit evidence; many blind spots come from services that are used operationally but not onboarded to logging or SSO.
  • Tune detections around suspicious account changes rather than service use alone, since popular web services such as repositories, social platforms, file-sharing, and messaging services often have legitimate business traffic.
  • Correlate external service alerts with identity context: new login geography, new device, impossible travel, MFA changes, password reset, token creation, permission escalation, or ownership transfer.
  • Use the relationship to T1584.006 as pre-incident context: alerts may represent adversary preparation rather than immediate execution, so escalation criteria should consider business criticality of the account and whether it could support targeting or infrastructure.
  • Avoid over-reliance on domain or URL blocking because the related technique involves legitimate web services that may be required for normal operations.

Mitigation priorities

  • Maintain an inventory of official business accounts on third-party web services, including owners, recovery contacts, and logging availability.
  • Require strong identity controls for managed service accounts where supported, including centralized authentication, MFA, least privilege, and controlled API token use.
  • Onboard critical web services to audit logging, alerting, and incident response playbooks before an incident occurs.
  • Define ownership and recovery procedures so incident responders can quickly regain control of compromised web service accounts.
  • Review whether procurement, SaaS governance, and compliance evidence cover externally hosted services that could be abused as infrastructure.
Analyst notes and limits

This take is based on the supplied DET0882 detection strategy metadata and its relationship to T1584.006 Web Services. The related ATT&CK description emphasizes adversaries compromising access to legitimate third-party web services such as GitHub, Twitter, Dropbox, Google, and SendGrid for use during targeting and later cyber operations. The highest-value defensive work is confirming visibility and ownership over the services your organization actually uses.

The DET0882 object does not provide an official description, detection logic, platforms, tactics, or data sources. The guidance above is therefore conservative and derived from the supplied relationship to T1584.006 plus the listed external reference. Local service inventory, logging availability, identity architecture, and business process evidence are required to determine actual coverage.

Official MITRE ATT&CK definition

Detection of Web Services

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1584.006 Web Services Sub-technique This object detects Web Services.
Relationship explorer

All related ATT&CK context

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
086b0f4a6f3f3329...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 086b0f4a6f3f…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0882
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.