← Back to Blog

Threat Research

Kali365 Ringer: Targeting Financial and Insurance Sectors

A Kali365 device-code phishing campaign targeted financial and insurance firms via voicemail lures, Google Sites, and Tencent-hosted panel infrastructure.

By ZeroBEC Team · July 14, 2026 · 17 min read

ZeroBEC prevented a Kali365 device-code phishing attack targeting a financial, regulated customer environment. The lure used a missed-call notification and a trusted Google Sites wrapper before redirecting through Google redirector, OCI API Gateway, and a Cloudflare-protected Kali365 host. The campaign targeted multiple organizations on the same day, including financial and insurance services customers, using the same Google Sites landing page, sender subdomain, subject pattern, and fake internal reference ID.

Executive summary

Public reporting from Huntress and the FBI IC3 Kali365 PSA has already characterized Kali365 as a device-code phishing ecosystem with Tencent AS132203 infrastructure, panel variants, lure templates, token workflows, API routes, and operator tooling, and as a PhaaS platform that captures Microsoft 365 OAuth tokens and bypasses MFA without intercepting user credentials.

ZeroBEC's additional contribution: we observed a Google Sites voicemail wrapper that handed off to OCI API Gateway and then to the Kali365 lure, tracked the authentication IPs on a controlled account, and pivoted from a Microsoft Authentication event at 170[.]106[.]39[.]48 to a Kali365 panel. The exposed panel bundle contained direct Kali365 Live branding, Windows/macOS installer paths, Token Vault, Lures, Inbox, B2B Sender, Email Extractor, Domains, Help Center, Live Browser, Admin Control, and Agent Dashboard workflows.

Identity telemetry showed evasion patterns: the first successful connections used Charter/Spectrum fixed-line residential IPs, consistent with geography-aware proxy selection to blend with expected user-region activity. The same timeline then showed interrupted MFA/device-code activity from 170[.]106[.]39[.]48, the Tencent-hosted IP that led to the panel discovery.

Key findings

• Confirmed attack type: Kali365 Microsoft 365 device-code phishing, high confidence.
• Primary lure: missed voicemail / internal communications notification, first displayed on Google Sites.
• Multi-target evidence: the same Google Sites URL, same sender subdomain, same fake reference ID, same subject pattern, and same delivery day were observed across financial and insurance services targets.
• Device-code abuse: the user was instructed to authorize an attacker-controlled device-code session through Microsoft rather than submit a password to a fake login page.
• Kit fingerprints: ts_ok cookie name, /l/<token> route, /api/status/<integer> polling, /api/generate device-code generation, Cloudflare challenge layer, device_code flow, cookies capture mode, and voicemail template.
• Panel findings: exposed React/Vite asset /assets/index-CKp2C-k5[.]js included Kali365 Live branding, installer paths, and operator workflows for token, lure, mailbox, sender, domain, and agent management.

Observed attack chain

The first visible URL was not the final phishing application. It was a small Google Sites voicemail page that used Google redirector to hand the victim to an OCI API Gateway trampoline and then to a Cloudflare-protected Kali365 lure. This layering made the first click appear low risk and reduced scanner reliability.

Email delivery and control bypass context

The email contained no attachment and relied on link chaining, identity workflow abuse, and cloud hosting reputation rather than malware delivery. It was authenticated through Amazon SES at the upstream handoff and reached the customer environment protected by a mature secure email gateway and Microsoft 365 controls. The customer gateway is relevant as defensive context, not attacker infrastructure.

The result is the core problem this case illustrates: a well-regulated and hardened environment can still receive an inbox-delivered identity lure when the attack blends authenticated cloud email, generic business language, trusted web hosting, and a legitimate Microsoft authorization workflow.

Same-day multi-target reuse

A second sample observed the same day reused the same sender subdomain, subject pattern, Google Sites page, and reference ID against an insurance-services target. Combined with the financial-services customer case, this supports a multi-target campaign assessment without naming the affected brands.

• Shared Google Sites first-stage: hxxps://sites[.]google[.]com/view/ringer-55632/home.
• Shared fake reference: ADM-20260330-X9.
• Shared sender subdomain: speechbox[.]*******[.]com.
• Shared lure language: missed call / internal communications / View Call Details.
• Shared delivery day: July 9, 2026.

Kali365 lure behavior

The phishing host presented a voicemail-themed page and generated a Microsoft device verification code. The page did not host a fake Microsoft password form. Instead, it attempted to make the user authorize attacker-controlled access through Microsoft device-code authentication. This is the core defensive challenge: the visible authentication surface can be legitimate while the session being authorized is controlled by the attacker.

Device-code generation endpoint

The panel also exposed a device-code generation response. The JSON returned success, a numeric session_id, a 900-second expiry, a user_code field, and Microsoft device authorization fields. The live code and legitimate Microsoft URLs are redacted in the figure because they are not useful IOCs and may identify a specific analysis session.

Authentication telemetry and panel discovery

ZeroBEC tracked the authentication IPs observed on a controlled account. The timeline showed successful and failed Microsoft Authentication activity from fixed-line Charter/Spectrum IPs, followed by interrupted MFA/device-code activity from 170[.]106[.]39[.]48. Investigating the 170[.]106[.]39[.]48 authentication source led to the exposed Kali365 panel.

The fixed-line ISP activity is important. The attackers did not rely only on obvious cloud infrastructure. They used residential fixed-line geolocation as an early access layer, apparently to make first connections blend with user-region expectations, then interacted with device-code and panel infrastructure from Tencent AS132203.

Panel and infrastructure pivots

The panel pivot should be interpreted as an infrastructure and implementation correlation, not as a single-IP attribution claim. The strongest host was 170[.]106[.]39[.]48 because it combined Microsoft authentication telemetry, Tencent AS132203 location, exposed Panel title, historical Shodan context, and the recoverable Kali365 panel bundle.

Recovered Kali365 panel bundle

Although the panel was protected by authentication, it exposed a public React/Vite JavaScript asset under /assets/index-CKp2C-k5[.]js. Recovering and reviewing that asset provided the panel navigation model, help content, operator workflows, Kali365 Live branding, installer paths, and feature labels. The CSS was useful for visual reconstruction, but the JavaScript carried the operational evidence.

Panel functionality observed in the bundle

The panel functionality goes well beyond a device-code landing page. The Help Center and UI labels read like an operator playbook for capture, token management, mailbox access, sending, domain rotation, and reseller operations. The most important defensive observations are summarized below. Similar operator productization is visible in the Forg365 platform, which exposes Token Vault, AI lure generation, and Cloudflare Worker deployment inside a Telegram-distributed panel.

Operator Help Center artifacts

The exposed Help Center shows how operationalized the kit is. It gives operators troubleshooting paths for anti-bot behavior, domain flagging, SSL issues, token revocation, and email-send failures. These details are particularly valuable because they explain why automated detonation may see blank pages, Microsoft redirects, or transient domains rather than the full phishing workflow.

• Lure page not loading: the Help Center states that anti-bot protection blocks scanners, VPNs, and known security crawlers, and suggests regular browsers, mobile cellular access, cache clearing, or incognito browsing.
• Domain flagged: when Google Safe Browsing or Microsoft SmartScreen burns a domain, operators are told to rotate the CF Worker or switch to a new domain; old lure URLs are considered dead.
• SSL issue: linked domains have an SSL reprovisioning flow, while CF Workers rely on automatic SSL and redeployment.
• Emails not sending: send jobs are tied to token state, recipient validity, Microsoft rate limiting, and job processing state.
• Token revoked: revoked tokens are treated as unrecoverable; the operator guidance points back to a fresh capture from the target.

Public baseline vs. ZeroBEC additions

Huntress and the FBI established the public baseline for Kali365: a device-code phishing ecosystem that abuses Microsoft OAuth/device authorization, captures tokens, and runs through a commercialized PhaaS panel. ZeroBEC's case adds a field-level view of how the lure reached a hardened customer environment and how the operator infrastructure was recovered from identity telemetry.

Static artifact findings

• The PDwLJY20PmA artifact is a reusable lure builder, not a simple redirect page.
• The decoded configuration includes design=voicemail, flow_type=device_code, capture_mode=cookies, and a benign voice/collaboration exit theme.
• The script creates the device-code experience, displays a verification code, and polls backend status endpoints.
• The page uses obfuscation and Cloudflare challenge behavior to slow or disrupt automated analysis.
• The exposed panel bundle contains Kali365 Live branding, Windows/macOS installer paths, and workflows for Token Vault, Lures, Inbox, B2B Sender, Email Extractor, Admin Control, Domains, Help Center, Live Browser, and Agent Dashboard.

Indicators of compromise

All textual indicators below are defanged. Legitimate Microsoft device authorization URLs, Google resource URLs, Cloudflare challenge URLs, and benign exit URLs are intentionally omitted from the IOC list. The attacker abused them as part of the chain, but they are not useful block indicators in isolation.

Malicious or suspicious URLs and patterns

Domains, IPs, and kit fingerprints

Recommended customer actions

• Confirm the email was removed or quarantined from all recipients and search for the same sender, subject, Message-ID, lure token, and fake reference ID.
• Search DNS, proxy, browser, EDR, and firewall logs for the defanged chain listed in the IOC section.
• Review Entra sign-ins for targeted users and adjacent recipients from the first delivery time through the following 24 hours.
• Look for device-code transfer method, Microsoft Authentication Broker, Microsoft Authentication, unexpected successful sign-ins, interrupted MFA, Python Requests 2[.]34, AS132203, and the IPs listed in this report.
• Revoke sessions and refresh tokens for any account that interacted with the lure or shows suspicious device-code activity.
• Remove or disable any Entra ID device objects that were registered around the incident window and cannot be tied to a known user or corporate enrollment. Device-code phishing frequently ends with the attacker registering their own device so refresh tokens survive credential resets; revoking sessions alone does not remove that persistence.
• Review OAuth consent grants, registered devices, inbox rules, forwarding, mailbox delegation, Teams access, OneDrive access, and Graph activity for affected accounts.
• Restrict device-code flow through Conditional Access unless there is a documented business need and a scoped exception.

Conclusion

This campaign is best described as a Kali365 Ringer attack: a voicemail-themed Microsoft 365 device-code phish that used Google Sites, Google redirector, OCI API Gateway, Cloudflare, and Kali365 panel infrastructure to move from inbox delivery to identity authorization. The case reinforces the main public lesson from Huntress and the FBI: device-code phishing is an identity-control problem, not a password-form problem. ZeroBEC has documented the same identity-control pattern in adjacent campaigns, including DEBULL, where the attacker sessions ended in a GraphSpy-Device object, and Forg365, where the operator platform pairs device-code phishing with a Manifest V3 browser extension that refreshes Microsoft SSO cookies from the attacker side.

The operational lesson is sharper. This customer had a well-regulated, highly hardened Microsoft 365 environment and an advanced Mimecast secure email gateway in front of the mailbox. The email still reached the inbox because the attacker combined authenticated cloud email, generic business language, trusted first-stage hosting, cloud trampolines, anti-bot controls, residential geolocation, and a legitimate Microsoft authorization workflow.

That is why ZeroBEC is AI-native. Static blocklists, sender authentication, SEG scoring, and URL reputation are necessary but insufficient. Attackers will continue to find paths through trusted infrastructure and legitimate identity workflows. The defensive layer must understand how the organization normally communicates, how different users interact, what each user's baseline looks like, which relationships are normal, how link chains behave in context, and when an email or identity event is anomalous even if every individual artifact looks plausible.

ZeroBEC prevented the lure from remaining available to the user and preserved the evidence needed to connect the email, browser chain, cloud trampoline, authentication telemetry, panel infrastructure, and exposed Kali365 operator workflows into a single attribution story.

Ready to see how ZeroBEC protects your organization? Start free or contact us.