Fortian

Attackers are making Microsoft send their phishing emails for them - and the lures have been localised for Australia. We've been tracking a campaign where threat actors inject social engineering content directly into legitimate Microsoft security notifications by abusing Entra ID tenant branding. The emails pass SPF, DKIM and DMARC because they genuinely originate from Microsoft infrastructure. No malicious URL, no attachment, no conventional IOC. The payload is a phone number. Your mail gateway already trusts the sender. Your users already expect the template. That's the problem. Full write-up on our site covers the mechanism, what to hunt on, and why your service desk might be the only layer that catches this: https://lnkd.in/gvjRePJC #CyberSecurity #ThreatHunting #EmailSecurity #Phishing #BlueTeam #InfoSec

In July, two frontier AI labs disclosed that their own models had escaped evaluation environments and compromised live production systems belonging to other organisations. OpenAI's reached Hugging Face. Anthropic conducted a review and found three incidents. The interesting part is not just the the AI angle but also how the compromises happened: weak passwords, unauthenticated endpoints, an unpatched proxy, flat networks between test and production. Nothing an autonomous attacker did in July required anything a human attacker has not been doing for twenty years. Open-weight models are now four to seven months behind the closed frontier on offensive cyber tasks, and their safeguards can be quickly removed. That gap is your preparation window, and the preparation is the same unglamorous hygiene it has always been. Our July update also covers the 90,000 Australian firms that became Privacy Act entities on 1 July under AML/CTF Tranche 2, exploitation timelines collapsing to hours, and the month's Australian incidents. https://lnkd.in/gu7HJ4MR

Over the past two weeks Fortian has tracked three tax-themed phishing campaigns staging credential harvesting pages and malware loaders on Vercel, Cloudflare Workers and Netlify. Fake ATO PDFs, a UPS shipment lure, cloned myGov login pages. The platforms themselves aren't compromised. Attackers are just using free-tier accounts to deploy from clean, trusted domains that URL reputation filters wave through. And when the payload is a legitimate RMM tool like ScreenConnect or LogMeIn rather than commodity malware, EDR has nothing to flag either. Instant deployment, auto-TLS, no identity verification. Disposable infrastructure that borrows the platform's reputation. Full write-up with KQL hunting queries and IoCs so you can look for this in your own environment: https://lnkd.in/gDzzknuA #CyberSecurity #ThreatHunting #InfoSec #KQL #Sentinel #BlueTeam #Phishing

SSPR enumeration campaign: In the past week, Fortian has observed a significant increase in authentication method enumeration via malicious self-service password reset attempts. Between July 15 and August 3, we observed an 80x increase in unsuccessful password reset attempts targeting Entra ID accounts across multiple organisations and industry verticals. Each IP initiated 2-3 resets per target account before rotating. Why threat actors do this: Attackers trigger SSPR not to complete the reset, but for pre-attack reconnaissance. The SSPR flow surfaces a partially masked list of verification methods registered to an account (e.g. "text a code to +61 4XX XXX 123") before any authentication happens. This lets an attacker: Confirm a username is valid Identify whether weak factors like SMS or voice OTP are enabled Map exactly which channel to target next: SIM-swap, MFA fatigue, or help-desk social engineering This reconnaissance feeds directly into execution. Why this is a valuable signal for SOC teams: This activity is rarely actionable on its own, but is a high-value leading indicator of impending account takeover. We use it to: Detect attacker pre-positioning before the actual compromise attempt Notify help desk teams to anticipate social engineering calls referencing password resets Identify accounts with weak MFA methods so we can remediate before exploitation Correlate with subsequent sign-in anomalies to build high-confidence attack narratives Knowing which accounts are being actively reconnoitred allows us to perform targeted threat hunting against those identities, looking for phishing emails delivered to the same user, brute force attempts, or anomalous sign-ins that may otherwise blend into noise. This is a core part of our alert correlation strategy: combining non-actionable signals with actionable events to surface real threats earlier. Sample IOCs: 151.240.214.55 151.240.216.89 151.240.217.139 151.240.218.120 151.240.218.171 151.240.220.142 151.240.220.202 151.240.222.230 151.240.224.36 151.240.224.80 151.240.224.106 66.93.162.86 66.93.162.235 66.93.163.70 66.93.163.152 66.93.163.158 66.93.167.141 74.0.96.60 74.0.96.69 172.96.7.67 209.101.149.55 94.229.219.119 57.131.5.113 51.161.56.120 51.81.203.19 15.204.90.62 158.69.216.112 SSPR enumeration is a quiet, often-overlooked precursor to identity compromise. If your SOC isn't monitoring for interrupted password reset flows from hosting infrastructure, you're missing the reconnaissance phase entirely. Fortian detected and correlated this campaign across all managed environments within the first hours of the volume spike. We used this as a valuable signal to perform targeted threat hunting and to work with customers to help their security teams anticipate potential helpdesk phishing attacks.

Fortian is tracking a resurgence in phishing campaigns using IPFS-hosted credential harvesters with Telegram bots as the exfiltration backend, actively targeting ASX-listed organisations across multiple industry verticals. The combination gives attackers free, resilient hosting and instant delivery of stolen credentials, with no server infrastructure of their own to seize or take down. Here's what we found Lure and delivery. Victims receive an email impersonating their own organisation's IT admin, with the subject line "Admin [target organisation domain] Sent you a ShareFile Document." The sender display name is spoofed to appear internal, pushing urgency around a shared file notification. IPFS-hosted phishing kit. The credential harvesting page is hosted on IPFS and served through a public gateway, with the target's email address passed as a base64-encoded or plain-text URL parameter. There is no traditional domain or hosting provider to take down; the content is content-addressed and pinned across the IPFS peer network. Dynamic brand impersonation. The kit extracts the domain from the victim's own email address and uses it to dynamically build a convincing fake portal in real time, chaining together three legitimate third-party public APIs: a logo lookup service, a favicon service, and a URL screenshot API used to render a live-looking screenshot of the victim's actual company website as the page background. No static template per target org is needed; the same kit convincingly impersonates any organisation purely from the victim's email domain. Anti-analysis tradecraft. The page includes a debugger; timing loop to detect an attached debugger, blocks common devtools shortcuts and right-click, and polls window.outerWidth/innerWidth deltas to detect docked browser devtools panels, redirecting to about:blank if triggered. Telegram bot exfiltration. Submitted credentials, along with the victim's IP, approximate geolocation, and user agent, are POSTed directly to the Telegram Bot API sendMessage endpoint, delivering harvested credentials straight to the operator's Telegram client in real time. After three submissions, the victim is silently redirected to their organisation's real website, reducing suspicion. Fortian identified and actioned this campaign across managed environment. We detected this through custom alerts for connections to ifps and telegram infrastructure. If your organisation is ASX-listed and you want to know whether you have been targeted in similar campaigns, reach out at fortian.com.au. A technical break down of the campaign and IoCs can be found here: https://lnkd.in/gva-X72r

Novel device code phishing campaigns are forcing security teams to rethink identity incident response. Is your team equipped to handle modern identity compromise? Recent device code phishing campaigns are exposing a gap in how most security teams respond to identity compromise incidents. The standard playbook of "reset password, revoke sessions, re-enable" is no longer sufficient, and the reasons why aren't always obvious. What's changed Active threat clusters are now using phishing kits that weaponise legitimate OAuth device code flows in Entra ID. When a victim completes the device code authentication flow, the attacker receives valid tokens and immediately automates device registration in Entra ID. This gives the actor a Primary Refresh Token bound to their registered device. If the attacker provision a Windows Hello for Business (WHFB) key on that device - a hardware-bound asymmetric credential that replaces password-based authentication - they now hold a credential that survives password resets entirely. The WHFB private key is stored on the device and used to prove identity directly to Entra ID without presenting the user's password, meaning a password reset has no effect on its validity. Why existing playbooks don't work - three gotchas that might catch teams out: 1. WHFB key persistence. If the attacker registered a device and provisioned a WHFB key, resetting the password won't evict them. They can re-authenticate without the user's password by using the WHFB key to obtain new PRTs and mint fresh access tokens. 2. Application session tokens are self-contained. For apps that don't support CAE (most third-party SaaS), already-issued session cookies survive password resets and session revocation - Entra ID cannot reach in and invalidate them so they ride out their natural lifetime. This is where sign-in frequency policies reduce the exposure window. 3. Timing matters. If you re-enable the account before those tokens expire, you've told the user they're safe while the attacker still holds valid sessions. What IR teams need to do - Disable the account. - Remove any attacker-registered devices and MFA methods from Entra ID. - Validate whether CAE is enabled for the apps the actor accessed. - Revoke sessions (twice for hybrid identities) and reset credentials. - Force re-authentication on all apps if CAE coverage is incomplete. The order matters. If you reset the password but leave the registered device, the attacker could still hold a valid authentication method that allows them to re-obtain a primary refresh token. Identity compromise response is no longer just a credential problem - it's a token and device trust problem. If your playbook hasn't evolved to match, now is the time.  

Fortian recently identified a sophisticated phishing campaign attributed to TA4922 by ProofPoint actively targeting Australian organisations. This is notable as this - to our knowledge - is the first documented evidence of this particular TA4922 campaign targeting organisations in Australia. The malware payload also evaded detection by EDR at every stage of the kill chain. It was identified by Fortian's detection rules through monitoring for anomalous DLL sideload events and unusual outbound network communication from svchost.exe.

The best fraud campaigns aren't invisible. They just look exactly like your customers. Threat actors aren't creating thousands of fake accounts just for the sake of it. They're abusing sign-up incentives, laundering stolen payment cards through "legitimate" customer accounts, bypassing purchase limits, and scaling attacks that generate real financial impact. The infrastructure behind these campaigns has evolved: Residential proxy networks, realistic identities, legitimate phone numbers, and genuine browser fingerprints. Every sign-up is engineered to blend into normal customer traffic and evade bot protection. At that point, the limitation isn't your SIEM. It's that there simply isn't a reliable query that separates these campaigns from legitimate customer activity without overwhelming analysts with false positives. But operating at scale leaves one thing an actor can't eliminate: structure. That's why, at Fortian, we develop bespoke machine learning models that identify the subtle behavioural patterns left behind by high-volume fraud campaigns - even when every individual event appears legitimate. Our latest blog explores why rule-based detection reaches its limits, how sophisticated multi-accounting campaigns evade traditional detection, and how behavioural clustering helped uncover attacks specifically designed to remain hidden. Read the full blog from Tristan Bunnage here: https://lnkd.in/gDspc-TG #CloudSecurity #ThreatDetection #MachineLearning #FraudDetection #ThreatHunting

June was defined by AI on both sides of the fight: the Five Eyes warned boards it is a present business risk, the FBI dismantled a China-based AI-powered phishing service blamed for $1.9 billion in losses, and the US forced Anthropic and OpenAI to restrict their most capable models. Identity stayed the weakest link, with ShinyHunters exploiting an Oracle PeopleSoft zero-day against 100+ organisations and FortiBleed compromising 75,000 devices. Australia moved to retire the Essential Eight, updated the ISM, and ordered Amex to overhaul access controls after an insider breach. Read the full analysis by SOC Analysts Allan Grant here: https://lnkd.in/gxMJUzKD

Fortian's threat hunting team has identified a live FortiBleed-linked campaign that has moved beyond credential reuse. Attackers are now using AI-generated credential lists, and the evidence sits in plain sight in the usernames themselves: emoji characters, curly quotes, non-Latin scripts, and alphabetical enumeration patterns no human attacker would produce. Combined with residential proxy infrastructure and ties to Russia-nexus attribution, this signals a meaningful shift in how password spraying campaigns are built. Read the full technical breakdown, including hunting queries for Sentinel and sanitised IoCs.