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

T1538: Cloud Service Dashboard

An adversary may use a cloud service dashboard GUI with stolen credentials to gain useful information from an operational cloud environment, such as specific services, resources, and features. For example, the GCP Command Center can be used to view all assets, review findings of potential security risks, and run additional queries, such as finding public IP addresses and open ports.[1]

Depending on the configuration of the environment, an adversary may be able to enumerate more information via the graphical dashboard than an API. This also allows the adversary to gain information without manually making any API requests.

EnterpriseT1538TechniqueObject v1.5 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Cloud Service Dashboard is a discovery behavior where an adversary with stolen credentials uses a cloud provider or SaaS graphical console to understand what services, resources, risks, public IPs, and open ports exist. The business issue is that a successful login to a dashboard can turn one compromised identity into rapid situational awareness for an intruder, without obvious API enumeration patterns.

Executive priority

Prioritize this as an identity and cloud visibility problem. Leaders should ask whether console access is tightly governed, whether privileged and stale accounts are managed under least privilege, and whether SOC teams can distinguish normal administrator dashboard use from suspicious access. This technique matters for incident decision-making because dashboard access may reveal what the adversary could see before any destructive or disruptive action occurs.

Technical view

For IaaS, SaaS, Office Suite, and Identity Provider environments, validate monitoring of GUI-based cloud access and console sign-ins. ATT&CK provides no official detection text for T1538, but the relationship to DET0291 indicates a detection strategy focused on cloud service dashboard usage via GUI-based cloud access. SOC and IR teams should review cloud console sign-in evidence, identity provider authentication context, session characteristics, and any available dashboard activity records. Treat use by the Scattered Spider ATT&CK group as threat-context only, not as proof of activity in the local environment.

Likely telemetry

  • Cloud console sign-in events, including AWS Console Sign-in Events where applicable
  • Identity provider authentication logs for users accessing cloud or SaaS dashboards
  • Cloud audit logs showing GUI or console session activity where the provider records it
  • Administrative account, role, and privilege assignment records
  • Available dashboard or security-center activity records, such as access to asset, findings, public IP, or open-port views where logged

Detection direction

  • Validate that GUI console access is logged separately or clearly enough to distinguish it from API-only activity.
  • Tune detections around unusual dashboard access by privileged or sensitive accounts, especially from atypical identity, session, or access context.
  • Account for false positives from legitimate administrators, cloud engineers, auditors, and security teams who routinely use dashboards.
  • Look for identity-driven context first: stolen credentials may produce valid logins, so absence of malware or API enumeration does not rule out discovery.
  • Confirm whether the environment logs views and searches inside provider dashboards; some configurations may expose more information through the GUI than through APIs.

Mitigation priorities

  • Implement User Account Management controls, including least privilege and disciplined account lifecycle management.
  • Limit dashboard access to users and roles with a documented business need.
  • Review and remove stale, overprivileged, or unnecessary accounts that can access cloud, SaaS, Office Suite, or identity dashboards.
  • Ensure account changes and privilege grants are auditable for compliance and incident reconstruction.
  • Use incident response playbooks that quickly identify what dashboards a compromised account accessed and what information may have been exposed.
Analyst notes and limits

The supplied ATT&CK object frames this as discovery through legitimate cloud service dashboards using stolen credentials. The key defensive decision is whether identity governance and cloud logging are strong enough to make valid-but-suspicious dashboard use visible. Relationship context includes mitigation M1018 User Account Management, detection strategy DET0291, and use by G1015 Scattered Spider.

MITRE provides no official detection text for this technique in the supplied fields, and the DET0291 relationship includes only its name and basic metadata. Local cloud provider logging, SaaS audit capabilities, identity provider configuration, and account privilege design determine practical coverage.

Official MITRE ATT&CK definition

Cloud Service Dashboard

An adversary may use a cloud service dashboard GUI with stolen credentials to gain useful information from an operational cloud environment, such as specific services, resources, and features. For example, the GCP Command Center can be used to view all assets, review findings of potential security risks, and run additional queries, such as finding public IP addresses and open ports.[1]

Depending on the configuration of the environment, an adversary may be able to enumerate more information via the graphical dashboard than an API. This also allows the adversary to gain information without manually making any API requests.

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.

Associated objects

Groups, software, and campaigns

Group Enterprise

G1015: Scattered Spider

Scattered Spider is a native English-speaking cybercriminal group active since at least 2022. [1] [2] The group initially targeted customer relationship management (CRM) providers, business process outsourcing (BPO) firms, and telecommunications and technology companies before expanding in 2023 to gaming, hospitality, retail, managed service provider (MSP), manufacturing, and financial sectors. [2] Scattered Spider relies heavily on social engineering, including impersonating IT and help-desk staff, to gain initial access, bypass multi-factor authentication (MFA), and compromise enterprise networks. The group has adapted its tooling to evade endpoint detection and response (EDR) defenses and used ransomware for financial gain. [3] [4] [5] Scattered Spider had expanded into hybrid cloud and identity environments, using help-desk impersonation and MFA bypass to obtain administrator access in Okta, AWS, and Office 365. [6]

Relationship explorer

All related ATT&CK context

detects · Detection Strategy DET0291: Detection of Cloud Service Dashboard Usage via GUI-Based Cloud Access Enterprise uses · Group G1015: Scattered Spider Enterprise mitigates · Mitigation M1018: User Account Management Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

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.5
Created
Modified
Raw hash
d0049d4f925fda2b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.5 Current bundle d0049d4f925f…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    Google Command Center Dashboard

    Google. (2019, October 3). Quickstart: Using the dashboard. Retrieved October 8, 2019.

    Open source URL
  2. [2]
    AWS Console Sign-in Events

    Amazon. (n.d.). AWS Console Sign-in Events. Retrieved October 23, 2019.

    Open source URL
  3. [3]
    mitre-attack T1538
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use