DragonForce

Résumé de la gestion

DragonForce Le groupe est non seulement un nom de charge utile, mais une plateforme criminelle qui combine les filiales, la pression de marque, l'extorsion de données et le renouvellement technique.DragonForce a également été mentionné dans le contexte de la concurrence et des écosystèmes affiliés en mutation.

Le risque principal est que DragonForce peut exploiter des itinéraires commerciaux normaux pour réduire la visibilité du trafic malveillant. Des rapports récents décrivent l'abus de Microsoft Teams TURN-relays pour le commandement et le contrôle dans un scénario d'attaque. C'est défensif: communication qui court à travers des services de cloud ou de collaboration bien connus ne devrait pas être automatiquement fiable.

Pour les organisations, cela signifie que la détection ne doit pas se limiter aux hashes malwares. DragonForce-comme activité nécessite une visibilité de l'identité, SaaS/collaboration trafic, des motifs sortants, accès à distance, datastaging et des outils de récupération.

Groupement et développement

DragonForce est visible depuis 2023 et s'est développé vers un écosystème de ransomware plus organisé. Reporting public décrit un modèle semblable à cartel dans lequel les affiliés ou les partenaires peuvent utiliser l'infrastructure et la pression de marque.

Le groupe a été mentionné dans des tensions de RansomHub et dans des changements plus larges au sein du marché des ransomwares. Ces conflits ne sont pas seulement des drames criminels internes; ils peuvent frapper les victimes lorsque les affiliés changent, plusieurs groupes prétendent le même accès ou les mêmes données sont réextorqués.

DragonForce est un bon exemple de pourquoi les profils d'acteurs ne devraient pas être statiques. La charge utile technique, la base d'affiliation et la stratégie d'impression peuvent changer tandis que le nom reste le même.

Exploitation et chaîne d'attaque

La chaîne d'attaque suit le modèle moderne : accès initial via des vulnérabilités, des crédits, du génie social ou des courtiers d'accès; puis découverte, utilisation de privilèges, collecte de données, exfiltration et impact.

L'utilisation des relais Teams TURN ou des mécanismes de relais similaires est importante car le trafic C2 semble alors se soulever sur une infrastructure de collaboration légitime. Les défenseurs devraient donc examiner le comportement: quel hôte parle, à quelle heure, avec quels volumes et quels processus commencent la connexion?

DragonForce peut créer une pression par le cryptage, les allégations de sites de fuite et la menace avec publication. Dans un environnement affilié, la même organisation peut également faire face à une deuxième extorsion ou revente d'accès ou de données plus tard.

La recherche doit toujours vérifier si l'acteur a pu faire des sauvegardes, des hyperviseurs, des administrateurs de cloud, du stockage ou de la gestion d'identité.

IOC et artefacts connus

Artefacts comprennent DragonForce demandes de paiement de fuite, notes de rançon, fichiers chiffrés, datatage, C2- trafic via des itinéraires de relais ou de nuage inhabituels, outillage d'accès à distance et éventuellement outillage basé sur Go comme dans les rapports récents autour de TURN- abus.

L'abus de relais en équipe ou en nuage ne doit pas être traduit en blocage aveugle des services Microsoft. La détection correcte est dans les clients déviants, les hôtes inhabituels, le trafic hors du contexte normal de l'utilisateur et la corrélation avec la découverte ou le mouvement latéral.

Utilisez IOC pistils avec source et date. ransomware groupe infrastructure change rapidement; code de conduite autour de C2- le camouflage, l'approvisionnement de données et l'utilisation des privilèges restent utilisables plus longtemps.

Caractéristiques des victimes et enseignements tirés

Les réclamations DragonForce concernent différents secteurs. La leçon la plus importante n'est pas un seul secteur, mais la combinaison de la furtivité technique et le comportement du marché.

Une deuxième leçon est que les plateformes de collaboration font partie du suivi de la sécurité. Les équipes, relais, intégrations SaaS et connexions cloud sont liées aux affaires mais peuvent également être détournées pour rendre le trafic normal.

Une réclamation exige de vérifier si les données ont été publiées seules, elles ont été effectivement volées, réutilisées ou transférées à un autre groupe par une filiale.

Comment vous armer

Construisez la détection sur les modèles de trafic de cloud et de collaboration inhabituels. Laïcs EDR, proxy, pare-feu, DNS et identitaire côte à côte et les hôtes de recherche qui se comportent comme relais ou tunnel.

Renforcer les couches d'identité et de gestion. Les affiliés vivent sur des références réutilisables et un bâtiment à privilèges rapides. MFA, PAM, sauts hôtes et niveau de compte limitent la vitesse des dommages.

Préparez-vous à une extorsion double ou répétée. Consignez la classification des données, la détection de l'exfiltration, les processus de conservation et de communication de l'enregistrement afin que les revendications puissent être validées rapidement.

Chasses spécifiques

Commencez à DragonForce avec des chasses sur le C2 caché dans les communications commerciales normales. Rechercher des processus de fin de série qui ouvrent des connexions via la collaboration, le cloud ou les itinéraires relais sans appel actif, réunion ou utilisation d'une application appropriée.

Vérifiez les équipes, proxy, pare-feu et EDR- données autour des hôtes qui produisent un trafic de relais élevé. Notez différents volumes, comptes de service, serveurs qui génèrent du trafic de communication comme l'utilisateur et des processus en dehors des chemins Microsoft standard.

Chasse pour le comportement d'affiliation: dumping de justificatifs, exécution à distance, nouveaux services, RDP-chapping, optimisation des données et accès aux consoles de sauvegarde. DragonForce peut être techniquement créatif, mais l'attaque doit encore atteindre les privilèges, les données et l'impact.

Exposition et prévention

Les contrôles d'exposition ne devraient pas sauter les plateformes de collaboration et les équipes SaaS., Microsoft 365, les applications OAuth, les principaux services et l'accès conditionnel déterminent si le trafic normal du cloud peut également être abusé.

Limiter les serveurs autorisés à parler directement aux services de cloud et de collaboration. Un serveur de fichiers, un contrôleur de domaine ou un serveur de sauvegarde ne devrait normalement pas afficher des équipes ou des modèles de relais comme l'utilisateur.

Si un accès ou un ensemble de données change avec un groupe criminel, la réutilisation doit être limitée par rotation symbolique, réinitialisation du mot de passe, comptes de service globulés et classification des données.

Sources et incertitude

Signaler les abus de TURN- relais est d'actualité et important, mais ne devrait pas conduire à des conclusions simplistes. L'existence du trafic des équipes n'est pas IOC; la combinaison suspecte de l'hôte, processus, volume et incident est.

DragonForce sont également mentionnés dans les conflits écosystémiques, qui sont pertinents pour le risque de double extorsion, mais aucune preuve technique qu'une victime a été touchée par deux groupes.

Par conséquent, indiquez par observation si c'est une revendication de source, un contexte écosystémique, un artefact malware, un comportement en réseau ou une télémétrie incidente.

Scénario exécutif et SOC

Un scénario DragonForce peut commencer par une connexion nuageuse apparemment normale. Il SOC voit le trafic vers l'infrastructure connue de Microsoft ou relais, tandis qu'un processus d'extrémité l'utilise comme un itinéraire dissimulé C2-. L'acteur utilise ensuite des crédiels pour se déplacer plus en interne.

Le point de décision est si le trafic cloud a un contexte. Un client Teams sur un ordinateur portable utilisateur pendant le temps de travail est normal; un processus serveur qui utilise le trafic relais juste après l'escalade des privilèges n'est pas.

Pour la gestion, le risque de double extorsion est particulièrement important. Conflits d'affiliation, remarques et revente peuvent réutiliser les mêmes données ou accès. Un incident n'est fermé que lorsque des justificatifs, des jetons, l'exposition aux données et des réclamations externes ont été traités.

Ce que le visiteur doit vérifier en termes concrets

Vérifiez que les journaux de cloud et de collaboration sont disponibles : Entra ID, journaux d'inscription, journaux d'audit, événements liés aux équipes, proxylogs et télémétrie en point. Sans ces sources, l'abus de relais reste difficile à distinguer.

Vérifiez quels serveurs peuvent générer du trafic cloud. Créez une base de référence par serveur. Un serveur de sauvegarde, un serveur de fichiers ou un contrôleur de domaine ne devrait pas avoir des modèles de collaboration comme l'utilisateur.

Vérifiez que le commutateur d'affiliation est inclus dans la réponse incidente. Rotation des mots de passe, tirer des jetons, fermer l'accès du fournisseur et surveiller les sites de fuite même après récupération technique.

Relation avec l'exposition à Amuneth

L'exposition ne devrait pas seulement montrer une exposition web classique à DragonForce, mais aussi traduire le risque de nuage et d'identité en actions compréhensibles.

Les rapports devraient indiquer quels systèmes sont accessibles depuis Internet, mais aussi quelles chaînes de gestion sont derrière eux. Un portail vulnérable est plus sérieux lorsqu'il mène à des comptes de service ou à des données clientes.

Les scans aident principalement à déplacer la discussion de . . . nous sommes piratés à . . quelle route utiliserait une filiale demain . . . . C'est la valeur préventive correcte.

Notes supplémentaires de la Défense

DragonForce appelle une attention supplémentaire à la confiance dans les plateformes bien connues. De nombreuses organisations considèrent le trafic vers les grands fournisseurs de cloud comme moins suspect, mais précisément cette confiance peut être abusée.

Prenez également la préparation juridique et de communication avec vous. La formation de cutter et les conflits d'affiliation permettent à une victime d'être contactée par une autre partie une fois de plus après la première réclamation. Capture qui garde des communications d'extorsion, qui évalue des échantillons et qui décide si les clients ou les fournisseurs sont informés proactivement.

Pour les équipes techniques, un exercice utile est : simuler un hôte qui transmet des données via des itinéraires et mesures ou proxy légitimes, EDR et SIEM ensemble pour reconnaître cette anomalie. Si cette corrélation est manquante, DragonForce-comme la furtivité est trop difficile à voir.

Indicateurs de compromission (IOC)

Les indicateurs sont des observations historiques, pas la preuve d’une infection actuelle. Vérifiez la source, l’ancienneté et le contexte avant toute détection ou tout blocage ; les outils d’administration légitimes peuvent générer des faux positifs.

Sources

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

Éléments probants et limites

L’attribution reflète l’évaluation de la source, pas une identité vérifiée. Une inscription sur un site de fuite ne prouve à elle seule ni chiffrement, ni vol de données, ni vulnérabilité précise, ni relation d’affiliation. Les informations manquantes restent explicitement signalées.