The load-bearing line in Island's write-up is a short one: an origin-unbound MFA method is used [10]. Origin-unbound means the response the user produces is valid regardless of which page collected it, so a tap in Authenticator or six digits typed into a lookalike form is worth the same to the proxy as it is to Microsoft. That is why the relay order matters. Island describes the proxy passing the password, then Authenticator push approvals or OTPs, then SMS codes, in sequence, to legitimate Microsoft servers in real time [8]. Microsoft then issues the session cookie it would have issued anyway, and the proxy takes it and reuses it before it expires [9]. In Microsoft 365 that can read as an ordinary successful sign-in, without a spike in login failures and without malware execution [11].
The delivery chain is built against reputation rather than against the user. An OAuth error redirect for an application registered in the attacker's own tenant puts the redirect on a Microsoft domain, and Google sign-in endpoints are used the same way as relay points [4]. Legitimate Docusign notifications, document viewers and Microsoft or Google domains all appear before the attacker domain, which shows up only in the final hop [5]. Sender authentication passes, because the envelope really is Docusign's [3]. The landing infrastructure sits on .vu domains mimicking brand names with document-operation paths in mixed case, such as PwPt-sHaRe or Ms36-AcCeSs [6]. Island publishes 755 domain IOCs and says not to treat any single characteristic as definitive proof [15]. My read of that caution: the mixed-case path is the cheapest artefact for the operator to regenerate, so a rule written on it buys you until the next build. The kit also spends client CPU on proof-of-work and checks for automation and DevTools [7], which means your sandbox gets a worse experience than the victim does.
The economics are the part that should set your planning assumption. The price is $320 and the reported scope is hundreds of organisations [1]. At 200 organisations that is $1.60 of tooling per target [21]. The material states the figure without a billing period [22], so read it as the order of magnitude of an attacker's tooling budget rather than a line item. Island's own framing is that commercialisation lets attackers who cannot build AiTM infrastructure execute session theft anyway [20].
For the recommended controls to transfer, two things have to be true. Passkeys and FIDO2 keys are origin-bound [16], but they only help if the origin-unbound method is actually removed for those accounts, because the relay described here works on whatever fallback remains [10]. The other suggestion, blocking suspicious redirect paths through browser policy, presumes managed devices and a browser you can set policy on [17]. Detection has the same prerequisite problem: Island's recipe is a join across browser transition sequences, redirect paths, device trust state, token anomalies and post-authentication activity [13]. On the endpoint there is usually no malware, so browser history and navigation history are the auxiliary evidence [12], and on the identity side the signals are token reuse after a legitimate success, device or IP or browser mismatch, newly registered MFA methods, OAuth grants and mailbox rules [14]. That join needs retention on both sides at the same timestamps.
A password reset does nothing to a cookie that has already been issued, which is why the response guidance puts revocation of active sessions and refresh tokens alongside it [18], and why the sweep has to cover the inbox rules, forwarding settings and OAuth grants an attacker may have added on the way through [19].
