Five Hops and a Live Operator: Inside a Real-Time Card-Harvesting Phishing Kit

We expected a normal case: someone forwards a sketchy link, you sandbox it, you find a generic credential-phishing page, you write up two paragraphs and move on. What actually happened was a redirect chain that fought back at every layer, deliberately built to make automated tooling give up, and at the end of it, a fully functional Booking.com impersonation kit with a live human operator watching victims fill out a payment form in real time.

Short version: what started as "check this one forwarded link" ended with us mapping a five-hop redirect chain, a pixel-perfect brand impersonation kit harvesting full card data and PII, a five-second AJAX polling loop giving a real operator live control over each victim's session, and an embedded chat widget letting that operator talk a victim through hesitation. Russian-language artifacts in the page source provided context about the kit's likely development environment and fraud ecosystem.

Walking the chain before touching the payload

The instinct with a suspicious link is to throw it at a sandbox or curl it and see what comes back. That instinct failed here, repeatedly, and figuring out why it failed at each hop was most of the actual investigation.

• Hop 1 was Avanan time-of-click protection in the recipient organization's mail environment, wrapping the forwarded link. This was routine link-protection behavior, not evidence that the campaign targeted Bulkhead Security.
• Hop 2 was Barracuda Link Protect in the sender's mail environment. Its wrapped URL carried typo=1, indicating that murl.gr had been flagged as a likely typo-squat but was logged rather than blocked.
• Hop 3 was murl.gr, a commodity shortener observed at https://murl.gr/zeJ3ja and resolving to 91.98.79.35, a Hetzner-hosted system in Frankfurt (AS24940). Its HTTPS behavior was broken: it served plain HTTP on port 443, so automated tooling that required a valid TLS handshake stopped at this hop for the wrong reason.
• Hop 4 was safebrowse.io, a URL-safety interstitial that presented a "Continue" button and required a human click to proceed. Sandboxes and crawlers do not generally perform that interaction. That single design choice quietly defeats much automated URL detonation, because systems built to safely visit a link on a user's behalf are non-interactive by design.
• Hop 5, the payload, landed on sdlkfm2lsfdfdf.icu, observed at /CGTE1K9AGPT1C/ and /lufigoq. It sat behind a Cloudflare proxy with its origin hidden and layered on user-agent filtering, likely filtering of known scanner IP ranges, and per-victim single-use path tokens. Only a real browser following a fresh, real click saw the phishing page. Every hop was a small, specific bet against a specific category of automated defense, and stacked together they worked.

What was waiting at the end

The final page was a near-exact clone of a real hotel-booking payment flow: reused Booking-style CSS class names, matching SVG icon paths, the same 40-plus language list, and real card-network and wallet logos. One detail stood out immediately: a Ukrainian language option existed in the asset paths but was explicitly commented out of the rendered HTML, a deliberate exclusion rather than an oversight.

The form itself asked for far more than a stolen password. It collected full name, phone, email, and free-text fields, alongside full card data (PAN up to 19 digits, expiry, CVV rendered as a password field), and a currency selector defaulting to a standard fiat currency but offering close to two hundred options including a long list of major cryptocurrencies. That currency breadth is a tell on its own: a kit built only to skim card numbers doesn't need a crypto wallet picker. This one is built for more than one monetization path.

Buried in the page's client-side script, running silently every five seconds, was an AJAX loop polling /ajax/payment_card_status.php for a live status flag. If that flag ever came back true, the victim's browser was redirected wherever the operator chose: a "your card was declined, try again" page to harvest a second card, a legitimate site to close the loop cleanly, or anywhere else. A second polling call, /ajax/user_send_status.php, reported which step of the funnel the victim was currently on. The form submitted to /69CROKHE/ with observed session identifier 77081544. Combined, this isn't a static phishing page, it's a live console: an operator gets notified within five seconds of a victim landing, watches them move through the form in real time, and can steer the outcome. An embedded Chatra live-chat widget at /chat/ZWGYTTH3F (identifier ZWGYTTH3F) let that operator pose as support staff, the kind of real-time social pressure that talks a hesitant victim through a red flag they might otherwise have stopped at.

sequenceDiagram
    participant Victim as Victim Browser
    participant Kit as sdlkfm2lsfdfdf.icu (Phishing Kit)
    participant Operator as Threat Actor / Operator Dashboard

    Victim->>Kit: GET /CGTE1K9AGPT1C/ (loads Booking.com clone)
    loop Every 5 seconds
        Kit->>Kit: POST /ajax/user_send_status.php (page=payment)
        Kit-->>Operator: Notifies operator of victim's funnel step
        Victim->>Kit: POST /ajax/payment_card_status.php (code=true)
        Kit-->>Victim: {"status": false}
    end
    Victim->>Kit: POST /69CROKHE/ (firstname, lastname, cardNumber, expiry, cvv, token=77081544)
    Operator-->>Kit: Reviews submitted card data live
    Operator->>Kit: Sets status=true, url=<decline page>
    Kit-->>Victim: Redirect to "card declined" page
    Victim->>Kit: Submits a second card
    Note over Victim,Operator: Chatra widget (/chat/ZWGYTTH3F)<br/>lets the operator pose as live support
            

Hidden template text, invisible to the victim but present in the page source, was in Russian, including operator-facing UI labels and one especially telling line explaining that no fixed price needed to be set because the victim would type in their own amount, using a Russian-language slang term for a fraud victim common in Russian-speaking criminal communities. A commented-out error handler also contained a Russian-language console message. These artifacts are consistent with a Russian-speaking operator, development environment, or fraud ecosystem; they do not establish the actor's nationality or physical location.

<span>Пропустить</span>   <!-- “Skip” — operator-facing template hint -->
<span>Мамонт сам указывает цену EUR</span>   <!-- “The mammoth enters the price himself EUR” -->

Мамонт (“mammoth”) is established Russian criminal slang for a fraud victim, widely used in Russian-speaking fraud communities. In this context, the line is an internal operator instruction explaining that no fixed booking price needs to be set because the victim will enter their own amount.

// console.error("Ошибка: " + textStatus + ", " + errorThrown);
// “Ошибка” = “Error”

flowchart TB
    Victim["Victim Browser"]
    CF["Cloudflare CDN/Proxy\nsdlkfm2lsfdfdf.icu"]
    subgraph Attacker["Attacker-Controlled Infrastructure"]
        Origin["Hidden origin server\n(IP not exposed behind Cloudflare)"]
        Hetzner["Hetzner VPS 91.98.79.35\nAS24940, Frankfurt DE\n(hosts murl.gr, Hop 3)"]
        Chatra["Chatra live chat\n/chat/ZWGYTTH3F"]
        ImageCDN["imagebb-cloud.com\n(hosts hotel photo asset)"]
        CFA["Cloudflare Web Analytics\ntoken 0a8c88121e1e477d9039c607a0a2d43b"]
    end

    Victim -->|HTTPS| CF
    CF --> Origin
    Origin --> Chatra
    Origin --> ImageCDN
    Origin --> CFA
            

Why the layers matter together

Any one of these pieces is a known technique. Multi-hop link wrapping isn't new. Brand impersonation kits aren't new. Live-chat social engineering isn't new. What made this worth a full writeup is how deliberately the layers were sequenced to defeat specific classes of defense in order: the wrapping and interstitial layers exist purely to survive automated scanning long enough to reach a real human, the visual fidelity exists to survive that human's own scrutiny once they arrive, and the live operator plus chat widget exist to catch the fraction of humans who do hesitate despite the fidelity. It's a funnel built with defense-in-depth logic turned against the defender. Take away the human-click interstitial and automated sandboxes catch it immediately. Take away the live operator and the fallback conversion rate on a suspicious payment form probably drops hard. It's the combination that makes this kit effective rather than any single piece.

Root cause, from a defense standpoint

The structural weakness being exploited isn't in any one product, it's an assumption baked into a lot of URL-safety tooling: that a link resolves to something a machine can safely and fully traverse on its own. The moment a chain requires a genuine human interaction step to proceed, most automated detonation and scanning infrastructure simply stops, and a "no threat found" result at that point reflects "we couldn't get further," not "this is safe." A secondary weakness is that link-protection systems flagged the typo-squatted destination and logged it instead of blocking, treating a positive detection signal as informational rather than actionable.

What this means for defenders

• Treat interstitial-gated redirects as suspicious by default, not as "scan inconclusive, allow." If your link-protection or sandboxing pipeline can't get past a human-click gate, that's a strong signal worth surfacing to the user or blocking outright, rather than silently passing the link through as unscanned.
• Escalate on your own tooling's positive detections. A typo-squat flag that only logs is a near-miss you're choosing not to act on. If a link protection product flags something and still delivers it, that's a policy gap independent of anything the attacker did.
• Correlate IOCs across the whole chain, not just the final domain. The shortener, the interstitial service, the CDN-fronted payload domain, the image CDN, and the chat and analytics identifiers are all pivot points. Threat intel sharing that only lists the final phishing domain misses most of the infrastructure an actor can keep reusing after that one domain gets taken down.
• Brief users on live-chat social engineering specifically, not just "check the URL." A widget offering to "help" mid-payment-form is a pressure tactic most phishing awareness training doesn't cover, because it assumes static pages, not live operators.

Indicators of Compromise

The security lesson to take from this

When you're handed a suspicious link, don't stop at whatever verdict your first automated tool gives you. Walk the chain by hand and ask, at each hop, why an automated system would fail here specifically. That question is exactly what a kit builder was answering when they designed the chain in the first place, and it's usually where the real story, and the rest of the infrastructure, is hiding.

Glossary: Terms used in this post

• Redirect chain: A sequence of links where following one leads to another, and another, before finally arriving at the real destination. Attackers use long chains to add obfuscation between the original link and the final malicious page.
• Time-of-click protection / link wrapping: An email security feature that rewrites links in incoming email so that, whenever the link is actually clicked (not just when the email arrives), the destination gets re-checked in real time before the user is sent onward.
• Typo-squatting: Registering a domain name that's a slight misspelling or lookalike of a legitimate one, hoping victims won't notice the difference.
• Interstitial: A page inserted in between two others, in this case a "click to continue" page placed deliberately between the redirect chain and the final phishing page, requiring genuine human interaction to proceed.
• Sandbox / URL detonation: Automated security systems that visit a link in an isolated environment to see what it does, without a real human or real credentials involved, used to catch malicious pages before a person clicks them.
• Cloaking: Techniques a malicious page uses to show different content (or nothing at all) to security scanners and bots than it shows to real human victims, often based on user-agent, IP address, or geographic location.
• Geofencing: Restricting or altering content based on the visitor's geographic location, in this context likely used to hide the phishing page from security researchers outside the attacker's intended victim region.
• AJAX: A web technique that lets a page's JavaScript quietly send and receive data from a server in the background, without reloading the page, used here to give a remote operator live control over what a victim sees next.
• C2 (Command and Control): Infrastructure or a communication channel that lets an attacker remotely control or issue instructions to something they've compromised or deployed, in this case the live polling loop letting an operator redirect victims on demand.
• IOC (Indicator of Compromise): A piece of evidence, like a domain, IP address, or file hash, that can be used to detect or block a specific malicious campaign elsewhere.
• PAN / CVV: Primary Account Number (the full credit card number) and Card Verification Value (the 3-4 digit security code), the two pieces of card data most valuable to a fraudster.
• PII (Personally Identifiable Information): Data that can identify a specific individual, such as name, phone number, or email address.
• CDN (Content Delivery Network) / origin IP: A CDN sits in front of a website and serves traffic on its behalf, which can also be used to hide the real ("origin") server's IP address from anyone investigating the site.
• VPS (Virtual Private Server) / AS number: A rented virtual server, commonly used for disposable attacker infrastructure; an AS (Autonomous System) number identifies which network operator owns a given block of IP addresses.
• TLD (Top-Level Domain): The suffix at the end of a domain name (like .com or .icu); some lesser-known TLDs are popular with attackers because registration is cheap and abuse enforcement is inconsistent.
• Session/tracking token: A unique identifier embedded in a link or form to track an individual visitor or session, sometimes reused by researchers to pivot to related infrastructure or campaigns.