A sign-in response URL can contain an authorization code. Sharing it can expose part of an authorization exchange; successful redemption depends on the client, flow, and applicable protections. Keep the code transfer, token issuance, and resource access as separate findings.
An address copied from the browser after sign-in may contain part of the authorization exchange. A request to share it can expose sensitive material, even when the sign-in itself used Microsoft’s real website.
Before sharing the URL, ask who requested it, what it contains, and where it will go. A real identity-provider page can still be part of a deceptive workflow.
What the reported attacks asked people to do
Push Security’s December 11, 2025 ConsentFix report describes a campaign in which compromised websites displayed a fake verification step. A genuine Microsoft sign-in led to a localhost response URL containing an authorization code. The victim was asked to paste that URL into the original page. Push described abuse of the Azure CLI application in this observed variant. An existing Microsoft session could remove the need to enter credentials again. Push: original ConsentFix investigation
The person transfers a sign-in response to the requester. A code in that response is not an ordinary registration reference and is not the same thing as an access token.
Volexity’s December 4, 2025 reporting describes a related manual handoff in conference-themed attacks attributed by that company to UTA0355. In one investigated incident, the attacker used an existing email thread and WhatsApp communication, then asked for the resulting browser URL. Volexity observed subsequent Microsoft 365 file access. The report also covers separate device-code workflows; do not combine every case into one protocol diagram. Volexity: Dangerous Invitations
Push’s January 2026 follow-up described its campaign as appearing linked to APT29. That is the researcher’s attribution assessment. This article does not equate all actors using URL-sharing lures or assume an identical client configuration across their campaigns. Push: ConsentFix debrief
Four things that should not be called the same token
An authorization code is an intermediate value issued in an authorization-code flow. The client submits it to a token endpoint as part of a redemption request. An access token is the resulting credential used for an authorized resource request. A refresh token, when issued, supports obtaining further access tokens. A session cookie can maintain the browser’s signed-in session with a service. Our tokens and session cookies explainer introduces those roles.
Microsoft’s authorization-code documentation separates the browser response from token redemption and the subsequent token response. It also distinguishes public clients from confidential clients and documents the verifier required when PKCE was used. These details matter when interpreting a copied URL. Microsoft: authorization-code flow
When investigating, ask which service issued the value, which exchange it belongs to, who received it, and what happened next. Its appearance alone will not tell you. If the contents are uncertain, handle the URL as potentially sensitive and let the identity team classify it through the approved process.
Do not paste the original into a public decoder or a general chat channel. A request for help should communicate the sequence without giving more people the very material under investigation. The response team can arrange restricted collection when it needs the original artifact.
Public client does not mean any copied code will work
A desktop or native application cannot reliably keep a shared client secret confidential in the way a server-side application can. That distinction explains why a public-client exchange differs from a confidential-client exchange. It does not eliminate all other requirements on code redemption.
PKCE, pronounced “pixy,” stands for Proof Key for Code Exchange. It associates the authorization request with a verifier used in the later redemption step. RFC 7636 describes its protection against authorization-code interception: possessing the intercepted code is insufficient when the required verifier is missing. RFC 7636, sections 1 and 4
A public client’s code alone does not always yield tokens. Inspect the actual flow and relevant protections. In a case involving an attacker-arranged authorization request, also establish who controlled that request and any verifier; the mere presence of PKCE is not evidence that a trusted client initiated the transaction. That is a question for the investigation, not a conclusion to infer from the phishing label.
The diagram separates disclosure, redemption and resource access. The reported ConsentFix variant does not establish how every Microsoft client or OAuth deployment behaves.
Conceptual evidence map; success is conditional
- Browser response
Contains an authorization code. A code is not an access token.
- Person shares the response
The requester receives the copied value. This establishes only the handoff.
- Redemption attempt
A client submits the code. Applicable client and PKCE checks must pass; retain the result.
If accepted
- Token issuance
Tokens return to the requesting client.
- Resource operation
The client sends a token-bearing request. The resource checks it and returns a result; record the operation.
Shared response, issued token, and completed data access are different findings.
Which action did the employee take?
Our device-code phishing explainer follows a client waiting for authorization while the person enters a user code. Here the person exports an authorization response from the browser. Mixing those arrows would conceal the action the employee needs to recognize.
Our consent-phishing article asks what authority an app approval permits. That remains useful context, but an analyst should not require a newly displayed consent screen to recognize every code-handoff case. Investigate the actual application’s authorization path.
Our ClickFix article follows copied instructions into an operating-system execution context. The handoff described here can remain in browser and messaging interactions. Finding no command execution does not settle whether a sign-in response was disclosed.
These distinctions make an incident interview more useful. Ask “what did you copy, and where did you put it?” rather than choosing a campaign label first and fitting every later answer to it.
What happened after the URL was shared?
A message containing an authorization response can establish disclosure. A successful sign-in record describes authentication. Neither, alone, establishes that another client redeemed the code. Correlated redemption and resource records are needed to follow the chain further.
A rejected redemption supports a conclusion about that request. It does not establish that the employee withheld the response or that every client configuration has the same protection. A successful read similarly supports the named operation, rather than unrestricted access to the account.
Connect the conversation to the token and resource records
Separate five questions in the incident record: the requested task, the response disclosure, redemption, resource activity, and response actions. For each, record the artifact, time, owner, association with the case, and remaining uncertainty.
Start with the conversation because it explains the requested behavior. Then establish the identity-provider event and application context. Where available, associate later token and resource records using actual identifiers and documented logging behavior. Time proximity alone may help form a hypothesis, but it is weaker than an explicit transaction relationship.
The employee’s location is also an incomplete shortcut. A real sign-in performed by that employee can have an unsurprising origin even when the surrounding request is deceptive. Conversely, an unusual network origin in another record deserves investigation rather than immediate attribution. Record what each event represents before comparing their addresses.
Logs differ by service and configuration. Ask the administrator which logs exist, what they retain, and which stages they actually describe. Missing records should stay visible in the conclusion.
For example, “the employee shared the response at approximately 10:05; redemption remains unverified because the relevant records are unavailable” is a useful statement. It gives the incident owner a next action and makes the limit explicit. Calling the same evidence a confirmed full-account takeover would obscure that work.
Give the employee a response they can use
A person should not need to identify a grant type before asking for help. A useful report is: “This registration or support process asked me to share the address shown after sign-in.” Include the original request, approximate time, service name, and whether anything was already shared. Use the organization’s reporting route and avoid forwarding the full response URL broadly.
For a legitimate support issue, the support owner can specify a safe diagnostic artifact and an approved destination. Our HAR-file review guide explains the separate review needed when troubleshooting material itself can contain sensitive information.
If a response was already sent, involve the identity and incident teams promptly. They can assess affected sessions, applications, resource activity, and appropriate containment. A password change is one possible account action; it is not evidence that every token or session in the case has been addressed. Keep those checks in the containment review.
Technical validation has a separate scope from an employee reporting exercise. The technical follow-on test guide covers authorization, test identities, permitted operations, and cleanup.
