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

T1606: Forge Web Credentials

Adversaries may forge credential materials that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies, tokens, or other materials to authenticate and authorize user access.

Adversaries may generate these credential materials in order to gain access to web resources. This differs from Steal Web Session Cookie, Steal Application Access Token, and other similar behaviors in that the credentials are new and forged by the adversary, rather than stolen or intercepted from legitimate users.

The generation of web credentials often requires secret values, such as passwords, Private Keys, or other cryptographic seed values.[1] Adversaries may also forge tokens by taking advantage of features such as the `AssumeRole` and `GetFederationToken` APIs in AWS, which allow users to request temporary security credentials (i.e., Temporary Elevated Cloud Access), or the `zmprov gdpak` command in Zimbra, which generates a pre-authentication key that can be used to generate tokens for any user in the domain.[2][3]

Once forged, adversaries may use these web credentials to access resources (ex: Use Alternate Authentication Material), which may bypass multi-factor and other authentication protection mechanisms.[4][5][6]

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

Analyst context for executives and security teams

Analyst confidence High

Forge Web Credentials matters because an attacker who can create valid-looking cookies, tokens, or federation credentials may access web, SaaS, cloud, or identity-backed services without stealing a user’s current password or session. For leaders, the key issue is whether the organization can prove that web credentials are only issued by trusted systems, with controlled signing secrets, monitored token creation paths, and enough audit history to investigate suspicious access.

Executive priority

Prioritize this as an identity and cloud resilience issue, not just a web application issue. The ATT&CK object covers SaaS, IaaS, Office Suite, Identity Provider, and major endpoint platforms, so coverage depends on coordinated ownership across IAM, cloud, application, and SOC teams. Executives should ask whether token-signing materials, pre-authentication keys, temporary credential APIs, and privileged role paths are governed, audited, and reviewed as high-risk access mechanisms. This is especially important for incident response because forged credentials may bypass MFA and can make access appear authenticated unless token issuance and use are correlated.

Technical view

SOC and detection teams should validate whether they can connect credential use back to legitimate issuance. Useful analysis includes comparing SAML tokens, cookies, temporary cloud credentials, and application tokens against authoritative IdP, SaaS, cloud API, and application logs. Pay particular attention to token claims, lifetimes, role assumptions, federation token requests, signing certificate or private key access, and administrative commands or configurations that can generate pre-authentication material. Because ATT&CK provides no official detection text for T1606, teams should use the related DET0260 detection strategy as a planning reference but confirm detection logic locally.

Likely telemetry

  • Identity provider authentication, federation, token issuance, and administrative audit logs
  • SaaS and Office Suite audit logs showing session creation, token use, user impersonation, and administrative changes
  • Cloud control-plane logs for temporary credential requests such as role assumption or federation token activity
  • Application and web server authentication/session logs, including cookie or token validation events where available
  • Certificate, private key, secret store, and signing material access or configuration audit logs

Detection direction

  • Validate that token or cookie use can be correlated to an expected issuance event from the IdP, cloud provider, SaaS platform, or application.
  • Hunt for unusual token claims, excessive lifetimes, unexpected roles, anomalous user-agent/source patterns, or access that continues despite normal authentication controls.
  • Monitor creation, access, export, or modification of token-signing certificates, private keys, pre-authentication keys, and other cryptographic seed material.
  • Review cloud API activity for legitimate but high-risk temporary credential generation paths, including role assumption and federation token requests.
  • Tune detections to account for legitimate automation, federation workflows, service accounts, and administrative maintenance to reduce false positives.

Mitigation priorities

  • Enforce user account management and least privilege so users and service accounts cannot request or mint broader web credentials than required.
  • Apply privileged account management to administrators, token-signing infrastructure, federation configuration, cloud roles, and systems that store private keys or pre-authentication material.
  • Strengthen auditing for identity providers, SaaS applications, cloud control planes, application servers, and secret or certificate stores; ensure logs support incident reconstruction.
  • Review software configuration for token lifetimes, signing settings, federation trust, pre-authentication features, and temporary credential policies where those controls are available.
  • Regularly review account, role, and trust relationships to remove stale permissions that could enable forged credential creation or misuse.
Analyst notes and limits

This technique is a parent for Web Cookies and SAML Tokens, so local scoping should start with the organization’s actual web authentication architecture: IdP, SaaS platforms, IaaS providers, Office Suite integrations, and internally hosted applications. The related mitigations point to account management, privileged account management, auditing, and software configuration as the main defensive levers. The most important analytic question is whether a credential presented to a service can be traced to a legitimate issuance path.

The supplied ATT&CK object does not include official detection text, procedure examples, or platform-specific detection logic. The telemetry and control guidance above is inferred from the official description, platforms, external references, and stated mitigation/detection relationships. Local validation is required to determine which logs exist, how long they are retained, and whether token issuance and token use can actually be correlated.

Official MITRE ATT&CK definition

Forge Web Credentials

Adversaries may forge credential materials that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies, tokens, or other materials to authenticate and authorize user access.

Adversaries may generate these credential materials in order to gain access to web resources. This differs from Steal Web Session Cookie, Steal Application Access Token, and other similar behaviors in that the credentials are new and forged by the adversary, rather than stolen or intercepted from legitimate users.

The generation of web credentials often requires secret values, such as passwords, Private Keys, or other cryptographic seed values.[1] Adversaries may also forge tokens by taking advantage of features such as the `AssumeRole` and `GetFederationToken` APIs in AWS, which allow users to request temporary security credentials (i.e., Temporary Elevated Cloud Access), or the `zmprov gdpak` command in Zimbra, which generates a pre-authentication key that can be used to generate tokens for any user in the domain.[2][3]

Once forged, adversaries may use these web credentials to access resources (ex: Use Alternate Authentication Material), which may bypass multi-factor and other authentication protection mechanisms.[4][5][6]

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

Related techniques

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1606.001 Web Cookies Sub-technique Web Cookies subtechnique of this object.
Enterprise T1606.002 SAML Tokens Sub-technique SAML Tokens subtechnique of this object.
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1026: Privileged Account Management Enterprise subtechnique of · Technique T1606.001: Web Cookies Enterprise subtechnique of · Technique T1606.002: SAML Tokens Enterprise detects · Detection Strategy DET0260: Detection Strategy for Forged Web Credentials Enterprise mitigates · Mitigation M1054: Software Configuration Enterprise mitigates · Mitigation M1047: Audit Enterprise mitigates · Mitigation M1018: User Account Management Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

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
a82f06fe58faa5f1...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.5 Current bundle a82f06fe58fa…
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]
    GitHub AWS-ADFS-Credential-Generator

    Damian Hickey. (2017, January 28). AWS-ADFS-Credential-Generator. Retrieved September 27, 2024.

    Open source URL
  2. [2]
    AWS Temporary Security Credentials

    AWS. (n.d.). Requesting temporary security credentials. Retrieved April 1, 2022.

    Open source URL
  3. [3]
    Zimbra Preauth

    Zimbra. (2023, March 16). Preauth. Retrieved May 31, 2023.

    Open source URL
  4. [4]
    Pass The Cookie

    Rehberger, J. (2018, December). Pivot to the Cloud using Pass the Cookie. Retrieved April 5, 2019.

    Open source URL
  5. [5]
    Unit 42 Mac Crypto Cookies January 2019

    Chen, Y., Hu, W., Xu, Z., et. al. (2019, January 31). Mac Malware Steals Cryptocurrency Exchanges’ Cookies. Retrieved October 14, 2019.

    Open source URL
  6. [6]
    Microsoft SolarWinds Customer Guidance

    MSRC. (2020, December 13). Customer Guidance on Recent Nation-State Cyber Attacks. Retrieved December 17, 2020.

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