Microsoft 365 phishing has matured into a complete service economy, and Kratos is its clearest product. It hands affiliates the infrastructure, evasion controls, victim filtering, and credential exfiltration needed to run campaigns at scale, with no in-house tradecraft required.
The kill chain opens with familiar business pretexts such as a shared document, a pending invoice, a signature request. From there, victims are routed through trusted services, including SharePoint, OneDrive, Microsoft Forms, and Canva. Each legitimate hop hardens the lure, degrading automated inspection and masking the malicious endpoint behind platforms users already trust.
Kratos then drops Cloudflare Turnstile between security tooling and the phishing page, screening out sandboxes, crawlers, and automated scanners through a verification step that looks routine to the target. Behind that gate sits a pixel-accurate clone of the Microsoft authentication flow, harvesting submitted credentials and relaying them straight to attacker-controlled infrastructure.
Why does Kratos matter? It isn’t just another phishing page, and it’s an operational model that lets low-skill affiliates reproduce credible Microsoft 365 campaigns on demand. That’s where the real threat lives, far beyond the fidelity of a fake login screen. Kratos industrializes the path from a trusted lure to a full account compromise, making it accessible, repeatable, and hard to attribute.
Background
Not long ago, a phishing campaign gave itself away almost the moment you looked at it. A login form copied clumsily from Microsoft, a crude PHP script scribbling stolen passwords into a text file, a domain registered only days before the fingerprints worked alone, and they told you exactly how thin the operation really was. Kratos rewrites that story. It takes the whole messy craft of phishing and turns it into a service you can rent, handing affiliates everything they need to build, launch, filter, and run Microsoft 365 credential campaigns without ever having to engineer the machinery themselves.
To understand why that matters, you have to see a Microsoft 365 account the way an attacker does. It was never just an inbox. It is a master key. Behind that single login sits Exchange Online, SharePoint, OneDrive, Teams, Graph, connected business apps, private conversations, password-reset workflows, and years of relationships that already carry trust. Crack one identity and the whole enterprise opens up: invoices, supplier negotiations, payment approvals, customer records, legal files, internal memos, and the very authentication messages an attacker needs to burrow deeper or cash out.
Seen in that light, Kratos looks less like a folder of phishing templates and more like account-takeover infrastructure. It quietly pulls together everything an operation used to demand, domain deployment, certificate management, DNS setup, page assets, bot filtering, geofencing, control of the virtual servers, and clean delivery of whatever gets captured. The affiliate is left with almost nothing to do but choose who to hit and write a convincing lure. The service handles the rest.
Follow the activity across different campaigns and regions, and something quietly telling emerges. The real thread isn’t how many victims there are, it’s how similar the attacks look under the hood. Change the domain, change the lure, change the target, and the same page assets, the same collection logic, the same interface quirks, and the same deployment structure keep resurfacing. Those repeated fingerprints give the game away: this isn’t one attacker running one page from one server, it’s a service built to be reused, again and again, by whoever pays for it.
And to the attacker, none of it feels like separate moving parts. The email that lands, the trusted platforms that stage the lure, the challenge page that screens out defenders, the fake login that captures the password, the redirect that sends the victim on their way, all of it flows as a single, seamless journey engineered to steer the target from click to compromise. That is what Kratos really sells: not a phishing page, but the whole journey, packaged and repeatable, closing the gap between an affiliate with an idea and an operator who can take over a Microsoft 365 account at will.
Where Kratos Hides
Kratos hides in a trusted context before hiding inside infrastructure. The first destination is commonly a service the victim already uses, such as SharePoint, OneDrive, Microsoft Forms, Canva, Tilda, or another platform associated with documents and collaboration. SharePoint and OneDrive frequently act as the opening delivery route, allowing the lure to begin on a reputable domain before the browser crosses into attacker infrastructure.
This staging choice gives the affiliate several advantages. The email can contain a familiar address rather than the final collection domain, link inspection may stop at the trusted platform, and the victim sees a related experience before authentication appears. The attacker is not asking for immediate trust in an unknown page, because the earlier steps build that trust on behalf of the final page.
The infrastructure behind the last stage follows two broad patterns. Some deployments use newly registered or randomly named domains that can be rotated quickly, while others appear inside compromised legitimate websites, frequently WordPress installations under regional business domains. Disposable infrastructure gives the affiliate speed and replaceability, while a compromised website inherits domain history, working certificates, existing reputation, and a business appearance that can delay suspicion.
Cloudflare usually stands in front of the page and prevents the victim from seeing the origin directly, while the backend may operate on standard cloud or virtual server providers. Wildcard domains can rotate through generated subdomains, document hosts may use names such as files or docs, and compromised sites often bury the kit inside paths such as factura. The infrastructure is designed to be temporary because redeployment is cheaper than long-term survival.
A sanitized browser path can resemble the following sequence:
GET hxxps://tenant.sharepoint.com/document
GET hxxps://files.example.invalid/invoice
GET hxxps://portal.example.invalid/factura/
GET /assets/img/barr.svg
GET /assets/img/lg.svg
POST /next.php
REDIRECT hxxps://office.com
From the attacker’s perspective, every transition has a role. The trusted page creates context, the intermediary separates the email from the collector, the challenge page controls who reaches the form, and the final redirect returns the victim to a real Microsoft destination after submission. If the collector becomes exposed, the affiliate replaces that layer while preserving the lure, assets, and operating logic that define the campaign.
How Kratos Works
Kratos works as a staged browser operation backed by an administration layer that removes much of the infrastructure burden from the affiliate. The service can support page deployment, certificate installation, DNS modification, server status checks, file uploads, geographic restrictions, and several challenge providers. A deployment component can manage virtual servers and domains via dedicated API routes, while the central panel presents the operation as more like a commercial control plane than an improvised phishing folder.
The affiliate can choose between a conventional PHP Microsoft 365 page and a Node.js redirect service with reverse proxy characteristics. The PHP option follows the familiar credential collection model, in which the page receives an identity and password before forwarding them to the operator. The proxy option creates a different possibility by placing attacker infrastructure inside the authentication conversation, although the presence of proxy components does not prove that every observed campaign captured a Microsoft session.
When the victim reaches the landing page, Kratos may present Cloudflare Turnstile, reCAPTCHA, or hCaptcha before revealing the Microsoft-themed interface. Geographic controls can also limit traffic to selected countries. These layers reduce exposure to scanners and irrelevant visitors while giving the victim a familiar verification experience that makes the next authentication prompt feel expected.
The V1 browser sequence can be represented through a sanitized request flow:
GET /assets/img/barr.svg
GET /assets/img/lg.svg
GET /assets/img/ani.gif
GET /assets/css/styles.css
POST /next.php
Host portal.example.invalid
Origin hxxps://portal.example.invalid
Body [email protected]&pr=REDACTED
RESPONSE 302
Location hxxps://office.com
The page logic typically passes the identity and password as parameters di and pr, then submits them to an endpoint associated with the active variant. ‘V1’ usually sends them through next.php or a similar filename, while ‘V2’ uses obfuscated JavaScript and a fetch request to reach ‘save.php’. The early ‘V0’ branch uses mini.php below its ‘PTT’ and ‘SOft’ path structure.
Kratos may allow up to 3 password attempts before redirecting the victim or displaying an incorrect password message. This interaction helps the operator reject random input while maintaining the appearance of a real authentication failure. Captured data can then be serialized as JSON and delivered through Telegram or email, separating the victim infrastructure from the final channel used by the affiliate.
The Attack Chain
The phishing expedition begins with business language rather than obvious technical pressure. A document has been shared, an invoice requires attention, a signature is waiting, or a file appears to come from an existing relationship. These lures can pass through corporate email filters when their visible content, sender context, and initial destination appear compatible with normal work.
A sanitized campaign timeline can look like this:
STAGE Message delivered
STAGE SharePoint document opened
STAGE External document link followed
STAGE Turnstile challenge displayed
STAGE Microsoft themed page rendered
STAGE Credentials submitted to /next.php
STAGE Browser redirected to office.com
The attacker sees this sequence as a trust pipeline. The message supplies the business reason, the trusted service validates the context, the external page carries the actual collection logic, and the redirect removes the victim from the malicious environment after the data has been submitted. No single stage needs to carry the entire deception because credibility is distributed across the journey.
The operation unfolds through seven connected stages.
- The affiliate selects a business theme that matches the intended victim population, including invoices, shared documents, legal notices, signature requests, or traffic authority language.
- The lure points to a trusted service or hosted document, keeping the first click separate from the final credential-collection domain.
- The intermediary redirects the browser to a disposable host, a compromised website, a wildcard subdomain, or a business directory associated with the campaign.
- A challenge service filters automated traffic and creates a routine verification moment before the Microsoft page appears.
- The page displays an animated loading experience and then presents the authentication form, preserving the document context that brought the victim into the flow.
- Submitted values move through the specific generation collection endpoint, after which the victim may see an error or be redirected toward a legitimate Microsoft service.
- The affiliate attempts to convert the captured authentication material into mailbox access, document exposure, partner impersonation, payment fraud, or a wider identity intrusion.
The final stage depends on what the deployment captured. A conventional collector exposes credentials but still faces multifactor authentication and Conditional Access, while a functioning authentication relay may capture a usable session. WebSocket traffic or a convincing Microsoft clone alone cannot prove that session theft succeeded, which makes the distinction important even when the article follows the attacker view.
Kratos Enters the Phishing Ecosystem
Kratos appears as a new foe because it reduces the technical distance between an affiliate and a mature Microsoft 365 phishing operation. The service does not stop at page templates, since the administration layer can manage domains, certificates, virtual servers, page files, health state, bot filtering, geographic access, and the delivery of captured information. What once required several separate tools now resides within a single cohesive service model.
The operator environment reflects the language and structure of a legitimate platform. A central dashboard can expose users and sales activity, deployment components can prepare domains and servers, and API functions can handle domain verification, certificate installation, configuration, and cleanup. Captured data may be directed to Telegram or email, while the operator interface itself can use a master based on creds in Telegram. The criminals protect their own control plane while selling infrastructure designed to compromise somebody else’s identity.
From the affiliate perspective, the greatest value is operational consistency. The attacker does not need to preserve one domain, one server, or one page path for a long period because the service makes replacement part of the workflow. Disposable domains can rotate, compromised sites can be abandoned after removal, and wildcard subdomains can distribute activity without changing the underlying page logic.
Kratos also exists inside a crowded infrastructure ecosystem where the same cloud providers, edge services, virtual servers, and even trusted staging pages may be shared with Tycoon, Flowerstorm, Sneaky2FA, EvilProxy, and other phishing platforms. Shared hosting does not mean shared ownership, but it benefits the attacker by creating attribution noise and making broad infrastructure blocking expensive for the victim organization.
The choice between a PHP collector and a Node.js reverse proxy model further increases flexibility. One affiliate may want simple credential delivery, while another may pursue live authentication relay and session access. Those options create different levels of technical risk, but both begin with the same commercial advantage. Which is the ability to launch a recognizable Microsoft 365 campaign without having to engineer the complete attack stack.
Kratos is dangerous because it productizes repeatability. The service converts page creation, infrastructure management, traffic filtering, credential handling, and affiliate operations into reusable components, allowing the attacker to treat phishing as a deployment problem rather than a research project.
Kratos Variants
Kratos has evolved through three visible generations that change the page design, asset names, and collection logic while preserving the same operational objective. The differences show how the service responds when signatures become familiar, because each generation modifies the surface that researchers and security products can observe without abandoning the workflow that affiliates already understand.
V0 is the earliest known branch. Its URLs contain the PTT and SOft structure, while captured values are sent to mini.php. The page uses a secure file access theme that prompts the victim to verify an email address before opening a document, while a blurred invoice or spreadsheet remains visible behind the form. The branding is less faithful to Microsoft authentication than later versions, but the document pressure is already central to the design.
V1 becomes the dominant generation and shifts toward direct imitation of the Microsoft sign-in window. Its recurring assets include barr.svg, lg.svg, ani.gif, res.css, and styles.css. The browser logic uses a submitData() function that reads the identity and password values, sends them to next.php, and handles error messages or redirects to office.com. Alternative endpoints include nex.php, n3xt.php, and officer paths.
V2 restructures the frontend around dsa.svg, sid.gif, imag.jpg, and an obfuscated main.js file. It uses a beta version of jQuery and sends captured values toward save.php through fetch. The new structure changes the visible code and filenames, but the relationships remain underneath, as the V1 lg.svg content is identical to the V2 dsa.svg asset at the byte level.
From the operator’s perspective, these generations represent controlled adaptation rather than separate products. V0 tests the document access model, V1 perfects the Microsoft authentication imitation, and V2 introduces new assets and obfuscated client logic to reduce recognition. Shared infrastructure and identical content connect the branches, while the different collector paths allow the service to change its external appearance without replacing the broader administration model.
The variants show the economics of PhaaS evolution. The operator changes the smallest layer necessary to preserve campaign life, while affiliates continue using the same trusted staging, traffic filtering, credential delivery, and redirect strategy. Kratos evolves because the frontend is disposable, but the service behind it is intended to remain stable.
Fingerprints Kratos Leaves Behind
Even a platform designed for rotation must expose stable artifacts because the victim browser needs files to render the page and endpoints to submit captured data. These artifacts are not mistakes in the traditional sense, since they are dependencies created by reusable code. The same efficiency that helps affiliates launch campaigns also produces recurring fingerprints across otherwise unrelated domains and hosting environments.
The primary page assets identify the active generation when they appear together inside the same browser session:
From the attacker’s perspective, these files are part of the visual package that makes every deployment consistent. From the outside, their combination links campaigns even when the affiliate changes the domain, directory, certificate, or virtual server. A single filename may be meaningless, while the complete group exposes the shared kit behind the page. The collection endpoints create another footprint:
Behavior inside the browser adds more context. Kratos sessions may expose Cloudflare Turnstile identified as challengepoint, ‘DOMPurify version 3.2.6’, a browser tab titled Authentication, and a page classified as a Fake Microsoft Authentication Page. The victim may see an animated envelope with “Loading in progress” over a blurred invoice, while some variants display an Einvoice Beta footer.
The client logic can reveal ‘submitData()’ collecting the di and pr parameters before sending them toward the active endpoint. ‘WebSocket’ activity may also appear, though it remains a risk indicator rather than proof of an adversary in the middle of the flow. A persistent channel does not necessarily indicate that cookies, tokens, or Microsoft session data were successfully relayed.
Affiliate habits also surface through recurring URL path tokens:
These values can reflect language, campaign themes, or the preferences of a particular affiliate, yet they do not prove actor identity. Kratos hides infrastructure effectively, but reusable assets, form logic, collector paths, visual behavior, and affiliate naming habits expose the machinery that remains consistent underneath the rotation.
Browser Security and ITDR to the Rescue
Strong authentication, particularly MFA, no longer stops modern attacks. Adversary-in-the-Middle (AiTM) phishing kits relay the victim’s login in real time, capture the authenticated session token after MFA succeeds, and log in as the user without ever knowing the password.
Two controls address this where it actually happens: the browser, where the malicious URL is rendered, the fake login is shown, and the token lives, and ITDR, where the stolen session surfaces as anomalous identity behavior. Neither alone is enough. Together they cover both the point of theft and the point of use.
Note: AiTM variants can manipulate strong authentication, making it easier to downgrade or bypass it.
While we simulated more than 25 attack scenarios with a few variants, we saw two things: the browser security protects and prevents access to the malicious site, and if the variant bypasses the browser security, the ITDR catches it.
No Slack account needed.
Browser Security
Activate Guardz ITDR
To reduce exposure to modern identity-based phishing campaigns, organizations need visibility beyond the initial email. Attacks such as Kali365 abuse trusted Microsoft authentication flows, session artifacts, OAuth permissions, and post-compromise mailbox activity. In most cases, conditional access and other security policies are not enough.
Detecting these behaviors requires dedicated identity threat detection and response, not just traditional email or endpoint controls.
Activate Guardz ITDR to detect and respond to:
- AiTM Attack
- Malicious/hidden inbox rules
- Anomalous Graph API activity
- Suspicious OAuth consents
- And other emerging attacks
What does this look like in Guardz ITDR?
For example, Guardz ITDR detects AiTM, OAuth device code flow abuse, and other identity-based attack patterns using dedicated detection logic built to identify both known techniques and emerging PhaaS variants.
As the attack unfolds, the Guardz ITDR incidents appear and break down the details.
Conclusion
Kratos does not reinvent phishing, but it reorganizes the attack into a service that affiliates can operate with the consistency of a platform. The criminal value comes from combining trusted staging, temporary infrastructure, traffic filtering, Microsoft authentication imitation, credential collection, and data delivery into a single repeatable workflow. Each component is replaceable, while the service remains useful because the operator has separated the campaign into modular layers.
From the attacker’s perspective, trust is the primary avenue of exploitation. SharePoint and OneDrive provide the opening context, a hosted document gives the victim a reason to continue, Cloudflare and challenge services control visibility, and the authentication clone collects the data the campaign was designed to obtain. The operation succeeds when the user experiences several different systems as one legitimate Microsoft journey.
The variants reveal how the platform protects that model. V0 establishes the secure document theme, V1 improves the Microsoft login imitation, and V2 changes assets and client logic while retaining the same collection objective. Domains and servers rotate because they are disposable, whereas page behavior and affiliate workflow persist through reusable code and centralized operations.
Kratos also exposes the tradeoff inside every criminal service. Standardization allows affiliates to move faster, but the same standardization leaves recurring assets, collector paths, browser behavior, and URL tokens across separate deployments. The operator gains scale by reusing components, yet that reuse creates a recognizable technical identity beneath the changing infrastructure.
From the affiliate view, the most important capability is not page fidelity alone, but the ability to recreate the same trusted journey whenever infrastructure changes or a deployment disappears.
The real risk begins after the victim submits authentication material. A password may open the first door, a relayed session may bypass part of the authentication boundary, and a trusted Microsoft 365 identity can create access to email, files, relationships, and financial conversations that carry far more value than the original credential. Kratos turns that path into a product, which is why it should be understood as an account takeover machine rather than another phishing page.
Refernece
Discover additional Research Posts
More about Kratos PhaaS
