Security teams detect Greatness PhaaS by identifying phishing-as-a-service infrastructure that generates convincing login pages and proxies authentication to capture session data. Track reused lure patterns, rotating domains, suspicious mail flows, and successful sign-ins that follow an MFA challenge from a site that is not the expected corporate login surface.
How Greatness PhaaS detection works in practice
The most reliable way to spot greatness phaas is to look for the attack chain, not just the page. Greatness-style kits are built to present a convincing login surface while relaying the victim’s authentication in real time, so defenders should treat the phishing page, the mail delivery path, and the resulting sign-in telemetry as one event stream. The best detection signals are often weak individually, but clear when correlated.
Greatness campaigns frequently leave patterns in the infrastructure and the lure itself. Reused branding elements, similar page structure across rotating domains, and repeated sender behavior can reveal that apparently separate messages belong to the same phishing service. That makes lookalike-domain monitoring, URL reputation review, and campaign clustering more useful than waiting for a single obviously malicious page to appear.
Authentication telemetry is especially important because these kits are designed to sit between the user and the real service. If a successful sign-in follows an MFA prompt from a page that is not the expected corporate login surface, treat that as a strong indicator of adversary-in-the-middle activity. The same logic applies when session creation occurs from an unfamiliar domain family or when the user’s mailbox shows forwarding, rule creation, or other post-login abuse soon after the phish is delivered. For a broader detection playbook on adversary-in-the-middle phishing and session theft, see AiTM Phishing Guide.
Signals that usually separate Greatness from ordinary phishing
Greatness PhaaS is easier to catch when teams separate lure content from delivery infrastructure and from post-authentication activity. The lure may be mundane, but the supporting footprint often is not. Repeated sender domains, short-lived hosting, suspicious redirect chains, and a login page that behaves like a proxy rather than a static fake are all consistent with phishing-as-a-service tradecraft. The more these indicators cluster around a small set of pages or domains, the more likely you are dealing with an organised kit rather than one-off imitation.
Successful detection also depends on knowing what “normal” looks like for your environment. If a mailbox is being used to send unusual internal-looking lures, or if the same infrastructure is touching multiple users in a short window, the campaign should be escalated quickly. Current guidance suggests combining email telemetry, web proxy logs, identity sign-in records, and domain intelligence so the team can connect the lure to the login attempt and then to the session that was established afterward.
Phishing kits are part of a larger ecosystem, so detection improves when teams compare indicators against known phishing-kit patterns rather than treating each message as unique. The Phishing Guide is useful here because it covers phishing-as-a-service patterns, lookalike domains, and layered detection approaches that help distinguish commodity phishing from kit-driven campaigns.
What to verify before you call it a Greatness campaign
Before escalating an incident as Greatness PhaaS, verify that the suspicious page actually proxies authentication rather than just imitating it. That means checking whether the victim’s login attempt produced a real downstream session, whether MFA was satisfied through a suspicious intermediate page, and whether the same domain family appears in multiple victim reports or message traces. Correlation matters because a single suspicious page can be benign-looking clone activity, while a cluster of related pages is much more likely to represent an active campaign.
Teams should also verify whether the user account showed signs of follow-on abuse after the phish. In practice, that means reviewing sign-in logs for unusual geolocation, impossible travel patterns, anomalous user agents, mailbox rule creation, consent grants, or access to applications the user rarely touches. Those checks help distinguish a blocked attempt from a token or session compromise that may still be active.
For the identity side of the investigation, it is worth comparing the observed sign-in flow with expected authentication behavior. A successful login that occurs after a challenge from an unexpected surface is a stronger signal than a generic failed login burst. The NIST SP 800-63 Digital Identity Guidelines are relevant because they frame phishing-resistant authentication and the conditions under which authentication strength matters operationally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63 — Digital Identity Guidelines | Phishing-resistant authentication and sign-in assurance are central to AiTM detection. |
| Recommendation — Use phishing-resistant authenticators and review sign-in telemetry for unexpected authentication flows. | ||
| MITRE ATT&CK | T1566 — Phishing | Greatness PhaaS is a phishing delivery and credential capture technique. |
| Recommendation — Map lure delivery and credential capture activity to phishing techniques in detection engineering. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | Correlating mail, web, and sign-in telemetry is the core detection pattern here. |
| DE.AE-02 — Adverse Event Analysis | A suspicious sign-in after MFA from a non-corporate login surface is an adverse event signal. | |
| Recommendation — Correlate email, proxy, and identity logs to detect campaign infrastructure and post-login abuse. Investigate anomalous post-authentication activity as a likely compromise indicator. | ||
Practitioner Guidance
What to prioritize: Start with the highest-confidence cluster, not the most visible lure. A campaign becomes operationally important when the same infrastructure is tied to successful sign-ins, mailbox abuse, or session creation, because that is the point where the phish has crossed from delivery into access.
What to verify: Check whether the compromise path includes a real authentication event after the phishing page, and whether any sessions, tokens, or mailbox rules were created immediately after. If those artifacts exist, treat the incident as credential or session exposure rather than simple spam.
Common mistake: Teams often over-focus on blocklisting the domain and under-focus on the identity telemetry that shows whether the campaign worked. Blocking the page is useful, but it is not sufficient if the adversary already established access through the phished session.
Practitioner takeaway: Greatness detection is strongest when email, web, and identity logs are analyzed together, because the decisive clue is usually the handoff from lure to authenticated session, not the phishing page alone.