A new hire’s account signed into the corporate VPN hour after hour at exactly 26 seconds past the first minute. The punctuality is the confession: humans are never that precise. The work was being done from Belarus, and the US presence was a script.
For eighteen days, the account of a newly hired remote IT worker behaved like two people, and nothing escalated: Okta scored every sign-on MEDIUM risk and let them all through. Detection never had a chance, because an account compromised from day one has no clean baseline to deviate from. What broke the case was human: the new hire’s manager could not shake the feeling that something was off, and an analyst pasted that suspicion into Artemis AI Mode, which turned weeks of instinct into a confirmed case in a single investigation. Work that would have taken an analyst days of pivoting across a month of identity logs came back in minutes.
The account that never had a baseline
Anomaly detection assumes a baseline to violate: months of clean history, then the break. This account had no history to break. A US device fingerprint appeared on June 1, the first day the account was observed, connecting through the corporate VPN. On June 2, one day later, a second device appeared from a Belarus IP behind an anonymous proxy, authenticated with a password and a security question, and completed full SSO into Office 365.
That day-two timing is itself a finding. An account takeover looks like a long stable pattern followed by a sudden foreign intrusion. Foreign access inside the first 48 hours of an account’s observed life is a different creature: an identity operated from abroad from the start. Also from the start, no real hardware. The account’s only registered corporate device was a Windows 365 Cloud PC, a virtual desktop rented in a US datacenter, sitting non-compliant in device management with no EDR agent behind it. Two and a half weeks into the job, the company’s endpoint security had never once met this employee, because there was no employee machine to meet. Hold that thought: a virtual desktop in a US datacenter is also how you give a US body to someone who has never been in the US.
Seventeen minutes and twenty-seven seconds
On June 19 the account produced the pair of events that settles the two-operator question on physics alone:
| Event time (UTC) | Event | Source | Device fingerprint |
|---|---|---|---|
| 02:43:56 | user.session.start | Belarus (residential exit) | ef35o7uz… (the Belarus device) |
| 03:01:23 | user.session.start | United States (residential exit) | 3gq1wwgu… (the US device) |
The gap is 17 minutes and 27 seconds. No VPN-reconnection story explains it either: the two sessions ride different device fingerprints, each with weeks of consistent geographic history. Two devices, two places, one account, seventeen minutes apart. That is two people, or one person plus a machine. It turned out to be both.
The metronome
While the two “operators” traded places, the corporate VPN exit kept its own schedule. Across that day, fifteen of seventeen hourly logins from it landed at exactly 26 seconds past the first minute of the hour:
05:01:26 06:01:26 07:01:26 08:01:26 09:01:26 10:01:26
11:01:26 12:01:26 14:01:26 15:01:26 16:01:26 18:01:26 19:01:26
Code language: CSS (css)Humans do not do this. Cron does this. The pattern is a scripted keepalive: keep the account continuously alive on a US corporate VPN, so that anyone glancing at the identity logs sees an employee at work during US business hours. And the VPN exit is shared infrastructure carrying over a hundred real employees, which is exactly what makes it good camouflage: one scripted session per hour disappears into legitimate traffic. Each of these sessions triggered anomalous-device or anomalous-location risk flags. Each completed successfully anyway.
The cryptographic tell
The strongest evidence in the case is not behavioral but cryptographic. Over 30 days, the account’s MFA record splits perfectly along geography:
| Source | MFA factors observed | Phishing-resistant? |
|---|---|---|
| Corporate VPN and secondary US IP | SIGNED_NONCE (Okta FastPass, device-bound) | Yes: hardware-anchored |
| Belarus IP | Password, security question | No: knowledge factors, the weakest available |
| Russia IP | Okta Verify push from an Android emulator | Not device-bound |
Every device-bound authentication in the window came from US sessions. Zero came from Belarus. A FastPass credential is anchored to a hardware-backed private key on a specific physical device; it cannot be produced without holding that device. The Belarus operator fell back every single time to the two weakest factors available: things a person can be told. The factor mix is a map of who holds what. The hardware lives with the US cover presence. The person doing the work has only knowledge, and knowledge can be shipped across a border.
One more MFA artifact rounds it out. On June 16, an Okta Verify push for the account was approved from a Russian IP. Okta’s own record carries the tell in a single field:
{
"eventType": "user.authentication.auth_via_mfa",
"client": {
"geographicalContext": { "country": "Russia" },
"userAgent": { "os": "Android",
"rawUserAgent": ".../okta.android.auth Android/16 Google/sdk_gphone64_x86_64 ..." }
},
"securityContext": { "risk": { "level": "MEDIUM", "reasons": ["Anomalous Device"] } },
"debugContext": { "debugData": { "factor": "OKTA_VERIFY_PUSH" } }
}
Code language: JSON / JSON with Comments (json)sdk_gphone64_x86_64 is the default device name of the Android Studio emulator. A Verify factor for a US employee living on emulated Android infrastructure in Russia is not a corner case any legitimate workflow produces. That same day the account authenticated from three countries (the US, Belarus, and Russia), each sign-on flagged MEDIUM, each successful.
Ruling out the boring explanations
A foreign IP on a corporate account has innocent explanations: shared VPN infrastructure, a travel gateway, a misattributed range. The investigation closed each one with an exclusivity check across the whole org:
| Source | Location | Org-wide users | This account’s events | Everyone else’s |
|---|---|---|---|---|
| Belarus residential exit | Belarus | 1 (this account) | Hundreds | 0 |
| US residential exit | United States | 1 (this account) | Hundreds | 0 |
| Corporate VPN exit | United States | Well over a hundred distinct users | Hundreds | Tens of thousands |
The Belarus IP and the secondary US IP were each used by exactly one identity in the entire company, hundreds of times. These are the operators’ personal connections, and the exclusivity removes every benign infrastructure explanation at once.
The blast radius
This was not a dormant test account. Through a broad set of group memberships, its SSO grants reached the company’s HR, payroll, and expense systems, and the Belarus sessions used Office 365: mail, documents, SharePoint. All of it reachable by an identity whose actual operator was never the person the company believed it hired, with no endpoint telemetry anywhere in the stack.
| Date / time (UTC) | What happened | ATT&CK |
|---|---|---|
| June 1 | Account first active; US device fingerprint appears via corporate VPN. Only registered device: a non-compliant cloud-hosted virtual desktop, no EDR behind it | T1078.004 |
| June 2 | Belarus device appears via anonymous proxy, authenticates with password + security question, completes SSO to Office 365 | T1090 · T1078.004 |
| June 16 | Sign-ons from three countries (US, Belarus, Russia) in a short window, each flagged MEDIUM, each successful | T1078.004 |
| June 16, 18:01:50 | Okta Verify push approved from a Russian IP on an Android emulator | T1098.005 · T1621 |
| June 19, 02:43:56 | Belarus session starts | T1078.004 |
| June 19, 03:01:23 | US session starts, 17m27s later: two concurrent operators | T1078.004 |
| June 19, through the day | Corporate-VPN keepalive logins at a fixed :01:26 second, fifteen of seventeen hours that day | T1078 |
| Jun 19, 19:09 | The manager’s suspicion reaches an analyst, who opens Artemis AI Mode; the full scheme is reconstructed and a case opens. The detection point. | — |
| Jun 20, 18:07 | Account deactivated; application access cascaded off | — |
Why nothing fired
Every fragment of this scheme was in the logs, some of it for eighteen days. Walk the stack and count what each layer could see.
Okta’s risk engine flagged the anomalous sign-ons MEDIUM, and every one completed, because a valid password and a valid factor were presented. A risk engine scores one login at a time; it has no concept of a month of logins forming an employment-fraud hypothesis, and MEDIUM events on an account that keeps authenticating read as noise.
IP reputation cleared the Belarus address entirely. No proxy, VPN, or Tor markers in threat intelligence, and commercial geolocation providers could not even agree which country the address was in: one major service placed it in the United States. A blocklist rule has nothing to match on an address the industry itself scores benign.
EDR was blind by construction. Endpoint detection presumes an endpoint; a worker operating through a cloud-hosted virtual desktop and personal, unmanaged devices never generates a single event in it. The absence itself, an active employee whose only device is a non-compliant virtual desktop, is a signal almost nobody alerts on.
And the initial access vector was the hiring process. The identity was issued, provisioned into a broad set of groups, and granted HR-system and O365 access through entirely legitimate onboarding. There is no log source for an interview.
How Artemis caught it
What cut through was not a detector but a person. The new hire’s manager had been collecting unease for weeks, none of it a log line: call audio so poor it was borderline inaudible, screen-share latency that felt like a remote desktop session, ever-present virtual backgrounds, foreign-language voices bleeding through the mic once, password lockouts that suggested an unfamiliar keyboard layout, and a story about staying with family in another state for the first few months. Unease like that usually dies in a hallway conversation, because there is nothing to file it against. Here, an analyst pasted the manager’s concern into Artemis AI Mode, and the investigation agent turned it into evidence: it asked the questions a fraud hypothesis demands (concurrency, periodicity, factor asymmetry, IP exclusivity, the account-birth timeline) and answered every one from the customer’s own telemetry, building the case laid out above. The output was a confirmed true-positive case, with immediate guidance to deactivate the account, revoke sessions, inventory everything the sessions had reached, and take the question of who was actually hired back to HR. The next day, the account was deactivated and its application access cascaded off.
The pattern behind the incident
Fraudulent remote workers are an identity problem the SOC inherits from the hiring pipeline. By the time the scheme is running, every conventional signal has been legitimized: real credentials, real MFA, real access, all issued on purpose.
What survives are three tells that do not depend on history. Physics: two session starts closer together than any human could travel. Mechanics: timing too regular to be a person. Cryptography: device-bound factors that cannot be produced without the hardware, splitting cleanly along a geographic line. None requires new telemetry; all three were in standard Okta system logs the company already collected. They require an investigator willing to hold a month of events in one hypothesis, which is exactly the work that never happens when each event arrives as a separate MEDIUM. In this case the first detector was a human who felt the latency on a video call. What made the difference is that the suspicion finally had somewhere to go.
For defenders
Four things you can act on today, whatever you run:
- Hunt MFA factor asymmetry by source. Group each identity’s successful factors by source IP and geography. An account that presents device-bound factors from one location and only knowledge-based factors from another is being operated by more than one party. Zero phishing-resistant factors from an IP that signs in daily is a question that needs an answer.
- Hunt mechanical timing. Aggregate session starts per identity by second-of-hour. Humans jitter; scripts do not. A fixed :MM:SS recurring across hours is automation on the account, and if you didn’t put it there, someone else did.
- Treat active SSO plus zero endpoint enrollment as a standing violation. An employee with live access to HR and payroll systems and no managed device in MDM or EDR should page someone, especially in the first 90 days, and a new hire whose only device is a cloud-hosted virtual desktop belongs in the same queue.
- Run a new-hire identity review around day 30. For each new account: device fingerprints and their management status, source geographies and proxy/VPN classifications, factor mix per location, and group memberships against role. Review new identities against the org and the role, not against their own two weeks of history. Pair it with the verify-the-worker hiring controls in the CISA and FBI advisories on DPRK IT-worker schemes.
Detection as a prompt
No single event says “this employee is two people”; the proof is an intersection, and all of it lives in identity logs alone. Artemis expresses threat hunts as instructions to an investigation agent rather than as static rules, which is what let one analyst question become a full reconstruction. If you run an agentic investigation tool, the same idea ports directly. A prompt that would have surfaced this scheme:
Role: fraudulent-worker triage over the org's own logs
(IdP/SSO sign-on + factor events, VPN, MDM/EDR inventory, HR directory).
Trigger: an account under 90 days old with sign-ons from foreign or
anonymizing infrastructure; OR MFA factor types that differ by source
IP; OR session starts recurring at a fixed second past the hour.
Investigate, in order, and report what you find at each step:
1. Concurrency. Compute the minimum time gap between session starts
from geographically distant IPs. Compare against minimum travel
time. Distinct device fingerprints on each side make the two-
operator conclusion stronger; state it.
2. Periodicity. Distribution of session-start minute:second per
source IP. Sub-second consistency across consecutive hours is
automation; identify which IP carries it and what it masks.
3. Factor asymmetry. For each source IP/geo: which MFA factor types
succeed there? Device-bound factors from one geography and only
knowledge factors from another means the operators do not share
hardware. State who can hold the enrolled device.
4. Exclusivity. For each suspect IP: how many org identities have
ever used it? An IP exclusive to one account, hundreds of events,
is a personal operator connection, not infrastructure.
5. Birth timeline. When was each device fingerprint first seen,
relative to account creation? Foreign access within the first days
of an account's life is fraud-from-hire, not takeover. Check MDM/
EDR enrollment: does any managed device exist for this user at all?
6. Blast radius. Group memberships, SSO app access (HR, finance,
payroll), and what each geography's sessions actually reached.
Recommend immediate deactivation and an HR identity verification
if two operators are established.
Do not treat passed MFA, corporate-VPN presence, or an ACTIVE directory
status as exoneration. The question is how many humans the evidence
requires, and whether any of them is the person the company hired.
Code language: PHP (php)Drawn from real findings in a customer environment; details anonymized and indicators sanitized.
