UNC6040 Phoned Staff to Authorise Salesforce Connected Apps

The activity tracked as UNC6040 works like this. Someone calls an employee, presents as IT support, and guides them to a page in their own Salesforce environment where connected applications are approved. The employee is asked to enter a connection code the caller supplies.

The code authorises an application the attacker controls. In observed cases that application impersonated a legitimate data-loading tool and requested broad scopes, including full API access and the ability to issue refresh tokens.

This is not a vulnerability, and it is important to say so plainly rather than reaching for the word. Device authorisation exists because some clients cannot present a login form — a television, a command-line tool, a device with no browser. The user authenticates elsewhere and confirms a short code.

Every step performs its designed function. The user is genuinely authenticated. The code genuinely corresponds to the pending request. The consent screen genuinely lists the scopes. The system’s only error is believing the human understood what they were approving.

A session ends. A refresh token does not, in any practical sense: it survives password changes, it is not re-checked against a second factor, and it revokes only if somebody goes looking for it in an administrative console.

That is why the phone call is worth the effort. Five minutes of social engineering converts into durable programmatic access that generates no further authentication events, and appears in logs as an approved integration doing what integrations do.

Restricting which connected applications may be authorised at all, and by whom, removes the decision from the person on the phone. Alerting on new connected-app authorisation gives a detection point that does not rely on anyone noticing the volume later. Neither is difficult; both are commonly left at the permissive default.