Government grade malware in the wild

[Ignitionnet]

For the geeks, this beast's protection code is now out in the wild and being seen in commercial malware.

It ignores instrumentation attempts by AV and has the usual obfuscation along with lots of unusual obfuscation so extremely difficult to catch.

Unplug your network connection now!

doesn't the fact it creates a reg entry give it away if you do not have skype? ( limited understanding of this subject)

[qasdfdsaq]

TBH I've found lots of malware used by elite criminal groups to be above the junk some people consider "government grade" for years already, what exactly is "government grade" malware anyway? After all we've known some governments to use pretty crappy and amateurish attacks on occasion.

Interestingly the researchers say repeatedly it's designed for x86 and x64, yet in their analysis say the payload is pure 64-bit and uses native 64-bit system APIs. Which wouldn't run on a x86-32 install. Then they later say the main payload executes inside a 32-bit process. So what exactly is going on?

[Ignitionnet]

Originally Posted by qasdfdsaq

TBH I've found lots of malware used by elite criminal groups to be above the junk some people consider "government grade" for years already, what exactly is "government grade" malware anyway? After all we've known some governments to use pretty crappy and amateurish attacks on occasion.

Interestingly the researchers say repeatedly it's designed for x86 and x64, yet in their analysis say the payload is pure 64-bit and uses native 64-bit system APIs. Which wouldn't run on a x86-32 install. Then they later say the main payload executes inside a 32-bit process. So what exactly is going on?

The references to Windows on Windows are a hint.

http://en.wikipedia.org/wiki/WoW64

Have a look at the references to the obfuscation techniques it uses. Part of the games it plays involve screwing with WoW.

Along with that it has a 32 bit wrapper and execution paths for both 32 and 64 bit.

The protection features are exceptionally sophisticated and were seen first in a malware traced back to the Russian government. That code is instruction for instruction in commercial gack. Seems government grade to me.

Happy to reverse engineer it if you can send me a copy. Will just take a while.

[qasdfdsaq]

Windows on Windows is irrelevant though. WoW64 does not exist on 32-bit Windows. A native 32-bit binary can run on 64-bit using WoW64, a native 64-bit binary cannot run on 32-bit Windows. It can try screw with WoW as much as it likes, but when WoW doesn't exist on the target machine it's not going to get anywhere... The references all describe how it'd run on a x64 Windows install, but not an x86 (although a partial example of the some disassembly of the latter is shown, no description of how they came to it is shared)

[Ignitionnet]

Mmm this was meant to be a fairly light-hearted post hence the comment at the end.

This is actually more of a PR piece than a serious technical article. The malware itself is similar to Urausy.C/D with some modifications (modified Yoda wrapper) and bits of espionage payload attached.

[qasdfdsaq]

Yes, I know, though the Sentinel labs article tries to go into some depth of technical analysis either I'm reading it wrong or it's self-contradictory and they've left out some important bits (like, where do I get a copy?)

[Ignitionnet]

It's not very technical at all.

http://blog.avast.com/2013/07/24/ura...nd-20-minutes/

Is something like technical.

If you want a copy go to one of the usual places where these things live. Analyses don't tend to provide links, though it should at very least have the MD5 of the thing.

[qasdfdsaq]

I don't see the difference in technicality really, the first has

Anti-debugging uses the NtQueryInformationProcess
Native API with DebugPort parameter.

Anti-debugging, using the NtSetInformationThread with
ThreadInformationClass to 0x11 (ThreadHideFromDebug
ger), the thread will be detached from the debugger.

The second says

The first stage begins with a check for presence of a debugger (NtQuerryInformationProcess with ProcessInformationClass = 7 = ProcessDebugPort). If a debugger is detected, the malware ends. The presence of NtSetInformationThread with ThreadInformationClass = 0×11 = ThreadHideFromDebugger means “the debugger will stop receiving debug information or exceptions from this thread.”

Pretty much the exact same information in different words... The second is just a lot more verbose rather than trying to be a summary. A lot more technical? Not to me...

[Ignitionnet]

Feel free to obtain the older malware, reverse it yourself, and show them how it should be done as far as a technical reporting and analysis goes.

[qasdfdsaq]

I still don't understand what you see to be the difference, given as quoted above, it's the same information on the same subject in both paragraphs.

I'm not sure what 'showing them' has to do with the difference you are trying to describe?

[Qtx]

Originally Posted by qasdfdsaq

Windows on Windows is irrelevant though. WoW64 does not exist on 32-bit Windows. A native 32-bit binary can run on 64-bit using WoW64, a native 64-bit binary cannot run on 32-bit Windows. It can try screw with WoW as much as it likes, but when WoW doesn't exist on the target machine it's not going to get anywhere... The references all describe how it'd run on a x64 Windows install, but not an x86 (although a partial example of the some disassembly of the latter is shown, no description of how they came to it is shared)

The malware is compiled as 32-bit and is always spread as 32-bit. There isn't a 64-bit version as it is more beneficial to run 32-bit malware on 64-bit version of windows as the 32-bit version will utilise WoW, which gives them extra capabilities than running 64-bit code directly. The WoW factor could give documented/undocumented features as well as another chink in the chain for vulnerabilities.

Often the malware writer on the internet will have techniques and use use 0-day vulnerabilities that governments/security services are not aware of (although the window of exclusivity is limited) so it goes without saying it works both ways and the agencies have techniques no one else knows about.

At least the AV companies can try and work this in to their programs now, if they can.....maybe that is why Symntec recently gave up and said AV is no longer viable for keeping infections away. Could make your computer extremely slow to check everything and even then it will have problems detecting infections in firmware of your hardware and bios for example. At least Dragor (BadBios fame) know's he isn't mad now since the Snowden leaks, after seeing software update and infections come back on an air-gapped computer

[qasdfdsaq]

Originally Posted by Qtx

The malware is compiled as 32-bit and is always spread as 32-bit. There isn't a 64-bit version as it is more beneficial to run 32-bit malware on 64-bit version of windows as the 32-bit version will utilise WoW, which gives them extra capabilities than running 64-bit code directly. The WoW factor could give documented/undocumented features as well as another chink in the chain for vulnerabilities.

See, that makes sense and I'd expect it to be done like that, however the article in the OP states:

The malware creates a separate 32-bit process and
decrypts itself. Then it switches to the 64-bit segment, ex
-
ecuting its payload using the FAR CALL instruction (The
file stage, stage1_upk.i64, function InjectHookAndShell).
The payload is pure 64-bit calling only Native System
APIs

So what exactly are they getting at?

At least the AV companies can try and work this in to their programs now, if they can.....maybe that is why Symntec recently gave up and said AV is no longer viable for keeping infections away.

I guess that's why McAfee came up with Deep Defender:
http://www.mcafee.com/uk/products/deep-defender.aspx
Though given virtual machine hypervisors have their own vulnerabilities as it is, I wonder how long it'll be before someone develops an exploit to rootkit the Deep Defender host as well...

[Qtx]

Originally Posted by qasdfdsaq

So what exactly are they getting at?

I think what they are saying, and im not 100, is that the initial 32 bit first stage that goes through WoW64 then manages to execute 64 bit code that it calls from outside of the memory allocated to the 32 bit code and WoW64. That is after it re-assembles that second 64 bit code that it had planted in different sections of memory. So WoW64 bit code calling second separate native 64 bit code.

They still don't exactly say why doing this stops AV's from seeing the hooks or API calls. Could be how it is injected in to the memory space of another process or a bug in how windows handles something. Could be that the AV doesnt see beyond the WoW64 part running for some reason. Really dunno

It really wouldn't surprise me if it uses a backdoor put in by microsoft. People have got to stop thinking of backdoors as they used to be, these days they are made by intentionally coding bugs so there is the deniability factor. No code showing magic packets/port knocking or passwords that can be found by reverse engineering software/firmware like we saw a while back with some routers. Instead a bug is put in that is extremely difficult to find or exploit unless you created in the first place.

Re Deep defender; a step in the right direction. Protection really needs to start at the hardware level. Just hope they do it right rather than just introduce another thing that can be exploited like you say.

[qasdfdsaq]

Thanks for the explanation

As for hardware protection - haven't we had TPM and Trusted Execution for a while now?