What's going on?
A relatively new strain of ransomware called DragonForce has making the headlines after a series of high-profile attacks.
Like many other ransomware groups, DragonForce attempts to extort money from its victims in two ways - locking companies out of their computers and data through encryption, and exfiltrating data from compromised systems with the threat of releasing it to others via the dark web.
So far, so normal. How did DragonForce come to prominence?
DragonForce's earliest known ransomware attack was against the Ohio Lottery. In that case, DragonForce boasted it had stolen over 600 GB of data - including three million records containing names, email addresses, social security numbers, and other sensitive information.
Other claimed victims have included Yakult Australia (95.19 GB of company data breached), and Coca-Cola in Singapore (413.92 GB.)
Didn't they also hit some island recently?
You must be thinking of the island of Palau in the Western Pacific.
In mid-March 2024, the government of Palau was hit by a ransomware attack that locked up computers. Bizarrely, ransom notes from two hacking gangs were left behind - one from LockBit and one from DragonForce.
As Recorded Future reports, the ransom notes gave the government differing instructions on how to communicate with the attackers, but the Tor links provided did not work.
On its dark web leak site, the DragonForce ransomware gang threatened to release information stolen from the island's government, stating that negotiations had broken down. Palauan authorities, however, denied having made any contact with the cybercriminals.
That's peculiar. What else should I know about DragonForce?
Well, in another bizarre twist, the DragonForce ransomware gang has recently been reported as publishing audio of its discussions with victims on its leaks site.
Audio?
Yes. As TechCrunch reports, a telephone conversation between a member of the gang and somewhat baffled front desk employees was posted on the group's website in an apparent attempt to pressure a company into paying a ransom.
DragonForce sounds a little desperate if it has to phone its victims to initiate negotiations...
It does rather. But that doesn't mean that they can't still cause a lot of harm and disruption if you are unlucky enough to be hit by the group's ransomware.
So, who is behind the DragonForce ransomware?
Although it is uncertain who is responsible for the DragonForce ransomware attacks, some in the cybersecurity community have linked the ransomware to the Malaysian hacking group and forum called DragonForce Malaysia.
The similar names should not, of course, be considered proof of a connection - and it's always possible that the name of DragonForce has been chosen intentionally by the ransomware gang to lead investigators off the scent, or as a piece of mischief-making. Or maybe it's simply coincidence...
Although there are some bizarre aspects to DragonForce, it still sounds like I should take the threat seriously.
My recommendation would be to take any ransomware group seriously. If your organisation falls victim then the consequences could be very costly.
What should we do to protect our business from ransomware?
Your organisation should follow safe computing practices to defend against DragonForce and other ransomware attacks. Those include:
- making secure offsite backups.
- running up-to-date security solutions and ensuring that your computers are protected with the latest security patches against vulnerabilities.
- Restrict an attacker's ability to spread laterally through your organisation via network segmentation.
- using hard-to-crack unique passwords to protect sensitive data and accounts, as well as enabling multi-factor authentication.
- encrypting sensitive data wherever possible.
- reducing the attack surface by disabling functionality that your company does not need.
- educating and informing staff about the risks and methods used by cybercriminals to launch attacks and steal data.
Stay safe.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of Tripwire.
