DragonForce

Management summary

DragonForce should be read as a modern, aggressive positioning ransomware operation. The group is not only a payload name but a criminal platform that combines affiliates, brand pressure, data extortion and technical renewal. In 2025/2026 DragonForce was also mentioned in context of competition and shifting affiliate ecosystems.

The main risk is that DragonForce can exploit normal business routes to reduce the visibility of malicious traffic. Recent reports describe abuse of Microsoft Teams TURN-relays for command-and-control in an attack scenario. That's defensive: communication that runs through well-known cloud or collaboration services should not be automatically trusted.

For organizations, this means that detection should not be limited to malware hashes. DragonForce-like activity requires visibility of identity, SaaS/collaboration traffic, outbound patterns, remote access, datastaging and recovery tools. If you use endpoint signatures only, you may miss the preparatory phases.

Grouping and development

DragonForce has been visible since 2023 and has developed towards a more organized ransomware ecosystem. Public reporting describes a cartel-like model in which affiliates or partners can use infrastructure and brand pressure.

The group was mentioned in tensions of RansomHub and in wider shifts within the ransomware market. Such conflicts are not only internal criminal drama; they may hit victims when affiliates switch, multiple groups claim the same access or data is re-extorted.

DragonForce is a good example of why actor profiles should not be static. The technical payload, affiliate base and printing strategy can shift while the name remains the same.

Operation and attack chain

The attack chain follows the modern pattern: initial access via vulnerabilities, creditials, social engineering or access brokers; then discovery, privilege use, data collection, exfiltration and impact. The exact route varies by affiliate.

The reported use of Teams TURN- relays or similar relay mechanisms is important because C2- traffic then seems to be lifting along on legitimate collaboration infrastructure. Defenders should therefore look at behaviour: which host talks, at what time, with which volumes and which processes start the connection?

DragonForce can build pressure through encryption, leak-site claims and threat with publication. In an affiliate environment the same organisation may also face second extortion or resale of access or data later on.

Research should always check whether the actor could have been able to do backups, hypervisors, cloud administrators, storage or identity management. Only when those layers are excluded can recovery be started safely.

Known IOCs and artifacts

Artefacts include DragonForce leak-site claims, ransom notes, encrypted files, datataging, C2- traffic via unusual relay or cloud routes, remote access tooling and possibly Go-based tooling as in recent reporting around TURN- abuse.

Team or cloud relay abuse should not be translated to blind blocking of Microsoft services. Correct detection is in deviant clients, unusual hosts, traffic outside normal user context and correlation with discovery or lateral movement.

Use IOC pistils with source and date. ransomware group infrastructure changes quickly; code of conduct around C2- cloaking, data-astaging and privilege usage remain usable longer.

Victim pattern and lessons

DragonForce claims affect different sectors. The most important lesson is not a single sector, but the combination of technical stealth and market behaviour. Affiliates seek access and pressure; the brand provides bargaining power.

A second lesson is that collaboration platforms are part of security monitoring. Teams, relays, SaaS integrations and cloud connections are business-related but can also be misused to make traffic seem normal.

A claim requires checking whether data has been published alone, actually newly stolen, re-used or taken to another group by an affiliate.

How to arm yourself

Build detection on unusual cloud and collaboration traffic patterns. Lay EDR, proxy, firewall, DNS and identity side by side and research hosts that behave as relay or tunnel.

Strengthen identity and management layers. Affiliates live on reusable credentials and fast privilege building. MFA, PAM, jump hosts and account tiering limit the speed of damage.

Prepare for double or repeated extortion. Record data classification, exfiltration detection, logging retention and communication processes so that claims can be validated quickly.

Specific Hunts

Start at DragonForce with hunts on hidden C2 within normal business communications. Search for endpoint processes that open connections via collaboration, cloud or relay routes without an active call, meeting or using a suitable application. Relationship with process name, parent process and time is more important than domain blockage.

Check Teams, proxy, firewall and EDR- data around hosts that produce high relay traffic. Note different volumes, service accounts, servers that generate user-like communication traffic and processes outside standard Microsoft paths.

Hunt for affiliate behavior: credential dumping, remote execution, new services, RDP-hopping, data-astaging and access to backup consoles. DragonForce can be technically creative, but the attack still needs to achieve privileges, data and impact.

Exposure and prevention

Exposure checks should not skip collaboration platforms and SaaS. Teams, Microsoft 365, OAuth apps, service principals and conditional access determine whether normal cloud traffic can also be abused.

Limit which servers are allowed to talk directly to cloud and collaboration services. A file server, domain controller or backup server should not normally show user-like Teams or relay patterns. Deviations should be noted.

Make affiliate transition less harmful by segmenting credentials and data. When a access or dataset changes with a criminal group, reuse must be limited by token rotation, password resets, scoped service accounts and data classification.

Sources and uncertainty

Reporting on TURN- relay abuse is topical and important, but should not lead to simplistic conclusions. The existence of Teams traffic is not IOC; the suspicious combination of host, process, volume and incident phase is.

DragonForce is also mentioned in ecosystem conflicts, which is relevant to the risk of double extortion, but no technical evidence that a victim has been hit by two groups.

Therefore, record by observation whether it is a source claim, ecosystem context, malware artifact, network behaviour or own incident telemetry.

Executive Scenario and SOC

A DragonForce scenario can start with an apparently normal cloud connection. It SOC sees traffic to known Microsoft or relay infrastructure, while an endpoint process uses it as a cloaked C2- route. The actor subsequently uses credials to move further internally.

The decision point is whether cloud traffic has context. A Teams client on a user laptop during working time is normal; a server process that uses relay traffic right after privilege escalation is not. Detection should therefore be related.

For management, the risk of double extortion is particularly important. Affiliate conflicts, rebrands and resale can re-use the same data or access. An incident is only closed when credentials, tokens, data exposure and external claims have been handled.

What the visitor needs to check out in concrete terms

Check that cloud and collaboration logs are available: Entra ID, sign-in logs, audit logs, Teams-related events, proxylogs and endpoint telemetry. Without these sources, relay abuse remains difficult to distinguish.

Check which servers can generate cloud traffic. Create a baseline per server roll. A backup server, file server or domain controller should not have user-like collaboration patterns.

Check that affiliate switch is included in incident response. Rotate passwords, pull tokens, close vendor access and monitor leak sites even after technical recovery.

Relationship with Amuneth Exposure

Exposure should not only show classic web exposure at DragonForce, but also translate cloud and identity risk into understandable actions. A weak condition access policy is as relevant as an open port.

Reporting should show which systems are accessible from the Internet, but also which management chains are behind them. A vulnerable portal is more serious when it leads to service accounts or customer data.

The scans help mainly to shift discussion from . . . we are hacked to . . which route would use an affiliate tomorrow . . . . That is the correct preventive value.

Additional Defence Notes

DragonForce calls for extra attention to trust in well-known platforms. Many organisations treat traffic to large cloud providers as less suspicious, but precisely that trust can be abused. Therefore, distinguish between destination and behaviour: known destination, unknown process, strange time and abnormal data volume is still suspicious.

Also take legal and communication preparation with you. Cutter formation and affiliate conflicts allow a victim to be contacted by another party once again after the first claim. Capture who keeps extortion communications, who evaluates samples and who decides whether customers or suppliers are proactively informed.

For technical teams, a useful exercise is: simulate a host that transmits data via legitimate cloud routes and measures or proxy, EDR and SIEM together to recognize this as an anomaly. If that correlation is missing, DragonForce-like stealth is too difficult to see.

Indicators of compromise (IOCs)

Indicators are historical observations, not proof of a current infection. Validate source, age and context before hunting or blocking; legitimate administrative tools can produce false positives.

Sources

• TechRadar: DragonForce abusing Teams TURN relays
• Tom’s Hardware: DragonForce and ransomware turf war reporting
• Ransomware.live — DragonForce

Evidence and limitations

Attribution describes the source assessment, not a verified identity. A leak-site listing alone does not prove encryption, data theft, a particular vulnerability or an affiliate relationship. Missing information is left explicit.