Blacksite Phishing Kit Uses Cloaking to Evade URL Scanners

Abnormal AI researchers reported in June 2026 that a phishing-as-a-service offering named Blacksite pairs an adversary-in-the-middle phishing kit with a cloaking service called Cloaked.gg. According to the research, suspected security scanners and analysis environments can receive benign decoy pages while selected targets are routed to the live phishing flow.

How the reported chain works

1. An operator creates or distributes a campaign URL through email, messaging, advertising, or another delivery channel.
2. The cloaking layer evaluates attributes such as network origin, hosting provider, geolocation, and signs of automated analysis.
3. A suspected scanner receives a harmless decoy, which can produce an apparently clean verdict.
4. A selected visitor is routed to an adversary-in-the-middle reverse proxy that mirrors a real sign-in experience.
5. Credentials, multi-factor codes, session cookies, or tokens can be captured and relayed during authentication.

The reported design does not merely copy a static login form. An adversary-in-the-middle proxy can relay content between a victim and the legitimate service in real time. That enables theft of session material even when the victim completes multi-factor authentication, because the attacker is positioned inside the authentication exchange rather than guessing the second factor later.

Why scanner evasion changes URL reputation

Traditional URL checks often fetch a destination from known cloud infrastructure, controlled browser environments, or recognizable scanner networks. Cloaking attempts to identify those requests and change the response. The destination can also vary by country, device, referral path, time, cookie, or campaign token. A verdict therefore needs freshness, context, and corroboration.

• Record redirects and the final destination instead of evaluating only the first URL.
• Repeat analysis from independent network and browser contexts when the risk justifies it.
• Inspect domain age, certificate history, hosting changes, redirect behavior, and campaign reuse.
• Treat a benign decoy that is unrelated to the advertised destination as a possible evasion signal, not automatic proof of safety.
• Preserve the timestamp and observation context because the response can change after the first scan.

Protect the identity flow, not only the link

URL analysis should be one layer in an account-protection program. Phishing-resistant authentication, device and session risk controls, token binding where available, short session lifetimes for sensitive actions, and rapid revocation reduce the value of captured credentials or cookies. Users should be encouraged to start sensitive sign-in flows from a known application or bookmarked domain rather than a message link.

Defenders should also monitor the post-authentication behavior that follows a stolen session: new devices, impossible travel, mailbox-rule changes, recovery-method changes, unusual token use, payment changes, and bulk access. A malicious session can look authenticated because the attacker stole a valid session rather than bypassing authorization at the HTTP layer.

Safer handling for links and redirects

• Resolve and validate redirect destinations on the server before exposing them to users.
• Use explicit destination allowlists for administrative, payment, and account-recovery workflows.
• Do not convert an unavailable scanner, timeout, or malformed result into a silent safe verdict.
• Separate URL threat evidence from the final access decision so policy can account for uncertainty.
• Log the original URL, normalized destination, decision reason, and time while redacting credentials and sensitive query values.