DPRK Using Etherhiding in Persistent Attacks

Day 14 of 100 in the 100 Days of Cyber Challenge

Welcome to the first article on the Malware Monday blog. One of this site’s goals is to publish informative content about malware each Monday (or close to each Monday as time allows). Since I am ‘making this up as I go along’ there will be content added on other days too.

I’m trying to take an approach similar to the proverbial architect who designed buildings for a college campus but held off on building sidewalks between the buildings. After a few weeks of students walking their preferred routes between the buildings, the paths worn in the process showed the architect where the sidewalks should go.

In a similar way, running this site for awhile, ‘just doing it’ should make a clear path for how its content will be posted.

The first topic I wanted to cover is etherhiding, a formidable attack attributed to North Korean cybercrooks that has proven difficult to defend against.

Google Threat Intelligence Group discovered back in October that DPRK-sponsored threat groups UNC5142 and UNC5342 used etherhiding to facilitate attacks.

These attacks in part repurpose smart contracts, which rely on blockchain technology. If you want a good primer on smart contracts, a page on Kraken’s website should be helpful.

The TLDR of a smart contract is that it’s a latent program in the blockchain that executes once its conditions are met. Combine this with the blockchain principle of immutability and you have a built-in enforcement mechanism that’s tamper proof.

If the program enforces an agreement that parties entered into, that’s just people doing business. Nothing wrong with that.


But if program the smart contract runs consists of malware, you have a problem that conventional solutions cannot easily fix: malware that is hard to remove.

In addition to being immutable, blockchain technology is decentralized too; it’s practically everywhere. You can’t just locate the infected machine and quarantine it because the infection can’t be narrowed down to a limited set of machines or sites.

So what do you do about it? There does not seem to be single one-size-fits-all approach and the list of recommendations is more about prevention than the difficult task of fixing the damage after the fact.

Not an exhaustive list, but a few recommendations:

The DPRK playbook often uses social engineering attacks that prey on job seekers, especially techies. The Hack Academy recommends sandboxing coding tests and treating them with high suspicion. Using kill switches to prevent executing code from blockchains on production systems was also recommended.

Google’s recommendations (linked below) are tied to their enterprise solutions. Useful if you are a customer, but maybe not so much otherwise.

Users should be educated on phony job scams and Github repositories should be scanned regularly.

Other recommendations fall under the usual advice: regular audits, script blocking, keeping software and patches current, using 2FA, regular backups, etc.

Stay vigilant!

Hack Academy Coverage on Etherhiding

CSO Online page about etherhiding

Kraken page about smart contracts

Simpleswap coverage

IT Branschen coverage

Google Etherhiding Links (very thorough coverage)
https://cloud.google.com/blog/topics/threat-intelligence/dprk-adopts-etherhiding
https://cloud.google.com/blog/topics/threat-intelligence/unc5142-etherhiding-distribute-malware


Posted

in

by