In a chilling reminder that humans remain the weakest component in cybersecurity, multiple UK retailers have fallen victim to a sophisticated, orchestrated cyber-attack by the hacking group known as DragonForce. But this breach was not successful using a zero-day application vulnerability or a complex attack chain. It was built on trust, manipulation, and a cleverly deceptive phone call.

By impersonating employees and tricking IT support into resetting internal passwords, attackers sidestepped security controls with a convincing voice and sense of urgency. Once access was gained, ransomware was deployed, which paralyzed internal systems. The attackers then exfiltrated the “goods” and caused millions in disruption to operations.

This incident is not just a cautionary tale. It is a blueprint for future attacks. In this blog, we will unpack the details of what has happened, how the attackers were successful, and most importantly, what the security controls and threat hunting methodology organizations should have in place to avoid becoming a news headline.

Anatomy of the Attack

The DragonForce ransomware crusade against UK retailers has demonstrated a particular blend of tactical social engineering and privilege abuse, executed with minimal reliance on typical malware or techniques at the initial stage.

The attack began with voice phishing – otherwise known as vishing – a targeted social engineering technique. The threat actor would contact IT support lines impersonating legitimate current employees. By leveraging open-source intelligence (OSINT) and likely credentials harvested from other public breaches, they could provide enough information to bypass weak or non-existent protocols within the help desk authentication procedures. Once verified by IT support, password resets were requested for key accounts, granting them authorized access to the internal systems.

Once inside the environment, the attackers began enumerating internal systems and escalating privileges. By taking advantage of weak access controls and likely misconfigurations within Active Directory, they elevated standard user accounts to privileged accounts. Common techniques may have included credential dumping from memory using tools like Mimikatz, abusing LSASS processes, or exploiting overly permissive group memberships and their inherited rights. With elevated access, attackers pivoted to other systems using native tools such as Remote Desktop Protocol (RDP), PsExec or PowerShell remoting, which avoids detection by leveraging what is already trusted in the environment – classic “living off the land” approach.

With administrative privileges established, the DragonForce attackers shifted focus to evading detection and preparing the environment for ransomware deployment. Security agents, including EDR and antivirus, were likely disabled through GPO manipulation or direct tampering with services and processes. This ensured persistence and uninterrupted payload execution. The ransomware – believed to be a custom variant deployed under a RaaS (Ransomware-as-a-Service) model – was then distributed across multiple endpoints, encrypting files and rendering critical systems inoperable.

Unexpected Vulnerability in the Bagging Area

The attack from the DragonForce group did not rely on sophisticated zero-day exploits – it succeeded by exploiting fundamental deficits in identity, access and operational controls. These overlooked weaknesses, often deemed low risk in isolation, combined into a high-impact attack chain.

The first and most critical flaw was inadequate identity verification at the IT help desk. Attackers impersonated staff and requested password resets without multi-factor checks, callback verification, or identity challenge protocols. This created a low-friction path for social engineering. Attackers did not need to hack in; they simply convinced the help desk to open the door for them.

Once inside, excessive privileges and poor Active Directory (AD) hygiene gave them the room to move as they saw fit and escalate privileges. Over permissive group permissions, a flat AD architecture, and likely legacy admin accounts provided an easy path to domain-level access. The environments lacked strong role separation and failed to enforce least privilege.

The lack of network segregation and internal access control meant lateral movement was easy and went unchecked. Core systems were reachable from compromised endpoints, and there were no boundaries (host-based firewalls, identity-aware boundaries) to contain the intruder. Native tools like RDP and PowerShell were freely available, giving the attackers the keys to the entire network.

Endpoint protection was lacking in preventative measures and not sufficiently hardened. EDR and AV agents could be tampered with or disabled without triggering automated responses or isolation protocols. This lack of enforcement and control allowed attackers to freely disable defences before launching the ransomware.

Finally, the environment lacked real-time visibility and behavioural detection. Critical actions – password resets, privilege escalations, EDR shutdown – were either not monitored, correlated or prioritised by security operations. Logs may have been present, but they were not effectively used to detect and stop the attack before ransomware was deployed.

In short, the breach was the result of a multi-layer failure of process and control, not a single missed patch, but an absence of security fundamentals across identity, access and segmentation, and monitoring.

Remember Your Receipt

To prevent similar incidents from occurring within your organization, a few core areas need to be focused on – starting with identity, then extending through network architecture, monitoring and access governance.

Firstly, enforcing multi-factor authentication is crucial, not just for user logins, but also for sensitive workflows like help desk password resets. One-time codes and time-restricted MFA applications (Microsoft Authenticator, etc.) combined with conditional access policies can block most credential-based intrusions before they begin. This would have prevented the attackers from being able to log into the accounts once the password had been reset; it would have relied on the user actively approving their access or having to be targeted for social engineering to gather the code from their application/token.

Once access had been achieved, the attackers could navigate through the architecture of the network due to its flat nature and lack of segregation. Implementing segmented zones for workstations, servers and administrative tools – whilst also implementing Just-In-Time (JIT) access and strict controls over the use of RDP/PowerShell – can limit movement and increase detection responsibilities.

However, segmentation only helps if what is happening is visible. Most environments generate logs, but lack real-time, correlated monitoring. Security teams need centralized visibility into authentication events, endpoint activity and privileged actions. Alerts on events, like password resets, EDR tampering or unexpected logins, must be contextual and actionable. Behavioural analytics adds another layer, detecting patterns that traditional techniques may miss.

Finally, least privilege must be enforced. The breach succeeded because excessive rights and legacy admin accounts gave attackers a straight path to control. Regular audits, RBAC, and tiered administrative models help limit access and contain escalation. Cleaning up over-privileged accounts and rotating credentials, especially service accounts, closes off common abuse paths.

Clean-up in the Security Aisle

To proactively identify threats that mimic DragonForce’s successful tactics, defenders and security professionals should hunt for evidence of suspicious account usage, privilege escalation, lateral movement, and EDR tampering.

Unusual Help Desk Account Activity (Initial Access)

This section of code is looking for accounts that have had their passwords reset outside of normal working hours, or accounts that were recently modified by IT staff and then used to authenticate from unusual IP addresses.

Elasticsearch (Python):

# Search for password reset events
reset_query = {
    "query": {
        "bool": {
            "must": [
                {"match": {"event.action": "user.password.reset"}},
                {"range": {"@timestamp": {"gte": "now-1d"}}}
            ]
        }
    }
}

resets = es.search(index="audit-*", body=reset_query)

# Search for sign-ins within 1 hour of resets
for hit in resets["hits"]["hits"]:
    user = hit["_source"]["user"]["name"]
    reset_time = hit["_source"]["@timestamp"]
    start = datetime.strptime(reset_time, "%Y-%m-%dT%H:%M:%S.%fZ")
    end = start + timedelta(hours=1)

    signin_query = {
        "query": {
            "bool": {
                "must": [
                    {"match": {"user.name": user}},
                    {"match": {"event.action": "user.login"}},
                    {"range": {"@timestamp": {
                        "gte": start.isoformat(),
                        "lt": end.isoformat()
                    }}}
                ]
            }
        }
    }

    logins = es.search(index="auth-*", body=signin_query)
    for login in logins["hits"]["hits"]:
        print(f"[ALERT] Suspicious login by {user}: {login['_source']['source']['ip']}")

‍

KQL:

AuditLogs
| where OperationName == "Reset user password"
| extend ResetTime = TimeGenerated
| join kind=inner (
    SigninLogs
    | where ResultType == 0
    | project UserPrincipalName, IPAddress, Location, TimeGenerated
) on $left.TargetResources[0].userPrincipalName == $right.UserPrincipalName
| where TimeGenerated > ResetTime and TimeGenerated < ResetTime + 1h
| project UserPrincipalName, IPAddress, Location, ResetTime, TimeGenerated

‍

Privilege Escalation via Group Membership Changes

Attackers may escalate privileges by adding users to administrative groups like “Domain Admins” or “Server Operators”.

Elasticsearch (Python):

es.search(index="audit-*", body={
    "query": {
        "bool": {
            "must": [
                {"match_phrase": {"event.action": "user.add_to_group"}},
                {"terms": {"group.name": ["Domain Admins", "Administrators"]}}
            ]
        }
    }
})

‍

KQL:

AuditLogs
| where OperationName == "Add member to role"
| where TargetResources has "Domain Admins" or TargetResources has "Administrators"
| project TimeGenerated, InitiatedBy, TargetResources, ResultDescription

‍

EDR or AV Tampering (Defence Evasion)

Looks for commands or processes that attempt to disable security tools.

Elasticsearch (Python):

edr_terms = ["sc stop", "taskkill", "DisableRealtimeMonitoring", "Set-MpPreference"]
edr_query = {
    "query": {
        "bool": {
            "should": [{"match_phrase": {"process.command_line": term}} for term in edr_terms],
            "minimum_should_match": 1
        }
    }
}

edr_events = es.search(index="sysmon-*", body=edr_query)
for event in edr_events["hits"]["hits"]:
    cmd = event["_source"]["process"]["command_line"]
    user = event["_source"]["user"]["name"]
    print(f"[WARNING] Possible EDR tampering by {user}: {cmd}")

‍

KQL:

DeviceProcessEvents
| where ProcessCommandLine has_any ("sc stop", "taskkill", "wmic", "Set-MpPreference", "DisableRealtimeMonitoring")
| project Timestamp, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine

‍

Conclusion

This attack was successful because of multiple failings within the process and security control stack. Due to the success being seen across multiple retailers when reviewing the initial access, it is likely that we will see an increase in this methodology, and attackers may pivot to target personnel in a more direct fashion instead of the passive application of this technique. The attack chain highlights the importance of having monitoring and alerts in place that can quickly identify and aid in the containment of sophisticated attacks.