What T1606 forge web credentials gives an attacker on SaaS and web apps
SOC leads need to know whether a session or token that looks valid could have been created outside the identity provider. T1606, Forge web credentials, sits under the Credential Access tactic (TA0006), which MITRE describes as the adversary trying to steal account names and passwords. Forged web credentials follow a different path: the adversary produces a credential that the application accepts as genuine, so it can act as an existing user without presenting that user's password. Because the forged value passes normal checks at the point of use, the activity can look like ordinary use of the account, which is why alerts built only on failed logins will miss it.
This matters most on SaaS platforms and internal web applications that trust tokens or cookies without checking where they came from. These services rely on signing keys or shared secrets held by the application or its identity provider. If that material is exposed, or if a service accepts values it never issued, a forged credential can be presented to any system that trusts it. Start with a register of every application that accepts self-issued tokens or external signing keys, and record who can read or rotate that material. Ask each SaaS vendor which session and token controls they expose to customers and which authentication events they log.
ATT&CK 20.0 lists two sub-techniques under T1606. Confirm their names and IDs in the enterprise-attack 20.0 bundle, and name the ATT&CK version in every detection mapping, since releases can rename or deprecate techniques. Assign each sub-technique to a named application or identity provider in your environment, with an owner who can confirm whether the platform logs the relevant events. Where a platform cannot provide that evidence, record the gap as a risk, because no detection can be validated against telemetry that does not exist.
Which telemetry reveals forged web credentials
This table compares the telemetry sources that can show forged or misused web credentials, the signal to look for in each, and the open-source collector that fits. Read each row as a question to answer in your own environment, since forged tokens often look valid until they are compared against issuance records. Check every data component ID against the ATT&CK 20.0 STIX bundle before you build rules on it.
| Data source | Signal to look for | Open-source collector |
|---|---|---|
| User Account Authentication | Session or token use with no matching issuance event from the identity provider or application | Wazuh with log collection from the identity provider, Security Onion for correlation |
| Application Log Content (SaaS audit trails) | Admin or API actions tied to a session that the audit trail never shows being created | Wazuh, with SaaS audit logs forwarded through a syslog or API collector |
| Network Traffic Content | Web requests carrying a token or cookie from a host, country or client profile that never used it before | Zeek HTTP and TLS logs, Suricata alerts, Security Onion |
| File Access | Reads or writes to local token caches, cookie stores or signing key files by unexpected processes | Wazuh file integrity monitoring, Velociraptor hunts for artifact access |
| Process Access | A non-browser or unknown process opening browser profile or credential store memory | Velociraptor endpoint hunts, Wazuh endpoint telemetry |
| Process Creation (context) | A signing or token-minting utility launched on a host that should not hold signing material | Wazuh, Velociraptor, Sigma rules applied to endpoint logs |
| Forged token replay (illustrative) | A token whose claims, lifetime or signature metadata do not match the identity provider's records | Zeek logs joined with identity provider logs in Security Onion |
Where forged tokens and cookies leave traces in web and SaaS logs
The most reliable signal for T1606 Forge web credentials is the gap between where a session was issued and where it was used. A token or session cookie is normally issued by the identity provider after a logged-in authentication event, and then presented to one or more SaaS applications over a period the identity provider controls. A valid-looking token is only suspicious when its issuance, lifetime or use does not match normal identity provider behavior. Defenders should confirm, for each identity provider and application in scope, which fields identify the issuing authentication event (session identifier, token identifier, client, network origin and authentication method), so that a later request can be matched back to a known issuance. Without that join, a forged credential and a stolen one look the same in application logs.
On endpoints, the places to watch are the token and cookie stores used by browsers, desktop SaaS clients and command-line tools on Windows, macOS and Linux. Changes to these stores by processes that are not the browser or client that normally owns them, or reads of them by unexpected processes, are signals worth alerting on. Coverage depends on the File Access and Process Access telemetry your endpoint agent actually collects, so confirm with the vendor or your own configuration exactly which paths and process relationships are captured before writing rules against them. Unusual authentication context in SaaS audit logs is the other main source: tokens presented from unfamiliar devices, impossible travel between sessions, lifetimes that exceed your configured policy, or sessions with no matching sign-in record. Detection quality depends on logging the identity provider and each SaaS application at a sufficient level of detail, and on retaining those logs long enough to investigate. Detection mappings in this section target Enterprise ATT&CK version 20.0, so confirm that the detection strategies and data component references you adopt still match that version before you deploy them.
Detection ideas for forged web credentials in SaaS and identity logs
The cards below describe detection ideas for T1606 Forge web credentials in SaaS and identity logs, written as logic you can package as Sigma rules and run in Wazuh or Security Onion. Each idea looks for a mismatch between what the identity provider issued and what a token or session later does, so tuning depends on knowing your normal sign-in patterns. Confirm each threshold against your own baseline before alerting.
Token use without matching issuance
This idea looks for a session or token that appears at a SaaS application or API without a corresponding issuance event in the identity provider's sign-in log for the same account and time window. Because forged web credentials never pass through the normal issuance path, the gap between use and issuance is the signal. Correlate application access logs with identity provider authentication events by session or token identifier, and confirm your identity provider records every token type you rely on. Tuning: set the correlation window and the tolerance for log delivery delay for your pipeline. False positives come from token refresh flows, SSO sessions issued before log retention began, and clock skew between systems.
New host or geography per account
This idea flags a single account whose sessions suddenly originate from a host, network or country not seen for that account in its recent history. Build a per-account baseline of source addresses and locations, then alert when a new combination appears alongside sensitive actions. Tuning: choose the baseline lookback and the definition of a new location to match how your workforce travels and where your egress points sit. False positives include VPN exit changes, remote workers, mobile clients that roam between networks, and service accounts that run from new automation hosts.
Anomalous token lifetime or claim change
This idea watches for tokens whose lifetime, audience, scope or role claims differ from the values your identity provider is configured to issue. A forged token often carries claims that no legitimate policy would produce, or a lifetime longer than the configured maximum. Compare observed claim sets against an allowlist exported from your identity provider configuration. Tuning: define which claim changes are expected during policy updates and which should always alert. False positives come from policy changes that have not yet been reflected in the allowlist, application-specific claim mappings, and tokens issued by a second identity provider during migration.
Cookie file access by unexpected processes
This idea alerts when a process other than the browser that owns a web session cookie store reads that file on an endpoint. Monitor file access events on known browser profile paths and alert when the reading process is a script interpreter, a command shell or an unsigned binary. Tuning: maintain an approved process list per operating system and per managed browser, and decide how to handle browsers installed outside standard paths. False positives include browser sync and backup tools, endpoint protection agents, password managers and forensic tooling.
Token use outside expected applications
This idea inspects network traffic content and proxy logs for bearer tokens or session identifiers presented to applications that the account does not normally use. Where TLS inspection is not in place, use application log content from the SaaS side and the proxy's destination and user agent fields instead. Tuning: list the applications each user group legitimately reaches and the user agents they send. False positives include new SaaS onboarding, APIs called by integrations, and browser extensions that call the same endpoints as the official client.
How to validate the T1606 detection in a lab before production
This sequence proves that a T1606 Forge Web Credentials detection fires on the telemetry you actually collect, that its false positive rate is understood against normal authentication activity, and that every result is tied to a specific rule version. It turns the detection from a hypothesis into a documented control that can be defended to auditors and operations teams.
Scope the technique and sub-techniques under test
Name the ATT&CK Enterprise version you are validating against, which for these pages is version 20.0, and list T1606 Forge Web Credentials along with its two sub-techniques, one per credential type in scope. Record the platforms in your estate that the detection covers, such as SaaS identity, Windows, macOS and Linux, and note which data components the detection depends on, including File Access and Network Traffic Content. Confirm the mapping against the technique page and the enterprise-attack 20.0 STIX bundle so the scope is traceable. The step is done when a signed scope sheet names the version, the sub-techniques, the in-scope platforms and the owner of each.
Design the emulation in a private cyber range
Work with the detection engineering owner to design a controlled exercise in a private cyber range that is isolated from production identity systems. Describe each test as a behavior and expected outcome, for example the category of web credential activity under review and what a defender should see, rather than writing tool commands or payloads. Use test accounts created for the purpose and agree a stop condition and a rollback path before the exercise begins. The step is done when the exercise plan is approved, lists every test behavior by sub-technique and has an agreed owner for the range and for the rollback.
Record expected log events for each step
For every test behavior, write down the log events you expect to appear, the source each one should come from, and the fields that must be present for the rule to match, such as account identifier, source host, timestamp and object accessed. Map each expectation to the data component it depends on, so gaps in collection are visible early. Include expected negative results too, where a benign action should not trigger the rule. The step is done when a table of expected events per test step exists, reviewed by someone who did not write the rule.
Confirm the rule matches collected telemetry
Run the exercise and pull the resulting events from your log platform, such as Wazuh, Security Onion or your SIEM, into the detection query. Compare what fired against the expected events from the previous step, recording each test as detected, missed or partially detected, along with the reason. Where a rule missed an event, check whether the telemetry was absent, malformed or simply outside the rule logic. The step is done when every test step has a recorded outcome and the match rate is written next to the expected count.
Measure false positives against a week of normal authentication data
Replay the rule against at least a week of normal authentication and web activity from the same environment, using production-like logs that have been handled under your data protection rules. Count each alert that fires on benign activity, group them by cause such as service accounts, automation or a known integration, and decide whether each group should be tuned, allowlisted with an owner and expiry, or kept. Agree with operations how many alerts per day the team can triage before tuning is required. The step is done when the false positive table is complete, each cause has a disposition, and the operations lead has accepted the alert volume.
Log results with the rule version
Record the test results in your detection register with the rule identifier, the rule version and hash, the ATT&CK version, the cyber range build, the test dates and the telemetry sources used. Keep the expected event tables, the match outcomes and the false positive dispositions in the same record so an auditor or a new engineer can reconstruct the validation. Store the record where change control can see it. The step is done when a versioned validation record exists and links to the exact rule that was tested.
Record gaps and reopen the detection backlog
Review every missed test, unresolved false positive and telemetry gap with the detection, logging and identity owners, and turn each into a tracked backlog item with an owner and a priority. Confirm the mitigations the team relies on, such as User Account Management and Audit, are implemented and evidenced for the platforms in scope, and add any missing items to the same backlog. Re-run the validation after each change and record the new rule version. The step is done when every gap has a tracked item, no open item is unowned, and the detection is marked as validated only for the versions and platforms that passed.
Mitigations for T1606: User Account Management and Audit
The two ATT&CK mitigations address the conditions that make a forged web credential useful to an adversary: the forged session must still be accepted, and the defender must be able to see it being used. The three supporting controls cover the response and key management steps that determine how quickly a suspected forgery can be cut off. Confirm each one in your own environment, because product behavior varies.
User account management (M1018)
Account lifecycle, session lifetime and privileged access in the identity provider decide how long a forged credential stays useful. Disable accounts promptly when people leave or change roles, set session and refresh token lifetimes short enough that a stolen session expires quickly, and limit administrator roles to named people who need them. For T1606, check whether a password reset or account disablement also ends existing sessions. If it does not, a forged or stolen web credential may keep working after the account owner has responded.
Audit (M1047)
Enable and retain sign-in, token issuance and role change logs from each SaaS application and the identity provider, then forward them to the SIEM. Detection of forged web credentials depends on seeing authentication events, new sessions and privilege changes with user, source address and client details. Ask each vendor which log categories are available on your plan, whether they can be exported in near real time, and how long they are kept. Confirm retention against your own policy and any regulatory obligations, then test in the cyber range that a simulated forged session produces a log entry you can query.
Session revocation runbook
Document how to end all active sessions and refresh tokens for an account, and who is allowed to do it. The runbook must name each console or API call used, the SaaS applications that keep their own sessions, and the step that rotates any application secret the account could use. Rehearse it in the cyber range so the on-call team knows the steps and how long they take in your environment. Ask vendors whether revocation reaches every connected application or only the identity provider session.
Token signing key management
Limit who can read and use token signing keys, store them in a managed key service or hardware-backed module where the platform supports it, and rotate them on a schedule and after any suspected exposure. A forged token that validates against a trusted key is hard to distinguish from a legitimate one, so key access logs and rotation records matter. Confirm with each vendor how rotation affects active sessions and whether old keys can be retired without a service outage.
Integration and API credential inventory
Keep an inventory of OAuth grants, API keys and service accounts connected to each SaaS tenant, with an owner and a review date for each. Forged web credentials often succeed through an integration that nobody reviews, so unused grants should be revoked and high-privilege tokens scoped down. Ask each platform whether it can list grants and last-use times through an administrative interface or API, and export that list into your access review process.
Triage and response when a forged credential alert fires
The first decision is whether the alert reflects a real session anomaly or a known false positive. Compare the flagged session against the identity's recent behavior: source address, user agent, device, token issuance time and the application it was used against. Check whether a scheduled job, a new VPN egress, a sanctioned browser update or a migration explains the event. Record the answer in the ticket before taking containment steps, because a rushed revocation of a legitimate integration can cause its own outage. Identify the affected account and the application that accepted the session, and note whether the identity holds administrative or API-level rights in that application.
If the anomaly cannot be explained, revoke active sessions and refresh or access tokens for that identity in the identity provider and in the affected SaaS application, then force re-authentication. Review the identity provider for recent configuration or signing key changes, new federation trusts, altered token lifetimes and recently added application registrations, since a forged credential is only useful if the trust chain accepts it. Where cookie or token stores on an endpoint are in scope, use Velociraptor to collect browser profile and application token artifacts from the suspect host under your documented collection procedure, and hash and preserve them before any cleanup. Export and preserve the SaaS audit logs for the account and the window around the alert now, because retention windows and log export limits differ by vendor and are easy to miss. Confirm those limits with each provider.
Escalate to incident response as soon as the anomaly is confirmed as unexplained, or when the affected identity is privileged, when a signing key or federation setting changed without a change record, or when the same pattern appears on more than one account. The incident commander should own the timeline and the evidence chain. Tell the account owner what happened in plain terms: their session was ended, they will need to sign in again, whether their password or multi-factor method needs resetting, and what they should report if they see unfamiliar activity. Avoid speculating about the cause until the evidence supports it, and give them a named contact for follow-up questions.
Rehearsing T1606 forge web credentials in a private cyber range
This tab covers the range built around a sample identity provider, a sample SaaS application and a log pipeline. Forged web credentials are most visible here as session activity that does not match the account's normal pattern, so the range needs authentication logs and application logs flowing into the same pipeline. The blue team works from the identity and application records, not from endpoint artifacts.
- Range topology: a sample identity provider, a sample SaaS or web application with its own audit log, and a log pipeline built on Wazuh or Security Onion that ingests both sources.
- Injects: general scenarios in which a session token or web credential appears to be used from an unexpected network location, or in which an account performs actions outside its role.
- Good detection: an alert raised within the agreed exercise window, naming the correct account, application and source context rather than only a generic host.
- Good response: session revocation for the affected account, preservation of authentication and application logs with their timestamps, and a lessons-learned entry recording which signal fired first.
Confirm with your team which identity platform and audit log retention apply to your environment before the exercise plan is finalized.
This tab uses managed Windows and macOS endpoints enrolled with the range's endpoint agents. The focus is on whether local activity linked to web credential handling is recorded and whether the alert carries enough host and account context to act on. Emulation stays at the level of described behavior, with no commands or tooling detail in the exercise plan.
- Range topology: Windows and macOS endpoint agents reporting to the same log pipeline as the identity provider, with file and process telemetry enabled according to the agreed scope.
- Injects: general scenarios in which a user's browser profile or credential material is touched by an unexpected process, followed by web sign-ins from that user's account.
- Good detection: the correlated alert identifies both the endpoint and the account, and it arrives in time for the responders to act within the exercise window.
- Good response: isolation of the affected host where the scenario calls for it, password and session resets for the impacted account, and preservation of endpoint evidence before any cleanup.
- Lessons logged: whether file access telemetry was present for the relevant paths on each operating system, since macOS and Windows often differ in coverage.
Ask your endpoint team to confirm which audit policies and agent versions are deployed before any scenario is run.
This tab covers Linux servers and workstations in the range, where web credentials are often held in application configuration, service accounts or browser profiles on shared systems. The blue team needs to see whether file access on those locations is logged and whether the alert ties the activity to a specific account and host. The range should include both interactive and service-account scenarios.
- Range topology: Linux hosts with Wazuh agents or Security Onion sensors, a log pipeline receiving file and authentication records, and a sample web application whose login events feed the same platform.
- Injects: general scenarios in which a service or user account begins authenticating to a web application from a host where that account does not normally operate.
- Good detection: an alert that names the host, the local account and the web account involved, with timing that lets responders establish the sequence of events.
- Good response: credential rotation for both the local and web accounts, revocation of active sessions, and capture of relevant logs and file metadata before systems are changed.
- Lessons logged: any gaps in file integrity monitoring coverage on the paths the scenario touched, and the owner responsible for closing each gap.
Confirm with your platform team which Linux distributions and log retention settings are in scope before scheduling the exercise.
Questions SOC leads and detection engineers ask about T1606
How can I tell a forged token from a legitimate token refresh?
No single field settles it, so judge the token against its history. A legitimate refresh should trace back to an earlier authentication event for the same session, client application and device. Look for refresh activity with no originating sign-in, token use from a new network, user agent or autonomous system, scope or lifetime changes that the application does not normally request, and token use after a password reset or session revocation. Where your logs allow it, check issuer and signature details on the resource side. Build the rule as a correlation across identity and resource events, and baseline each application separately. Confirm with each SaaS and identity vendor which token, client and session fields its logs record, because those fields determine what you can correlate.
Are SaaS audit logs enough without endpoint telemetry?
For many forged-token cases, SaaS and identity provider logs carry the strongest signals, because the suspicious activity appears against the provider's sign-in, token and API surfaces. Endpoint telemetry becomes necessary when the forged material was created or stored on a managed host, or when a session was taken from a browser. Confirm what each audit log records, including token issuance, grant type, client identifier, source address, device and retention period. Gaps usually appear around where a token was minted, which is the part that matters most. Decide which detections depend on endpoint data, document the accepted coverage gap in writing, and have the risk owner sign off on it.
Which logs should we retain first for web credential detection?
Start with the sources that record how tokens and sessions are issued and used. In practice, that means:
- Identity provider sign-in and token events, including refresh and revocation events
- SaaS admin and audit logs, including changes to applications, consents and API clients
- API or gateway access logs from resource servers, with client identifiers and source addresses
- Key and certificate management events, if your platform signs tokens with managed keys
Set retention periods with your compliance lead, since obligations come from your own policy and applicable regulation. Then check which data components the detection strategies for your target techniques reference in the enterprise-attack 20.0 STIX bundle, so retention follows what the detections need.
How should we tune detections for service accounts and mobile clients?
Tune by identity class and behavior, not by suppressing alerts wholesale. Service accounts behave predictably, so baseline their source addresses, scopes, token lifetimes and call patterns, then alert on deviations from that baseline. Mobile clients move between networks and run many app and operating system versions, so key on the registered client and device identifier, expect address changes, and alert when the device and client pairing changes. Keep every exclusion time-bound, written down and reviewed with the owning team. Test each tuning change against recorded benign traffic in your cyber range before it reaches production, so you can see what the change would have hidden.
How do we map detections to ATT&CK 20.0 and handle future versions?
Record the ATT&CK version in every rule and mapping. This page targets Enterprise ATT&CK 20.0, which MITRE released on 2026-10-13. Pull technique, sub-technique and detection strategy references from the enterprise-attack 20.0 STIX bundle, not from copied web pages, so the mapping stays machine-checkable. Each release can rename, deprecate or revoke techniques, so read the ATT&CK updates page when a new version ships and diff the bundle against your current mapping. Re-verify any rule that touches the T1606 sub-techniques, and keep a version field in your mapping table so older coverage claims stay accurate.
How often should we rerun detection validation for web credentials?
Rerun validation after any change that could alter what the detection sees, and on a fixed schedule that your risk owner approves and records. Triggers include changes to identity provider configuration, SaaS upgrades, log source changes, new ATT&CK versions and major rule tuning. Use the cyber range to replay recorded simulation traffic against the current rule version, and log each run with the date, rule version, expected result and actual result. Keep the schedule in your control documentation so auditors can see it operating. If you want the work run continuously, DeployOpen offers retainers for continuous testing, and the scope, frequency and deliverables would be agreed in writing first.
How DeployOpen builds T1606 detections and range scenarios
DeployOpen approaches T1606 Forge web credentials as a fixed-scope engagement inside the client's own environment, covering the parent technique and its two sub-techniques. The work turns telemetry from File Access, Process Access and Network Traffic Content into detections that are tested in a private cyber range before they reach production.
How we scope
- Agree in writing which platforms, SaaS applications and identity sources are in scope for T1606 detection.
- Confirm which ATT&CK version the detection mappings will target, such as v20, and record it in the scope.
- Inventory the logs for web authentication and token-related activity that the client can actually forward into its SIEM.
How we build
- Write detection logic for T1606 sub-techniques in Sigma and map it to the data components used by Wazuh, Security Onion or Zeek.
- Build collection and parsing for File Access, Process Access and Network Traffic Content sources in the client's stack.
- Test each detection in a private cyber range with replayed adversary-like activity, recording what fires and what does not.
How we hand over
- Deliver the detection rules, field mappings, tuning notes and a validation log tied to the agreed ATT&CK version.
- Document the mitigation work for User Account Management and Audit so the client can show how each control was configured.
- Train the client's analysts to run the range scenarios and repeat the validation after changes to their environment.
How we support
- Ongoing support, upgrades and continuous testing of T1606 detections are available as a retainer after handover.
- Retesting is scheduled when ATT&CK releases rename, deprecate or revoke techniques that the detections depend on.
- Ask any quote to itemize scope, deliverables and retainer terms so the client can compare them with its own requirements.
