Duqu Malware Techniques Used by Cybercriminals

Duqu 2.0 is a really impressive piece of malware, related to Stuxnet and probably written by the NSA. One of its security features is that it stays resident in its host’s memory without ever writing persistent files to the system’s drives. Now, this same technique is being used by criminals:

Now, fileless malware is going mainstream, as financially motivated criminal hackers mimic their nation-sponsored counterparts. According to research Kaspersky Lab plans to publish Wednesday, networks belonging to at least 140 banks and other enterprises have been infected by malware that relies on the same in-memory design to remain nearly invisible. Because infections are so hard to spot, the actual number is likely much higher. Another trait that makes the infections hard to detect is the use of legitimate and widely used system administrative and security tools­—including PowerShell, Metasploit, and Mimikatz—­to inject the malware into computer memory.

[…]

The researchers first discovered the malware late last year, when a bank’s security team found a copy of Meterpreter—­an in-memory component of Metasploit—­residing inside the physical memory of a Microsoft domain controller. After conducting a forensic analysis, the researchers found that the Meterpreter code was downloaded and injected into memory using PowerShell commands. The infected machine also used Microsoft’s NETSH networking tool to transport data to attacker-controlled servers. To obtain the administrative privileges necessary to do these things, the attackers also relied on Mimikatz. To reduce the evidence left in logs or hard drives, the attackers stashed the PowerShell commands into the Windows registry.

BoingBoing post.

Tags: , , , , ,

Posted on February 16, 2017 at 10:28 AM • 29 Comments

Comments

Sam Lord • February 16, 2017 12:36 PM

@Brian I assume that it wouldn’t, but doesn’t need to, as the type of machine its targeting will have high uptime, and be on a network where it can contact other machines to spread the exploit relatively easily.

Ross Snider • February 16, 2017 2:15 PM

Mimikatz and metasploit aren’t considered legitimate sysadmin tools.

Powershell itself has been used for the about 6 years in the hacking industry to bypass antimalware protections.

The technique of using legitimate admin tools to persist, elevate or take actions is really old (telnet, netcat, for instance and shellcode that spawns shells of /bin/sh with execve).

Ross Snider • February 16, 2017 2:32 PM

Don’t mean to post twice but Meterpreter has been around for over a decade and in-memory presistence before that.

The title of this makes it seem like malware is trying to mimic and learn from Duqu. That’s possible. But the evidence presented for it really doesn’t amount to much of anything. Using meterpreter? That was around since before Duqu disclosures.

It’s a nice story that hackers are learning from state sponsored malware, but ultimately seems pretty exaggerated. The truth is that learning goes in both directions and the overall trend of malware has been to move in this direction.

supersaurus • February 16, 2017 2:32 PM

command shells, e.g. bash, are nice tools to automate routine or repetitive tasks, but powershell is a command shell that speaks COM and .NET, thereby either going far beyond simple automation or opening pandora’s box depending upon point of view.

My Info • February 16, 2017 2:54 PM

@Brian B., Sam Lord

So how does the malware persist reboots if it’s in-memory only?

Boot sector viruses have been around for ages of course, but also the EEPROM BIOS is both highly proprietary and easily flashable in software with no special protections beyond that of “intellectual property,” not to mention various other auxiliary devices that also have highly proprietary but insecure and unprotected software-writable controller firmware code which is executed at a privileged level at boot time, such as hard drive controllers, CD-ROM drive controllers, video controllers, and controllers for mice, keyboards, memory card readers, and other USB devices, even thumb drives.

Many of these devices have their own microprocessors that run highly proprietary but unprotected and insecure executable code with direct privileged access to main memory and so forth, for example hard drives with DMA.

The real question: “Where isn’t the malware hiding?”

Phil Cobley • February 16, 2017 3:18 PM

@Brian – Reading through the Kaspersky report it appears that the persistence is managed through injecting malicious Powershell scripts into the registry, with potential C&C IP addresses placed in unallocated space. The report suggests that the only real forensic opportunities post incident are live RAM captures, network analysis and the registry amendments made by the malware. Hope that helps.

Sancho_P • February 16, 2017 5:28 PM

”It’s a nice story that hackers are learning from state sponsored malware …”
(@Ross Snider)

Still it seems national security demands insecure systems.

However, the worst security enemy is SaaS, which unfortunately is the future.

If the Russians hack Mi$o … Not really a if, a when.
Oh, probably they are already hiding under their desks? The code already there?
Paranoia, is it you?

Max • February 16, 2017 8:47 PM

Things will get interesting when malware starts to use Intel SGX to protect itself from examination (even a hardware RAM dump).

keiner • February 17, 2017 1:05 AM

Someone should have an eye on your orange utan that he takes his antipsychotic meds frequently, I think he’s going into a full-blown episode these days.

At which point do you guys take away the nuclear football away from him when he is in kind of mental state?

Drone • February 17, 2017 2:01 AM

Persistent in-memory exploits are very old-skool – ever since the appearance of stuff like BOOTP and PXE (and probably even earlier). The thinking is that if an attacker gets deep enough to persistently inject malware into volatile storage, it’s too late – time to burn down the farm.

steven • February 17, 2017 5:55 AM

“stashed the PowerShell commands into the Windows registry”
because nobody would ever find it in that awful mess!

Whereas, a hobby operating system running free software, would keep its configuration in /etc/ or /home/where/.ever/ as regular files that can be backed up, checksummed, cryptographically signed, analysed for changes, restored, or write-protected.

“NETSH networking tool to transport data to attacker-controlled servers”
because financial institutions don’t bother firewall outgoing traffic from internal systems?

Matteo • February 17, 2017 6:47 AM

True!
HackBack explicitly said that in his report on how he hacked Hacking team.

he said that he uses Duqu2 style viruses to prevent detection and used that in hacking team

Patrick • February 17, 2017 7:41 AM

This concept has been around, and in use, for at least 20 years.
The first commercial tool to use it was probably MOSDEF from Immunitysec, dating back to the early 2000’s.
So nothing new or even hint of inspiration here…

Clive Robinson • February 17, 2017 8:23 AM

The knowledge of Duqu style code has been around for a decade, and there was nothing particularly new or original, in fact it in turn had been known for a decade or so.

The first mainly “in memory” self propagating malware that most people can think of would be the Robert Morris Unix worm of 2nd Nov 1988.

The odd thing then is perhaps why it’s taken the attackers so long to get around to using the quite old (~30years) but slightly more advanced techniques.

The answer could be that the ITSec industry is so far behind, that the techniques have untill very recently been entirely unnecessary…

If true, what does that say about the ITSec industry?

For those old enough to remember Dave Cutler was allegedly VMS obcessed and got a job at Microsoft to “write a beter unix than unix” –which would become MS NT– because DEC would not.

For those that had the misfortune to have to administer the early versions of NT quite a few can tell tails of just how bad the NT in memory process control and reporting was, certainly a lot worse than Unix and way way short of what VMS could do… This poor performance made malware development and deployment one heck of a lot easier than it should have been, and the rest as they say is history.

r • February 17, 2017 5:41 PM

@Clive,

There’s a simple explanation,

neither the tools, nor the ‘necessity’ were available to the general public.

Prior to HDMoore how many people do you think had refactorable code?

How many people do you think had the ability to program such niche capabilities from a HLL?

It’s raising the bar while it’s lowering the requirements, expect worse.

Necessity is the mother of all invention, when private goes public you will always find adoption.

r • February 17, 2017 6:04 PM

It’s basic capitalism, I find and identify a niche to exploit or mine for profit and invent a tool to make my job easier. After a while some people become bored of doing the hard work and their tools become their lane of profit, no longer their old job doing whatever their tool did now they become makers instead of markers.

“Professional” criminals and inventors are much the same, always questioning what’s possible – what they can do better – what they can do different.

How they can improve what they deem as important, there’s so many angles to so many problems the only thing we can do is invent the artificial computerized assistants we’re going to start seeing.

Do my work, do my thinking, fill this out, fuzz this or that, email @Clive, SPAM @Bruce, filter @r.

It’s going to get much deeper than a simple/single exponent.

There’s 4 billion internet addresses making statements, like any good DDoS just wait until those 4 billion start asking each other questions. Real contemplatory questions I might add, can our current infrastructure handle that?

DDoS says: no.

When pervasive code analysis really hits, if it hasn’t already I think we’re going to find whole families of code were written by a few individuals. We might even find a few tools out there that were moonlighting projects while holding down a much more appreciable job, what do you do with your free time? Envision attacks? Defenses?

Do you write them down or do you work them out?

This is why privacy and security is important, but people have to be more responsible if they’re out there for the public good. If they’re not we still have to research these things to understand the capabilities and motives of others.

But like I said last week, I think a majority of the people on this planet when you really break things down what they’re doing is en line with a) safety, b) security and c) money.

It’s just how they balance those things, and how they view them that differs.

I deleted some things, rambled some more. Enjoy. That’s my rationality on the subject, I’m not here to exploit others though except maybe from learning a little bit about this environment and helping others to do the same and maybe some neat little PoC’s or tools along the way. Yay @ phr33stuph.

Clive Robinson • February 18, 2017 4:32 AM

@ r,

Who’s shoulders do you stand on Mr. Clive Robinson?

There are two traditional answers to that question, that of Sir Issac Newton and that of Ozymandias (Egyptian pharaoh Ramesses II) as channeled by English Romantic poet Percy Shelley (husband of Mary Shelley).

But as any father knows he is in perpetual danger of standing on the shoulders or other assorted body parts or possessions of those who chose to be perennially “under foot”. For though his home maybe his castle, like any wise ruler he must tread light and nimble lest his popularity be called into question there.

r • February 18, 2017 7:36 AM

@Clive,

I wasn’t trying to pick a fight, I understand the repercussions especially of my casting that shadow towards you. 😉 I was just trying to make sense of my miserable self and thoughts thank you for your patience friend.

Queen of the Sea • February 19, 2017 1:47 PM

@drone

Persistent in-memory exploits are very old-skool – ever since the appearance of stuff like BOOTP and PXE (and probably even earlier). The thinking is that if an attacker gets deep enough to persistently inject malware into volatile storage, it’s too late – time to burn down the farm.

Or you fix the bug. You only recycle the atoms if the design was so flawed that such bugs couldn’t be fixed with an improved software update.

Fully documenting a physical part’s designed ability to either be capable of such software update bug fixes, or not, would seem to be the step number one that the fascists don’t want the masses to grok.

Security by obscurity. Old cut-corners swept under the rug die hard.

MSDN scholar • February 21, 2017 8:56 PM

I’m trying to learn about the Windows Registry.
Please tell me which win32 API I should use to save keys to the autorun section of the registry, without it writing to the disk, because apparently that’s what someone did?

Do you have to put the registry hive file onto a ramdisk to modify the registry without leaving forensics? How would it persist then?

Someone said you can write to firmware to persist, but wouldn’t that leave something forensics could find?

I’m not looking to make a worm just to understand.

Was SQL Slammer based on Duqu 2.0? Is memory-residence really an anti-forensic technique or just something that is necessary when the vulnerability doesn’t allow a large enough payload for persistance mechanisms?

Roger • March 2, 2017 2:47 AM

Interesting story. But:
… stays resident in its host’s memory without ever writing persistent files to the system’s drives…
contradicts
…the attackers stashed the PowerShell commands into the Windows registry.
Writing something to the Windows Registry is writing a persistent file to the system’s drives. Several different files, depending which hive you write to. Which is, of course, how it persists between reboots.

It’s true that there a couple of special hives that do not get written to disk. But these ones do not persist changes.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.