Cyber Defense Center

Threat Insights – June 2026

CRITICAL · SUPPLY CHAIN ATTACK
IT Backup Service Provider Portal Compromise: Supply Chain Attack Results in Ransomware

A supply chain attack was identified involving a well known IT backup service provider, a widely used cybersecurity and backup platform. A third-party provider was managing the client’s backup environment remotely through their own MSP portal, which held Super Administrator privileges over the client’s endpoints.

The vendor’s Super Administrator account lacked Multi-Factor Authentication (MFA), creating a critical security gap entirely outside the client’s direct control. A threat actor exploited this weakness, gaining access to the vendor’s service provider portal via infrastructure operating over the Tor network.

Using the trusted MSP-level privileges, the attacker traversed from the vendor’s portal directly into the client’s managed environment and deployed a malicious PowerShell script across endpoints, resulting in ransomware execution. Observed indicators of compromise correlate strongly with the Payload Ransomware threat group.

The client had no direct visibility into this activity, as the attack path ran entirely through the vendor’s administrative layer before reaching their environment.

Notably, the client’s own environment had MFA enforced, demonstrating that their internal security posture was sound. However, this control was rendered ineffective because the attack never came through the client’s own access layer. It bypassed it entirely through the vendor’s compromised portal, highlighting that strong internal controls alone cannot protect against a compromised trusted third party.

Supply Chain Attack Timeline
Remediation Steps
  • Secure Privileged Accounts
  • Enforce third-party and vendor security assessments
  • Strengthen Endpoint Detection
  • Validate Third-Party Changes

HIGH – FINANCIAL IMPACT
Compromised 3CX Account Leads to International Toll Fraud

A compromised 3CX account was exploited by a threat actor to place multiple unauthorized international calls, resulting in significant financial impact due to fraudulent telephony charges. The investigation revealed that a user’s 3CX VoIP account was compromised, allowing an attacker to gain unauthorized access to the organization’s telephony system. The threat actor used the compromised account to initiate numerous international calls to premium-rate and overseas destinations over a short period.

The unauthorized activity remained undetected until an unusually high telecom bill triggered further investigation. The incident highlights the financial risks associated with compromised VoIP accounts and emphasizes the importance of securing unified communication platforms with strong authentication, access controls, and continuous monitoring.

Supply Chain Attack Timeline
Remediation Steps
  • Enforce MFA on VoIP Accounts
  • Monitor Call Logs for Anomalies
  • Restrict International Calling
  • Implement Telephony Fraud Alerts

PROACTIVE · SECURITY ADVISORY
Ghost Sender Assessment

The CDC team proactively assessed customer environments for exposure to the recently disclosed Ghost Sender email spoofing technique. The assessment evaluated exploitation feasibility and identified mitigation controls, including the implementation of Microsoft Exchange Online transport rules to detect and block unauthorized email scenarios.

Customers are encouraged to review their email security configurations and apply the recommended controls to strengthen protection against this attack vector.

Recommended Actions
  • Start with an audit phase before applying any blocking controls.
  • Use an Exchange Online mail flow rule to identify emails delivered directly to Microsoft 365/EOP.
  • Capture direct-delivery sender domains, source IPs, third-party services, and legitimate business exceptions.
  • Build a validated allowlist of approved direct-delivery sources.
  • Build a validated allowlist of approved direct-delivery sources.
  • After validation, implement enforcement to prevent unauthorized direct-to-Microsoft 365 email delivery.
  • This option provides the best balance of security, flexibility, phased rollout, manageability, and message trace visibility.
  • Final enforcement should be based on audit findings to avoid disruption to legitimate email flows.

Threat Detection Engineering

Threat Insights – June 2026

As ransomware operators continue to refine their tactics and threat actors increasingly abuse legitimate tools to fly under the radar, the Threat Detection Engineering team has expanded detection coverage to address some of the most active threat groups and commonly exploited attack surfaces. This month’s release delivers targeted detections across the full attack lifecycle — from initial driver abuse and lateral movement to persistence and defense evasion.

Additionally, the team has completed a critical infrastructure migration for the Threat Intelligence pack on Microsoft Sentinel, ensuring continued indicator-based detection as the platform evolves its data model.

What’s New This Release

7 New Detection Rules

DragonForce, Rogue Planet & FortiBleed use cases now active in Global

Threat Intel Pack Updated

Migrated from deprecated
ThreatIntelligenceIndicators to new
ThreatIntelIndicators table on Sentinel

New Detections – Detailed Breakdown
DragonForce Use Case: Privilege Escalation via BYOVD Driver Load
Rule Name: Global: Privilege Escalation: DragonForce: BYOVD Vulnerable Driver Load Detected
Priority: P2 (High)
Type: AUTO | New Detection
Scope: Global
Overview
This detection identifies DragonForce ransomware’s use of the Bring Your Own Vulnerable Driver (BYOVD) technique, where a known-vulnerable kernel driver is loaded to gain elevated privileges and disable security controls. This technique allows the attacker to operate at the kernel level, bypassing user-mode security products and enabling subsequent stages of the attack chain.
What It Detects
Loading of a known vulnerable driver associated with DragonForce campaigns, typically used to escalate privileges to SYSTEM level and neutralise endpoint detection and response (EDR) tools running on the host.
Why It Matters
BYOVD is a stealthy, effective method to defeat security tooling before ransomware execution begins. Early detection at the driver-load stage provides the opportunity to stop an attack before encryption or lateral movement can occur.

DragonForce Use Case: C2 Communication via DbgView64
Rule Name: Global: Command and Control: DragonForce: DbgView64 Unexpected External Network Connection Detected
Priority: P2 (High)
Type: AUTO | New Detection
Scope: Global
Overview
This rule triggers when DbgView64 — a legitimate Sysinternals debugging utility — is observed making unexpected outbound connections to external IP addresses. DragonForce operators abuse this tool to blend malicious command-and-control traffic within what appears to be routine system diagnostic activity.
What It Detects
Outbound network connections initiated by DbgView64.exe to external, non-internal destinations that fall outside expected operational baselines — a strong indicator of C2 tunnelling or beaconing behaviour..
Why It Matters
Abusing trusted, signed utilities for C2 is a classic living-off-the-land technique designed to evade network-based detection. Catching this early limits the attacker’s ability to receive instructions and exfiltrate data.

DragonForce Use Case: LimitBlankPassword Security Policy Downgrade
Rule Name: Global: Persistence: DragonForce: LimitBlankPassword Security Policy Downgrade Detected Detected
Priority: P2 (High)
Type: AUTO | New Detection
Scope: Global
Overview
This detection flags changes to the LimitBlankPasswordUse security policy, a Windows setting that restricts the use of blank passwords for network logons. DragonForce modifies this setting to enable lateral movement using accounts without passwords, facilitating access to additional systems across the environment.
What It Detects
Registry or policy changes that disable the blank-password restriction, allowing network authentication with accounts that have no password set — a technique used to pivot across hosts during a ransomware campaign.
Why It Matters
Weakening authentication policy is a precursor to widespread lateral movement. Detecting this downgrade enables responders to intervene before the attacker gains footholds on additional systems.

DragonForce Use Case: DbgView64 Unsigned DLL Sideloading
Rule Name: Global: Defense Evasion: DragonForce: DbgView64 Unsigned DLL Sideloading Detected
Priority: P2 (High)
Type: AUTO | New Detection
Scope: Global
Overview
This rule identifies the sideloading of unsigned DLLs through DbgView64. Attackers place a malicious, unsigned DLL in a location where the legitimate signed binary will preferentially load it, resulting in arbitrary code execution under the guise of a trusted process — a core defense evasion technique in the DragonForce toolkit.
What It Detects
DbgView64 loading a DLL that lacks a valid digital signature, deviating from expected behaviour for this utility. This indicates potential DLL hijacking or sideloading to execute attacker-controlled code.
Why It Matters
DLL sideloading through signed binaries effectively masks malicious activity from many security controls. Detection at this stage can surface ransomware payloads or implants before they fully execute.

Rogue Planet Use Case: Privileged Shell Spawning via Microsoft Defender
Rule Name: Global: Execution: Microsoft Defender: Rogue Planet: Spawning Privileged Shell Processes
Priority: P3 (Medium)
Type: AUTO | New Detection
Scope: Global
Overview
This detection identifies Rogue Planet activity where Microsoft Defender processes are abused to spawn privileged shell processes such as cmd.exe or PowerShell with elevated permissions. Exploiting security products to gain execution represents a high-value abuse scenario that can be difficult to detect through conventional means.
What It Detects
Child processes (command shells or scripting engines) spawned from Microsoft Defender binaries with privileges inconsistent with normal product behaviour, indicating potential exploitation or abuse of the security product itself.
Why It Matters
When security tools become the execution vehicle, standard process-lineage detections are bypassed. Early identification of this pattern prevents attackers from pivoting with high-privilege shells under a trusted parent.

Rogue Planet Use Case: Privileged Shell Spawning via Windows
Rule Name: Global: Execution: Windows: Rogue Planet: Spawning Privileged Shell Processes
Priority: P3 (Medium)
Type: AUTO | New Detection
Scope: Global
Overview
A complementary rule to the Defender-specific detection above, this rule covers the broader Windows execution context — identifying Rogue Planet techniques that leverage native Windows components or processes to spawn privileged shells. Together, these two rules provide comprehensive coverage of this threat actor’s execution methodology across different attack vectors.
What It Detects
Privileged shell or scripting process instances spawned from unexpected Windows parent processes as part of the Rogue Planet kill chain, including abuse of OS-native binaries to obtain elevated command execution.
Why It Matters
Dual coverage across Defender and native Windows vectors ensures that Rogue Planet cannot switch parent processes to evade a single-rule detection. Correlated alerts from both rules significantly increase detection confidence.

FortiBleed Use Case: Fortigate Local User Password Configuration Changes
Rule Name: Global: Audit and Compliance: Fortigate: Local User Password Configuration Changes Detected
Priority: P3 (Medium)
Type: AUTO | New Detection
Scope: Global
Overview
This detection monitors for password configuration changes made to local user accounts on Fortigate appliances. In the context of the FortiBleed vulnerability class — which involves credential exposure or authentication bypass on Fortinet devices — any post-exploitation activity involving local account modification is a critical indicator of compromise and persistence establishment.
What It Detects
Administrative or scripted changes to local user passwords on Fortigate devices as logged in Fortigate audit events. This includes both expected admin activity (for baselining) and anomalous changes that could indicate attacker persistence.
Why It Matters
Fortinet devices are a high-value target due to their network perimeter role. Attackers exploiting vulnerabilities in these devices often modify local credentials to maintain access. Detecting this activity enables rapid response before the foothold is entrenched.

Platform Update – Threat Intelligence Pack Migration

i Sentinel Table Migration: ThreatIntelligenceIndicators → ThreatIntelIndicators

The previously used Microsoft Sentinel table ThreatIntelligenceIndicators is being deprecated by Microsoft as part of Sentinel’s evolving data model. To ensure uninterrupted indicator-based detection, the Threat Detection Engineering team has updated the Threat Intel pack and all associated detection rules to reference the new ThreatIntelIndicators table.

“Staying ahead of the threat means evolving our detection infrastructure in step with the platforms we depend on — not after the fact.”

Summary – June 2026 Activity

This month’s release demonstrates the team’s focus on covering active, high-impact ransomware groups and exploitation tooling alongside critical infrastructure maintenance. The DragonForce use case pack delivers four high-priority detections across privilege escalation, command-and-control, persistence, and defense evasion — covering the majority of the known DragonForce attack chain. Rogue Planet detections add execution-phase visibility across both security product abuse and native Windows paths. The FortiBleed Fortigate rule extends compliance monitoring to network appliance credential changes. Finally, the Threat Intel pack migration to ThreatIntelIndicators ensures detection continuity on Sentinel as the platform transitions its data model.

Threat Management

RoguePlanet: The Defender Privilege-Escalation exploit, How We Defend Against It

SecurityHQ’s Threat Management Team uncovered attackers abusing Microsoft Defender to gain full SYSTEM-level control over protected endpoints. By deploying bespoke detections before Microsoft released patches, we ensured zero impact across all managed tenants.

What is RougePlanet?

RoguePlanet is a local privilege-escalation exploit, a program an attacker runs once they already have a low-privilege foothold, to promote themselves from an ordinary user to NT AUTHORITY\SYSTEM, the most powerful account on a Windows host. What makes it notable is the method: it abuses no software vulnerability and no CVE. Instead, it turns Microsoft Defender a trusted process that runs as SYSTEM into the instrument of attack.

The trick is to make Defender act on a file the attacker controls. The tool plants the harmless EICAR antivirus test string (a file every AV is built to detect), then drives Defender’s own scan-and-clean engine to remove it. Because Defender performs that clean-up as SYSTEM, and because a path-swap race redirects the action at the last instant, the privileged clean-up lands on a target the attacker chooses. The result is full SYSTEM code execution on the host.

Why it matters. Because RoguePlanet rides a trusted feature rather than a vulnerability, there is no patch that closes it and no malicious file signature to block. Defender is working exactly as designed. A sandboxed browser exploit becomes full host compromise, low-privilege malware can self-elevate, and endpoint agents running as the user can be switched off. Any host where this tool is seen should be treated as a confirmed elevation attempt and a likely active intrusion.

How the exploit works

RoguePlanet has a single mechanical core: it wins a timing race against Defender’s privileged clean-up and redirects it. Mapping that sequence is exactly what let us build behaviour-based detection without waiting on any patch:

How we defend

With a working tool that abuses a trusted feature, signature-based protection alone leaves a gap. We focused on the behaviour Defender’s own engine being coerced into an anomalous privileged write and pushed detection content live across every managed MDE tenant:

Detection layer What it surfaces
Non-service process loading MpClient.dll from an unexpected path The core tell — Defender’s client library being driven by something that isn’t Defender. RoguePlanet
Defender install-path registry read followed by shadow-copy enumeration The reconnaissance footprint before the abuse begins — InstallLocation read from user context.
wermgr.exe running from outside System32 The planted payload carrier and its :WDFOO alternate data stream. RoguePlanet
Unexpected on-demand trigger of the QueueReporting task The SYSTEM execution-launch step that converts the planted file into a running process.

Outcome. Behaviour-based coverage that holds regardless of patch status because there is no patch. On any match, our SOC investigates at once, isolates the host where warranted, captures a memory image before power-down (the SYSTEM child process and named pipe are runtime-only evidence), and verifies whether a SYSTEM-level write completed. To date, zero managed tenants have been impacted.

What do we recommend

  • Keep Tamper Protection on. Ensure Defender Tamper Protection and cloud-delivered protection are enforced tenant-wide via Intune or Defender policy, so the protection layer cannot be weakened as part of the chain.
  • Constrain local administrative rights. This is a local-escalation tool — it only matters once an attacker is already running code as a normal user. Reducing standing local-admin access and tightening initial-access controls materially lowers the chance of it ever being reached.
  • Hunt for the host artefacts. Sweep the fleet for the named pipe \\.\pipe\RoguePlanet, any wermgr.exe outside System32, and any file carrying a :WDFOO stream; review which account invoked QueueReporting.
  • Rebuild, don’t clean. Because a successful run yields SYSTEM, treat any confirmed host as fully compromised — rebuild from a known-good image and rotate every credential cached on or used from that host (domain, local admin, browser, and cloud sessions).

Threat Hunting

Hunting for Credential Theft & Identity Attacks: Kerberoasting, DCSync, MFA Fatigue, and Lateral Movement in Active Directory Environments

Hypothesis

SecurityHQ’s Threat Hunting team investigated whether adversaries had obtained or were actively attempting to obtain privileged credentials within the target Active Directory environment by exploiting weak Kerberos encryption configurations, accounts with pre-authentication disabled, domain replication permissions, or MFA control gaps. The assumption driving this hunt: an adversary with even a low-privileged foothold, whether gained through phishing, a credential broker or an MFA fatigue approval, could systematically work through a well-documented attack chain from initial credential harvesting through to domain dominance, leveraging native Active Directory mechanisms throughout and generating minimal noise against conventional alert thresholds. Each technique in this hunt represents a distinct stage of that chain, and the presence of indicators across multiple stages simultaneously would constitute high-confidence evidence of an active, hands-on intrusion.

How the Exploit Chain Works

Credential theft and identity attacks in Active Directory environments follow a consistent, documented progression that threat actors, from ransomware affiliates to nation-state operators, reliably execute once an initial foothold is established:

The full attack chain the team hunted proceeds as follows:

  1. Initial access: The adversary gains entry through phishing, credential stuffing, or MFA fatigue bombing, flooding a target with repeated push notifications until an approval is obtained through fatigue or confusion.
  2. Reconnaissance: With any internal access established, the attacker probes the domain using Kerberos error code distinctions, specifically the difference between KDC_ERR_C_PRINCIPAL_UNKNOWN (0x6) and KDC_ERR_PREAUTH_FAILED (0x18), to silently confirm which accounts exist without triggering lockouts.
  3. Credential harvesting: With a confirmed valid account, the attacker requests Kerberos service tickets for accounts with Service Principal Names set, forcing RC4 encryption to obtain offline-crackable hashes (Kerberoasting), or targets accounts with pre-authentication disabled to extract TGT responses without any password proof (AS-REP Roasting).
  4. AS-REP Roasting: In parallel, accounts with Kerberos pre-authentication disabled are targeted, the domain controller hands out an encrypted authentication response to any requestor without requiring proof of identity, and that response is cracked offline to recover the account password.
  5. Domain takeover: Once a sufficiently privileged account hash is cracked or a session token obtained, the attacker invokes DCSync by abusing the MS-DRSR replication protocol to extract the entire domain credential store, including the krbtgt hash, enabling Golden Ticket creation for persistent, undetectable access.
  6. Lateral Movement: With harvested NTLM hashes or Kerberos tickets, the adversary authenticates to systems across the network under the identity of legitimate users, pivoting toward high-value targets such as file servers, management systems, and backup infrastructure without triggering password-based controls.

Why This Hunt Matters

Credential theft and identity attacks remain the most consistently observed precursor to ransomware deployment and domain-wide compromise across enterprise environments. What makes this attack category particularly dangerous is that each technique in the chain abuses legitimate, built-in Active Directory functionality. Kerberos ticket issuance, directory replication, and NTLM authentication are all standard operations, meaning that without specific, targeted hunting queries, the activity is effectively invisible to conventional alert-based monitoring. Kerberoasting generates no failed login events. DCSync produces no network anomaly. Pass-the-Hash leaves no password entry in logs. The presence of RC4 encryption in the environment and accounts with pre-authentication disabled are not incidents in themselves, but they are the conditions that transform a low-privileged compromise into a domain-wide breach within hours. The username enumeration activity detected represents active reconnaissance against the domain; an adversary or tool is probing for valid account names and has already confirmed at least one dormant administrative account as a valid target, narrowing the attack surface for subsequent credential attacks.

What We Found

Kerberos encryption and pre-authentication posture

Kerberos ticket traffic was analysed across all domain-joined endpoints and domain controllers for the hunt period. Ticket requests using RC4 encryption (0x17) were identified within the environment, indicating that legacy encryption negotiation remains active for a subset of accounts or services. While the volume and context of these requests did not conclusively confirm active Kerberoasting tooling was in use, the presence of RC4 ticket issuance represents a configuration risk that reduces the effort required for offline cracking should hashes be obtained. Additionally, a small number of accounts were identified with Kerberos pre-authentication disabled, confirming the existence of AS-REP Roastable accounts in the environment. These accounts represent passive exposure; no active exploitation was observed against them during the hunt window, but their configuration means they can be targeted by any domain user without generating pre-authentication failure events.

Kerberos Username Enumeration

Behavioural analysis of Kerberos AS-REQ traffic surfaced a pattern of repeated authentication requests returning KDC_ERR_C_PRINCIPAL_UNKNOWN (0x6) responses, the error code the domain controller returns when a requested account does not exist. The requests originated from an internal network segment and targeted short, likely guessed usernames in rapid succession, consistent with automated username enumeration tooling probing for valid accounts using the distinguishable difference between existence and password failure error codes. The activity spanned multiple days and source machines within the same subnet, suggesting either a persistent misconfigured tool or a deliberate low-and-slow reconnaissance pattern designed to stay below volume-based alert thresholds. Critically, one of the enumerated usernames returned a KDC_ERR_KEY_EXPIRED (0x17) response rather than 0x6, confirming to the enumerating source that the account exists. A dormant administrative account with an expired password was thereby positively identified by the enumeration activity.

TGT forwarding on internal infrastructure subnet

Kerberos TGT forwarding activity was identified from multiple administrative accounts across an internal network subnet, with all observed tickets using AES256 encryption (0x12) and the Forwarded flag (0x60810010) set. All requests returned successful status (0x0). The pattern, multiple administrative accounts forwarding TGTs across several machines within the same subnet, is consistent with either legitimate Kerberos constrained delegation in use on infrastructure servers such as SharePoint or application middleware, a Privileged Access Workstation environment where forwarding is expected, or in the absence of confirmed infrastructure designation, Pass-the-Ticket lateral movement. The use of strong AES256 encryption across all observed tickets is a positive indicator and does not suggest credential downgrade abuse. 

MFA push flood and impossible Travel Signals

MFA push notification volumes exceeded detection thresholds for a number of accounts during the hunt window, with the signals primarily attributed to VDI session re-authentication behaviour and mobile device connectivity patterns. VDI environments generate multiple parallel authentication challenges per session depending on session broker behaviour, and mobile applications similarly produce compounding push events when accessing corporate resources alongside desktop sessions. Impossible travel signals were also observed, with multi-country sign-ins within the same hour attributed to geographically distributed VDI egress nodes and mobile carrier routing rather than physical travel. No pattern of repeated MFA denials followed by an eventual approval, the definitive fatigue bombing success indicator, was identified.

What We Did Not Find

Despite comprehensive coverage across all four credential theft technique categories, the following were not observed during the hunt period:

  • No Kerberoasting sweep activity: no accounts generated RC4 TGS requests across multiple service accounts at volumes consistent with automated tooling
  • No DCSync activity: no non-Domain Controller accounts triggered Directory Replication Service access using the replication control GUIDs associated with DCSync tooling
  • No unauthorised replication permission grants: no ACL modifications were detected on the domain root object granting replication rights to non-DC accounts
  • No Pass-the-Hash lateral movement: no accounts were observed authenticating via NTLM to an abnormal number of destinations within compressed time windows
  • No Pass-the-Ticket anomalies: no Kerberos ticket usage was identified that was inconsistent with the authenticating account’s normal access patterns
  • No LSASS access from non-system processes: no suspicious process interactions with the Local Security Authority Subsystem were detected in endpoint telemetry

Key Takeaways

  • RC4 encryption must be disabled. Its continued availability in the environment provides adversaries with a weaker cipher to target for offline cracking. Enforcing AES256 exclusively via Group Policy removes this attack surface entirely and has no impact on modern clients.
  • Pre-authentication must be enabled on all user accounts. Accounts with this setting disabled are unconditionally exposed to AS-REP Roasting regardless of password strength. There is no legitimate operational reason for standard user accounts to have pre-authentication disabled in a modern Active Directory environment.
  • Username enumeration via Kerberos error codes is a pre-attack signal. Repeated 0x6 responses from a single internal source across multiple days is a deliberate probing pattern. The source machine should be identified and attributed before this finding is closed, and Kerberos armoring (FAST) should be evaluated as a long-term control to eliminate the error code distinction that makes enumeration viable.
  • MFA push notifications are not sufficient for high blast radius accounts. The volume of push activity observed even when attributed to infrastructure noise demonstrates that push-based MFA creates unnecessary exposure for privileged users. Migration to number matching or FIDO2 hardware keys for high blast radius accounts eliminates the fatigue vector entirely.
  • Infrastructure subnets generating privileged Kerberos activity must be formally documented. Unattributed subnets producing TGT forwarding events across multiple privileged accounts cannot be distinguished from lateral movement without a confirmed asset inventory. Subnet labelling in detection queries and formal CMDB validation are both required to close this ambiguity.