EvilBit Threat Digest - When Tables Become Traps and Trust Turns Toxic

KryptoKat here. Some weeks, the threat landscape hands you a clean narrative--a single zero-day dominating headlines, or a breach so spectacular it eclipses everything else. This wasn't one of those weeks. Instead, we got a reminder that attackers continue to innovate around the edges: phishing campaigns that render QR codes as HTML tables to bypass image scanners, multi-stage AsyncRAT infections using legitimate Python environments for stealth, fake Fortinet VPN portals powered by SEO and AI-generated search summaries, and a sprawling Christmas-season initial access campaign targeting 767 CVEs with OAST callback validation.

The common thread? Attackers are weaponizing trust at every layer--trust in search results, trust in software update mechanisms, trust in legitimate cloud services. And the defensive playbook needs to evolve from "block known-bad" to "verify everything."

Let's dig in.

Phishing Evolution: When Your Email Gateway Sees a Table, Not a Trap

The SANS Internet Storm Center documented a phishing campaign that should make every SOC analyst rethink their content inspection rules. UncleSp1d3r talked about this previously in a ZeroDay Field Notes, but we now have additional defensive details. Instead of embedding QR codes as images (which email gateways can scan with OCR), attackers rendered the QR codes as HTML tables--hundreds of tiny <td> cells with bgcolor attributes forming the familiar black-and-white pattern.

The campaign ran between December 22–26, 2025, and used personalized URLs on subdomains of lidoustoo.click to harvest credentials. When victims scanned the rendered QR code with their phones, they were redirected to credential-harvesting pages that mimicked login portals.

The technique is elegant and effective. Image-based detection sees nothing suspicious--there's no <img> tag, no base64-encoded data URI, just a table. OCR tools configured to extract text from images won't trigger. And URL rewriting at the email gateway might miss the QR payload entirely because the link is encoded visually, not textually.

For defenders:

• Block or sinkhole lidoustoo.click and all subdomains at DNS and web gateway levels
• Deploy email content inspection rules to detect dense table constructs composed of small bgcolor cells (a signature of HTML-rendered QR codes)
• Implement URL rewriting and sandboxing at the email gateway to inspect and analyze destinations encoded in QR payloads before user access
• Conduct user awareness training emphasizing that QR codes in unsolicited emails carry equal or greater risk than suspicious links, and should not be scanned without verification
• Enable logging and alerting on outbound requests to *.lidoustoo.click and on unusual redirection chains originating from email traffic

The SANS ISC writeup includes code samples and detection guidance. This is a perfect example of how attackers adjust to defenses; when image scanning is everywhere, just send your payload as structured data instead.

AsyncRAT Goes Multi-Stage: Cloudflare TryCloudflare WebDAV, Python 3.14.0, and APC Injection

Trend Micro's MDR team documented an interesting AsyncRAT campaign that chains multiple evasion techniques into a single infection flow:

1. Initial delivery: Phishing ZIP containing .url or .lnk files pointing to Dropbox-hosted payloads
2. First stage: .wsh or .wsf scripts download a .bat file hosted on Cloudflare TryCloudflare WebDAV (a free tunneling service)
3. Second stage: Batch script downloads and installs the official Python 3.14.0 embed package from python.org to %AppData%\z1man\
4. Third stage: Python script (ne.py) performs APC injection of shellcode (new.bin) into explorer.exe
5. Final payload: AsyncRAT beacon with startup folder persistence

Using TryCloudflare WebDAV is pretty smart. It's a free, temporary tunnel that's tough to block completely since it's a legit Cloudflare service. The Python embed package is signed by the Python Software Foundation, so it passes application allowlisting. And APC injection into explorer.exe is a classic evasion technique that many EDRs struggle to detect reliably.

AsyncRAT itself is a well-known commodity RAT with extensive capabilities: keylogging, screen capture, remote command execution, credential theft, and plugin support. What makes this campaign notable is the sophistication of the delivery chain. Each stage uses legitimate infrastructure and signed binaries to minimize detection surface.

For defenders:

• Block TryCloudflare domains (*.trycloudflare.com) and monitor WebDAV connections to suspicious cloud tunnels
• Deploy EDR with behavioral analysis for script execution from %TEMP%, Downloads, and user-writable paths, especially scripts invoking Python or other interpreters
• Hunt for Python installations in user-writable paths like %AppData%\z1man and rundll32.exe DavSetCookie usage (WebDAV auth)
• Implement AMSI and Constrained Language Mode for PowerShell; restrict startup folder writes
• Enable web filtering for Dropbox shared links with ZIP archives containing .url files

The Trend Micro analysis includes full infection chain telemetry, file extractions from C2 servers, and Trend Vision One detection queries. For SOC teams, this is a case study in multi-stage threat hunting. You can't just block one piece; you need behavioral detection across the entire chain.

SEO Poisoning Meets AI Summaries: Fake Fortinet VPN Sites Steal Credentials

A campaign aimed at Fortinet VPN users shows how attackers are using SEO tricks and AI-generated search summaries to lead victims to fake phishing sites.

The attack flow, documented by multiple sources, generally follows this playbook:

1. GitHub Pages decoy: A repository at vpn-fortinet.github.io hosts a minimal landing page with SEO-optimized keywords
2. Search result manipulation: Victims searching for "Fortinet VPN download" or "FortiClient installer" see the GitHub page in results, boosted by AI-generated search summaries that make it appear legitimate
3. Redirection: The GitHub page redirects to fortinet-vpn.com, a convincing fake download portal
4. Credential harvesting: The portal prompts for VPN credentials before delivering a payload (fetched from myfiles2.download)
5. Post-compromise: Compromised VPN credentials enable account takeover, lateral movement, and data exfiltration

The use of GitHub Pages provides legitimacy, since it's a trusted domain, and the repository can be indexed by search engines. The AI-generated search summaries (from tools like Google's SGE, Bing Chat, etc.) often pull snippets that make the fake page appear authoritative, especially when the attacker has seeded the content with official-sounding language.

For defenders:

• Block and sinkhole vpn-fortinet.github.io, fortinet-vpn.com, and myfiles2.download at DNS/proxy and web gateways
• Enforce MFA for all VPN access and require per-session adaptive authentication
• Advise users to only download Fortinet installers from official fortinet.com endpoints; add explicit allow-lists for vendor download URLs
• Alert/monitor for authentication attempts using legitimate Fortinet accounts from unusual IPs and force password resets for suspected exposures
• Use web reputation/URL rewriting to strip or inspect GitHub Pages redirection chains; report malicious GitHub Pages to GitHub for takedown
• Hunt for IOCs in proxy, VPN, and EDR logs (DNS queries, HTTP referer chains, downloads from myfiles2.download) and isolate affected endpoints
• Train staff about SEO/AI-summary poisoning and instruct verification of source domains before following how-to search results

The campaign reminds us that "download from the official site" should go hand in hand with "make sure you're really on the official site." When AI summaries and SEO tricks mix, that verification step is critical.

Christmas Chaos: 767 CVEs, 2.5 Million Requests, and OAST Callback Validation

GreyNoise Intelligence documented ColdFusion++ Christmas Campaign, a coordinated initial access broker operation that exploited 767+ CVEs across approximately 47 technology stacks during the December 25–28, 2025 holiday period.

The campaign generated over 2.5 million requests targeting organizations in more than 20 countries (United States received the majority of attack traffic). The attackers used OAST (Out-of-Band Application Security Testing) callbacks via ~10,000 Interactsh domains (*.oast.pro, *.oast.site, *.oast.me, *.oast.online, *.oast.fun, *.oast.live) to verify successful exploitation before selling or leveraging access.

Key technical details:

• Primary threat actor IPs: 134.122.136.119 and 134.122.136.96 (AS152194, CTG Server Limited, Japan-based)
• CVE coverage: Adobe ColdFusion (CVE-2023-26359, CVE-2023-38203/04/05, CVE-2023-44352/53, CVE-2023-29298/300, CVE-2023-26347, CVE-2024-20767), Atlassian Confluence (CVE-2022-26134), Oracle WebLogic (CVE-2017-10271), Apache Struts 2, and ThinkPHP (among dozens of others)
• JA4T/JA4H fingerprints: Published for network-level detection
• GitHub repository: GreyNoise released supplemental data with full IOC lists

The campaign's timing (Christmas holiday) and breadth (767 CVEs) suggest a professional initial access broker building a target list for ransomware operators or other follow-on actors. The use of OAST callbacks is a hallmark of automated vulnerability validation, as attackers don't waste time on false positives; they confirm exploitability before pivoting.

For defenders:

• Block primary threat actor IPs: 134.122.136.119 and 134.122.136.96
• Block or monitor traffic to/from AS152194 (CTG Server Limited)
• Implement DNS blocklists for Interactsh OAST domains: *.oast.pro, *.oast.site, *.oast.me, *.oast.online, *.oast.fun, *.oast.live
• Review network and DNS logs for December 25–28, 2025 for connections to listed IOC IPs and domains
• Ensure Adobe ColdFusion and other targeted products are patched against 2023–2024 CVEs
• Monitor for JA4T/JA4H fingerprints associated with the campaign (documented in the GreyNoise report)

The scale and professionalism of this campaign highlights the importance of patching legacy vulnerabilities and monitoring for reconnaissance activity during holiday periods when SOC staffing is reduced.

Threat Actors Actively Targeting LLMs: SSRF via Ollama Model Pulls and Enumeration of 73+ LLM Endpoints

GreyNoise documented two distinct campaigns targeting LLM infrastructure between October 2025 and January 2026, with 91,403 attack sessions recorded in honeypots:

Campaign 1: SSRF Exploitation via Ollama and Twilio

Attackers exploited SSRF vulnerabilities in Ollama's model pull functionality and Twilio SMS webhook integrations, using OAST callback validation to confirm successful exploitation. The attack chain:

1. Malicious model pull URLs in Ollama trigger SSRF, allowing attackers to probe internal networks
2. Twilio webhook manipulation enables similar SSRF against internal endpoints
3. OAST callbacks (*.oast.live, etc.) validate that the SSRF reached attacker-controlled infrastructure

Campaign 2: LLM Endpoint Enumeration (80,469 sessions)

A detailed enumeration campaign hit over 73 LLM model endpoints (OpenAI, Anthropic, Meta, DeepSeek, Google, Mistral, Alibaba, xAI) to identify and map AI deployments. It used specific fingerprinting queries (like "How many states are there in the United States?") and fired off quick requests to multiple model endpoints.

The infrastructure overlaps with IPs tied to CVE-2025-55182 (React Server Components RCE) and CVE-2023-1389 exploitation, suggesting the LLM enumeration feeds into a broader exploitation pipeline.

For defenders:

• Configure Ollama to accept models only from trusted registries and implement egress filtering to prevent SSRF callbacks
• Block OAST callback domains at DNS level (*.oast.live, *.oast.me, *.oast.online, *.oast.pro, *.oast.fun, *.oast.site, *.oast.today)
• Alert on rapid-fire requests hitting multiple model endpoints and fingerprinting queries
• Rate-limit traffic from suspicious ASNs including AS152194, AS210558 (1337 Services GmbH), and AS51396 (Pfcloud UG)
• Monitor for JA4H fingerprint po11nn060000 associated with SSRF campaign tooling
• Update Ollama to version 0.7.0 or later to address known RCE vulnerabilities
• Patch React Server Components to version 19.2.3 or later to address CVE-2025-55182

The GreyNoise research provides first-party honeypot telemetry with direct observational data, specific IOCs, and JA4 fingerprints ready for immediate deployment. Organizations running exposed LLM endpoints should treat this as a wake-up call to implement egress filtering, block OAST domains, monitor for enumeration patterns, and patch immediately. And, perhaps, consider if you actually need to expose those endpoints to whole world.

Linux SSH Servers Under Siege: P2PInfect, XMRig, ShellBot, and XorDDoS

AhnLab ASEC's Q4 2025 honeypot analysis documents large-scale brute-force compromise of poorly managed Linux SSH servers. The report identifies the most prevalent malware families installed post-compromise:

• P2PInfect worm (majority of installs): Self-propagating malware that spreads via SSH brute-force and known vulnerabilities
• Coin-miners: XMRig, Prometei, and P2PInfect variants for cryptomining
• DDoS bots: ShellBot (RUBYCARP, IRC-based C2), XorDDoS

Observed post-compromise behaviors include automated download/execution of payloads via curl | sh pipelines, IRC-based C2 for ShellBot, and cryptomining/DDoS operations. The report includes actionable IOCs (IP addresses, URLs, MD5 hashes) and confirms actor-level reuse of infrastructure also documented by Sysdig in their RUBYCARP analysis.

For defenders:

• Disable SSH password authentication; enforce key-based auth and use strong, unique keys
• Harden SSH exposure: change default port if required, implement rate-limiting (fail2ban/sshguard), and block country/IP ranges tied to mass scanning where acceptable
• Deploy host-based detection for anomalous miner/DDoS binaries and monitor for execution of curl/wget | sh pipelines and suspicious cron jobs
• Use fail2ban/sshguard or equivalent to block repeated login failures and integrate with network blocklists
• Apply runtime detection (e.g., Falco/YARA) for known indicators and behaviors (suspicious ELF execution, IRC client activity, unusual outbound connections)
• Treat identified IOCs as indicators of compromise and block/monitor them in perimeter and EDR tooling

The fundamentals remain the same: weak SSH credentials are an existential risk for Linux infrastructure. If you're still using password authentication or haven't changed default credentials, you're already a statistic in someone's honeypot report.

RMM Tools Being Distributed Disguised as Video Files

AhnLab documented a phishing campaign using PDF attachments that lure users to fake Google Drive pages distributing legitimate Remote Monitoring & Management (RMM) installers (Syncro, NinjaOne, SuperOps, ConnectWise ScreenConnect) and NSIS downloaders. The installers and downloaders were code-signed with a certificate used by the threat actor since October 2025.

The campaign doesn't deliver traditional malware, it delivers legitimate RMM tools that attackers then use for covert remote access and post-intrusion control. Once installed, the RMM agents grant attackers persistent access, increasing the risk of lateral movement and ransomware deployment.

The code-signing certificate validates the binaries, which helps them bypass application allowlisting and user warnings. The fake Google Drive pages are convincing enough to trick users into thinking they're downloading a legitimate file shared by a colleague or partner.

For defenders:

• Treat unexpected invoice/payment PDFs as potential lures; do not follow embedded "drive" links or download suggested installers
• Block or monitor listed domains and URLs at the web proxy (specific domains documented in the AhnLab report) and investigate any successful connections
• Allowlist RMM installer hashes and publisher certificates centrally; require MSP vendor attestations before installing RMM software
• Implement endpoint application allowlisting and block execution of unsigned/unknown NSIS installers
• Enable EDR detection for post-installation behaviors (unexpected remote-control processes, unusual outbound C2 to RMM backends), and hunt for the MD5 hashes listed in the report
• Enforce least privilege and multi-factor authentication for remote-management accounts; monitor for new or anomalous RMM customer IDs/keys
• Train users to verify senders and verify attachments by out-of-band channels; treat Google Drive-style previews that redirect to download pages as suspicious

The abuse of legitimate RMM tools is a growing trend in ransomware and intrusion operations. The tools are designed for remote access and command execution; exactly what attackers need for hands-on-keyboard activity.

Closing Thoughts: Verification Over Trust

This week's stories remind us to double-check our assumptions about what we rely on and trust. We think search results are legit just because they show up on the first page. We believe emails are safe if they don’t look suspicious. We assume signed binaries are harmless. And we trust our SSH servers are secure just because they’re behind a firewall (spoiler: they’re not).

The defensive playbook should switch from just blocking to checking things out first. Manually verify search result domains. Check QR code destinations before you scan them. Make sure your SSH authentication uses key-based access and is MFA-protected. Also, confirm that every RMM tool installation is authorized and monitored.

Patch your ColdFusion instances. Secure your SSH servers. Block those OAST callback domains. And hey, treat every email with a QR code like it’s a phishing attempt until you know for sure it’s safe.

The attackers are automating at scale, and the only way to keep up is to automate your defenses, but with verification baked in at every layer.

-- KryptoKat