{
	"id": "3098b0df-07f4-4511-9865-e8119df1d23c",
	"created_at": "2026-04-06T00:12:16.049382Z",
	"updated_at": "2026-04-10T03:21:06.313874Z",
	"deleted_at": null,
	"sha1_hash": "24638fd2b3c90d1007fc321581c0a5f00665f4bd",
	"title": "Cross-Tenant Impersonation: Prevention and Detection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 62250,
	"plain_text": "Cross-Tenant Impersonation: Prevention and Detection\r\nBy Defensive Cyber Operations\r\nPublished: 2023-08-31 · Archived: 2026-04-05 19:27:55 UTC\r\nSummary\r\nOkta has observed attacks in which a threat actor used social engineering to attain a highly privileged role\r\nin an Okta customer Organization (tenant).\r\nWhen successful, the threat actor demonstrated novel methods of lateral movement and defense evasion.\r\nThese methods are preventable and present several detection opportunities for defenders.\r\nIn recent weeks, multiple US-based Okta customers have reported a consistent pattern of social engineering\r\nattacks against their IT service desk personnel, in which the caller’s strategy was to convince service desk\r\npersonnel to reset all Multi-factor Authentication (MFA) factors enrolled by highly privileged users.\r\nThe attackers then leveraged their compromise of highly privileged Okta Super Administrator accounts to abuse\r\nlegitimate identity federation features that enabled them to impersonate users within the compromised\r\norganization.\r\nTactics, Techniques and Procedures\r\nOkta Security has identified a cluster of activity in which:\r\nThreat actors appeared to either have a) passwords to privileged user accounts or b) be able to manipulate\r\nthe delegated authentication flow via Active Directory (AD) prior to calling the IT service desk at a\r\ntargeted org, requesting a reset of all MFA factors in the target account. In the case of Okta customers, the\r\nthreat actor targeted users assigned with Super Administrator permissions.\r\nThe threat actor would access the compromised account using anonymizing proxy services and an IP and\r\ndevice not previously associated with the user account.\r\nThe compromised Super Administrator accounts were used to assign higher privileges to other accounts,\r\nand/or reset enrolled authenticators in existing administrator accounts. In some cases, the threat actor\r\nremoved second factor requirements from authentication policies.\r\nThe threat actor was observed configuring a second Identity Provider to act as an \"impersonation app\" to\r\naccess applications within the compromised Org on behalf of other users. This second Identity Provider,\r\nalso controlled by the attacker, would act as a “source” IdP in an inbound federation relationship\r\n(sometimes called “Org2Org”) with the target.\r\nhttps://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nPage 1 of 6\n\nFrom this “source” IdP, the threat actor manipulated the username parameter for targeted users in the\r\nsecond “source” Identity Provider to match a real user in the compromised “target” Identity Provider. This\r\nprovided the ability to Single sign-on (SSO) into applications in the target IdP as the targeted user.\r\nWhat is Inbound Federation?\r\nInbound Federation allows access to applications in a target Identity Provider (IdP) if the user has successfully\r\nauthenticated to a source IdP. The feature can also be used for Just-in-time (JIT) provisioning of users. It’s a\r\nfeature that is used to save months off mergers, acquisitions and divestitures. It is also popular with large\r\norganizations (such as global parent companies) that require central controls or globally provision one set of\r\napplications (while also empowering divisions to have some level of autonomy for their own policies and apps).\r\nGiven how powerful this is, access to create or modify an Identity Provider is limited to users with the highest\r\npermissions in an Okta organization - Super Administrator or Org Administrator. It can also be delegated to a\r\nCustom Admin Role to reduce the number of Super Administrator’s required in large, complex environments.\r\nThese recent attacks highlight why protecting access to highly privileged accounts is so essential.\r\nPrevention\r\nBased on our analysis of this intrusion, we recommend Okta customers implement our industry-leading, phishing-resistant methods for enrollment, authentication and recovery; restrict the use of highly privileged accounts, and\r\napply dedicated access policies for administrative users and monitor and investigate anomalous use of functions\r\nreserved for privileged users.\r\nA more detailed set of recommendations is listed below:\r\nProtect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2\r\nWebAuthn.\r\nEnable Protected Actions (under Settings \u003e Features) to force re-authentication whenever an\r\nadministrative user attempts to perform sensitive actions.\r\nConfigure Authentication Policies (Application Sign-on Policies) for access to privileged applications,\r\nincluding the Admin Console, to require re-authentication “at every sign-in”.\r\nIf using self-service recovery, initiate recovery with the strongest available authenticator, and limit\r\nrecovery flows to trusted networks (by IP, ASN or geolocation).\r\nReview and consolidate the use of Remote Management and Monitoring (RMM) tools by help desk\r\npersonnel, and block execution of all other RMM tools.\r\nStrengthen help desk identity verification processes using visual verification.\r\nTurn on and test New Device and Suspicious Activity end-user notifications.\r\nhttps://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nPage 2 of 6\n\nTake a \"Zero Standing Privileges\" approach to administrative access. Assign administrators Custom Admin\r\nRoles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles.\r\nConstrain custom help desk roles with resource sets that exclude groups of highly privileged\r\nadministrators.\r\nEnforce dedicated admin policies - Assign all administrators to groups. Require users in these groups to\r\nsign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict\r\nthis access to trusted Network Zones and deny access from anonymizing proxies.\r\nApply ASN and IP Session Binding (from Settings \u003e Features) to all administrative apps to prevent the\r\nreplay of stolen administrative sessions.\r\nDetection and Response\r\nThe following System Log events and Workflows templates can be adapted to detect several of the TTPs listed\r\nabove.\r\nStage of\r\nAttack\r\nSystem Log Query\r\nWorkflows Templates/Further\r\nAdvice\r\nDetect AiTM\r\nphishing\r\nusing\r\nFastPass\r\neventType eq \"user.authentication.auth_via_mfa\"\r\nAND result eq \"FAILURE\" AND outcome.reason eq\r\n\"FastPass declined phishing attempt\"\r\nMonitor Unsuccessful Phishing\r\nAttempts\r\nUser Denied\r\nAccess due to\r\nASN/IP\r\nSession\r\nBinding\r\neventType eq \"security.session.detect_client_roaming\" Support article\r\nAlert on\r\nFactor Resets\r\neventType eq \"user.mfa.factor.reset_all\"\r\nTrigger Notifications when All\r\nMFA Factors are Reset\r\nAlert on\r\nFactor\r\nDowngrades\r\nThere is no System Log event for a Factor downgrade.\r\nTo monitor all activation and deactivation events, use\r\nthe following query: eventType sw\r\nTracking and Alerting for\r\nPossible Account Takeover\r\nEvents\r\nhttps://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nPage 3 of 6\n\n\"system.mfa.factor\"\r\nAlert on User\r\nSuspicious\r\nActivity\r\nReports\r\neventType eq\r\n\"user.account.report_suspicious_activity_by_enduser\"\r\nSuspicious Activity Reported\r\nAlert on New\r\nBehaviors\r\nduring Access\r\nto Okta\r\nAdmin\r\nConsole\r\neventType eq \"policy.evaluate_sign_on\" and\r\ntarget.displayName eq \"Okta Admin Console\" and\r\ndebugContext.debugData.behaviors co \"POSITIVE\"\r\nand\r\neventType eq \"policy.evaluate_sign_on\" and\r\ntarget.displayName eq \"Okta Admin Console\" and\r\ndebugContext.debugData.LogOnlySecurityData co\r\n\"POSITIVE\"\r\nWe recommend administrators\r\nuse Expression Language to alert\r\non access to the Admin Console\r\nfrom users that meet the\r\nfollowing conditions:\r\nsecurity.behaviors.contains('New\r\nIP') \u0026\u0026\r\nsecurity.behaviors.contains('New\r\nDevice')\r\nAlert on Sign-In Attempts\r\nvia\r\nAnonymizing\r\nProxies\r\neventType eq \"user.session.start\"\r\nand\r\nsecurityContext.isProxy eq \"true\"\r\nWe recommend administrators\r\ndeny sign-ins from these services\r\nin policy using a Dynamic\r\nNetwork Zone.\r\nAlert on\r\nCreation of an\r\nIdentity\r\nProvider by a\r\nSuper\r\nAdministrator\r\nor Org\r\nAdministrator\r\neventType eq \"system.idp.lifecycle.create\" Alternative\r\nthat includes all creation and modification events:\r\neventType sw \"system.idp.lifecycle\"\r\nWe recommend delegating access\r\nto this feature to a Custom\r\nAdmin Role with the minimum\r\nrequired permissions.\r\nAlert on Sign-In Events via\r\na Third-Party\r\nIdentity\r\nProvider\r\neventType eq \"user.authentication.auth_via_IDP\"\r\nWe recommend alerting on these\r\nevents if the organization does\r\nnot currently use the Inbound\r\nFederation feature.\r\nhttps://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nPage 4 of 6\n\nIndicators of Compromise\r\nFor the period 2023-07-29 to 2023-08-19\r\nIP addresses:\r\nIP\r\n24.189.245.79\r\n74.105.157.5\r\n174.199.192.95\r\n98.113.77.43\r\n108.21.89.22\r\n75.252.4.33\r\n73.205.234.246\r\n99.25.84.9\r\n185.56.83.225\r\n96.244.225.43\r\nChange Log\r\n1.2 - Mar 8, 2024\r\nUpdated recommendations to include new features released as part of Okta Secure Identity Commitment:\r\nProtected Actions, ASN/IP Session Binding.\r\nhttps://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nPage 5 of 6\n\nUpdated detections section to include System Log event for for an authentication failure arising from\r\nsession binding.\r\n1.1 - Sep 9, 2023\r\nUpdated Prevention section to include advice on constraining help desk administrators to specific user\r\ngroups.\r\nUpdated Detection section. While defenders can alert on IdP creation (eventType eq\r\n\"system.idp.lifecycle.create\"), an alternative approach is to alert on any creation or modification using the\r\n\"starts with\" qualifier (eventType sw \"system.idp.lifecycle\")\r\n1.0 - Sep 1, 2023\r\nOriginal Version Published\r\nThe Defensive Cyber Operations (DCO) team is responsible for detecting and responding to cyber threats that\r\nimpact Okta or our customers via the Okta platform. Our intelligence-driven capability identifies the adversaries\r\nmost likely to impact Okta and our customers, and prioritises our defensive capabilities based on the threats most\r\nlikely to be realised.\r\nSource: https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nhttps://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection"
	],
	"report_names": [
		"cross-tenant-impersonation-prevention-and-detection"
	],
	"threat_actors": [],
	"ts_created_at": 1775434336,
	"ts_updated_at": 1775791266,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/24638fd2b3c90d1007fc321581c0a5f00665f4bd.pdf",
		"text": "https://archive.orkl.eu/24638fd2b3c90d1007fc321581c0a5f00665f4bd.txt",
		"img": "https://archive.orkl.eu/24638fd2b3c90d1007fc321581c0a5f00665f4bd.jpg"
	}
}