A suspicious URL came in for analysis before escalation. First impression: something about the structure felt deliberately obfuscated — multi-level subdomain, unusual TLD nesting, the kind of thing someone builds when they need distance from the payload. The initial hypothesis was a zero-day delivery mechanism. It wasn't. But working through why it wasn't is the useful part of this write-up.
The URL
hxxps://retrieval.craidaiyio.in.net/@Gqay7AW/Broken down:
- →
craidaiyio.in.net— a typosquat. The.in.netsecond-level domain nesting adds legitimate-looking layers while the actual registerable domain stays cheap and disposable. - →
retrieval.subdomain — adds a functional-sounding prefix that implies a document or data retrieval system, which reduces suspicion - →
@Gqay7AW/— base64-adjacent token likely used to track which victim clicked, or to gate the payload to targeted recipients only
Safe Analysis Methodology
Before detonating anything, passive reconnaissance first:
- 01VirusTotal — submit the URL. At time of analysis, limited detections, which is a weak signal in either direction for a fresh campaign.
- 02URLScan.io — passive scan showing redirects, DOM structure, and any resources loaded without needing to interact with the page.
- 03ANY.RUN interactive sandbox — Windows 11 environment, full process tree visibility, network captures, MITRE ATT&CK tagging, and the ability to interact with the page as a human would.
What the Sandbox Found
The URL resolved to a two-stage delivery:
Stage 1: A non-standard CAPTCHA challenge. Not a Google reCAPTCHA — a custom-built one, which is a significant red flag. Legitimate sites use established CAPTCHA providers. A custom CAPTCHA exists to gate the payload behind a human interaction that basic automated scanners won't perform, while simultaneously appearing legitimate to a rushed user.
Stage 2: After CAPTCHA completion — a cloned Microsoft login page. High fidelity copy, Microsoft branding, correct URL format in the displayed elements. The actual submission endpoint was a non-Microsoft domain.
Why This Is NOT a Zero-Day
The initial alarm came partly from the Edge browser showing command-line processes that looked unusual in the sandbox process tree. This is the kind of thing that gets flagged as "suspicious process execution" and inflates the perceived severity. In this case, those processes were standard network service utilities — completely normal behavior for Edge's background networking stack. The malicious alerts were triggered by destination URL reputation, not by anything the executable was doing.
The definitive checklist for a true zero-day exploit:
| INDICATOR | ZERO-DAY | THIS CAMPAIGN |
|---|---|---|
| Memory corruption / heap spray | Present | Absent |
| Shellcode execution | Present | Absent |
| Privilege escalation attempt | Present | Absent |
| Vulnerability exploitation (CVE) | Present | Absent |
| Process injection | Often present | Absent |
| User interaction required | Usually not | Required (CAPTCHA + form) |
| Credential submission | Secondary goal | Primary goal |
This was a freshly-deployed phishing campaign using a typosquat domain, a custom CAPTCHA gate, and a high-fidelity login page clone. Sophisticated in execution, but social engineering — not exploitation.
Why the Misclassification Matters for IR
Calling this a zero-day and responding accordingly means:
- !You patch things that don't need patching and miss notifying affected users that their credentials are compromised
- !You escalate to C-suites with the wrong severity, burning credibility when the real story comes out
- !You spend forensics time looking for exploit artifacts that don't exist, while actual credential use is happening in the background
The correct IR for a credential phishing campaign: force password resets on all accounts that may have interacted with the URL, audit login logs for that period across all SSO-connected services, block the domain at perimeter, and notify staff.
Communication to Leadership
This analysis was prepared for escalation to a C-suite contact. A few principles I applied when translating the technical findings for that audience:
- →Remove all technical jargon ("sandbox," "root cause," "heap") — replace with plain-language descriptions of what happened and what the risk is
- →Lead with the decision they need to make, not the analysis that led to it
- →The tenant name (
netorg671502) not matching any known vendor was the most significant unresolved concern — make that the focal point - →Definitive conclusion up front: "This is not an exploit. Here is what it is, and here are the next steps."