About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Home » Industry WatchThe Technological » Hall of Monkeys » Heroes Banquet)

Symantec on the China Attack

Whose idea was it?


Buy It

Try It

Symantec's published report on the Chinese Google attack (which they cutely call 'Trojan.Hydraq') from 13 and 16 January makes interesting reading.

1. Install

Trojan.Hydraq trojan is a DLL that runs as a service within the context of the system process svchost.exe.

OK. Today almost everything on a Windows box that's not supposed to be there and that's going to access the Internet runs on svchost.exe.

In order to be executed within the process svchost.exe at the system startup, the trojan employs no injection techniques - this is achieved with the steps described below.

Whoa. Sounds cool!

Firstly, the trojan registers itself as a system service RaS[4 random characters] by creating Registry entries under the newly created key:

HKLM\SYSTEM\CurrentControlSet\Services\RaS[4 random characters]


OK.

The 'ImagePath' value of its service Registry key is set to start svchost.exe, as shown below:

"ImagePath" = %SystemRoot%\system32\svchost.exe -k netsvcs
HKLM\SYSTEM\CurrentControlSet\Services\RaS[4 random characters]


Whoa.

This will force the system process svchost.exe to look up its multi-string value 'netsvcs', load all services specified in it into its address space, and then call their ServiceMain() exports.

You gotta love those words about 'forcing the system'.

To make svchost.exe aware of its existence and be loaded too, the trojan adds its service name into the list of strings (service names) stored in the value 'netsvcs' of the Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost


Ah. Another Registry key set. OK.

To make sure its service name is added to the list of services only once, the trojan queries the contents of the value 'netsvcs' to make sure that the multiple strings stored in that value do not contain any string that starts from 'RaS' (case-sensitive).

Thanks for the tip on case-sensitive.

Other parameters of the newly installed service are specified in the values:

ObjectName = LocalSystem
Type = DWORD:0x20 (a Win32 service that can share a process with other Win32 services)
Start = 2 (to be loaded automatically for all startups)

of the Registry key:
HKLM\SYSTEM\CurrentControlSet\Services\RaS[4 random characters]


Lots of random characters.

Finally, to let svchost.exe process know where to load the DLL from, the image path of the trojan's service DLL is saved by setting the value:
ServiceDll = [path to trojan DLL]

of the Registry key:
HKLM\SYSTEM\CurrentControlSet\Services\RaS[4 random characters]\Parameters

The file name of the trojan DLL is retrieved by calling GetModuleFileNameA(), as the trojan knows its name may vary.


But of course! So did we reach the punch line yet? Not quite!

2. Backdoor

Skipping a bit of nonsense we come to the following.

The Hydraq trojan installs a backdoor trojan that listens for incoming commands. The commands allow the trojan to perform multiple actions - the trojan organises them into groups - these commands are enlisted below with the [group number].[internal command number] prefixes:

  • [0.0] adjust token privileges
  • [0.1] terminate processes
  • [1.0] enumerate name and status for all system services
  • [1.1] control arbitrary services
  • [1.2] query status for arbitrary services
  • [2.0] receive remote file and save it as %TEMP%\mdm.exe, then launch it by using command control program %SYSTEM%\cmd.exe
  • [3.0] enumerate Registry keys under the specified key
  • [3.1] enumerate Registry values for the specified key
  • [3.3] query Registry values
  • [3.4] set Registry values conditionally
  • [3.5] set Registry values unconditionally
  • [3.6] delete Registry keys
  • [3.7] create Registry keys conditionally
  • [3.8] create Registry keys unconditionally
  • [4.0] retrieve the list of logical drives on a system
  • [4.1] read files from the local file system
  • [4.2] execute arbitrary files
  • [4.3] copy files in the local file system
  • [4.4] delete arbitrary directories
  • [4.5] rename files
  • [4.6] change file attributes
  • [5.1] power off computer
  • [5.2] reboot Windows
  • [5.3] uninstall itself by deleting the Registry key HKLM\SYSTEM\CurrentControlSet\Services\RaS[4 random characters]
  • [5.5] clear all system event logs (application, security, and system pools)
  • [6.0] enumerate files in the specified path
  • [7.11] check if %SYSTEM%\acelpvc.dll is present - if it is present, load it and call its EntryMain() export; check the presence of the DLL %SYSTEM%\VedioDriver.dll
  • [9.1] open the file %SYSTEM%\drivers\etc\networks.ics and read 616 bytes from it
  • [9.2] delete the file %SYSTEM%\drivers\etc\networks.ics

In addition to the commands enlisted above, the trojan retrieves CPU speed by querying the '~MHz' value from the Registry key:
HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0


The stolen details are then delivered to the remote site.

Hydraq trojan is capable to keep [sic] inter-process communications with other components via a named pipe - a separate thread is spawned for that purpose.

Internal data or configuration is stored by the trojan in the values 'IsoTp' and 'AppleTlk' in the dedicated Registry key:
HKEY_LOCAL_MACHINE\Software\Sun\1.1.2


Note the clever use of 'AppleTalk' and Sun in the obfuscation. Haha.

So did we reach the punch line yet? Not quite. Sorry.

Continued in part II.

Part II

Previous post described the installation process of the trojan and its backdoor commands. Now it's time to inspect its connection details, in particular - where does it retrieve the host name of the remote command-and-control (C&C) server.

Uh - NO. That's not interesting. What's interesting is how this sucker gets on a system. Not how it works.

But Symantec have a few cool graphs for you to look at. Here's one of the best. It's a call graph.



The graph has no description of the axes, only a bunch of lines. So all you know is 'damn that's a lot of calls'. In which case they could have spared the bandwidth and just told you 'there's a lot of calls'.

They also go on to show you how they decode the encryption, and it's fascinating, truly fascinating, but it's utterly pointless.

They have a clip at YouTube too. Showing how this trojan enslaves an unwitting PC. Of course they do. Here it is.

Turn on flash, run the clip, and stop at 1:02.



See that window in the lower right? Here it is, but a bit bigger. Recognise it?



That's Windows Explorer. That's their file manager.

You can also see where they are, both in the title bar and in the address bar. They're in C:\WINDOWS\system32.

OK, got that? OK. Now it's time to return to the beginning of this article and ask Symantec some questions.

  • How did the trojan get to run in the context of a system process?
  • How could the trojan be allowed to register as a system service?
  • How was the trojan allowed to create several Registry keys in the sensitive area HKLM\SYSTEM\CurrentControlSet? That's the current hardware configuration for the machine as running, and user land isn't supposed to be able to touch hardware, so how and why was this allowed?

Not that it's that important guys, but things like this should require SYSTEM (root) privileges, right? So - was there a further attack vector you just hopped over? Or was it as easy as it looks?

Let's look at some more. Let's look at all those luscious commands the trojan can remotely execute!

adjust token (security) privileges, terminate processes, control arbitrary services, set Registry values, delete Registry keys, execute arbitary files, copy files in the local file system, rename files, change file attributes, power off computer, reboot computer, clear all system event logs, read and delete files in the %SYSTEM% hive...

That's quite the trojan! And if you've watched the complete Symantec clip by now, you'll have seen that the controlling computer has full (visual) insight into what's happening on the victim's computer. Cool, innit!

But again: how is all this possible? How can anyone, local or remote, do all these things without privilege escalation? For you surely can't do a mite of this on a real operating system, can you?

Finally, let's look at that screen dump from the YouTube clip again. The picture of Windows Explorer. What's interesting is we see four - and only four - columns of data in the file manager window.

  1. Name. The file name (sans path).
  2. Size. The file size (in KB or kilobytes).
  3. Type. The file type (such as 'application' or 'application extension'). (How helpful.)
  4. Date Modified. When the file was created or last modified.

There's no mention of ownership by group and user, there's no mention of permissions for the owner, the group, and everyone else, there's no mention of... And even if such things did exist (in your dreams, fanboy) then the Symantec guys evidently don't think it's important enough to even look at anyway.

Now we all know Internet Explorer is leaky as a sieve, and any Windows computer can at any time fall victim to a 'drive by attack' and get trojans on its hard drive, but in the clip, just before 1:02, we see the demonstrator click an icon on the desktop to simulate the second phase - the download of additional malware. And right around 1:02 we see that result in yet another file being copied into system32. Was that process running as SYSTEM (root)?

Because system32 is the most sensitive part of a Windows computer. It's the equivalent of Apple's /System/Library or the standard Unix directories /bin, /sbin, /usr/bin, /usr/lib, /usr/sbin, and so forth. And trojans could never get in there - nobody can get in there - without privilege escalation.

So a few followup questions to the cool guys at Symantec.

  • Whose idea was it to put this report online?
  • Whose idea was it to leave the gate unlocked so trojans could just walk in and take over the entire farm?
  • Whose idea was it to even bother trying to fight the trojan in the first place?

But don't worry - nobody's going to ask you whose idea Windows 7 was.

There are those who foolishly think it was their idea...



But we won't let on. We promise.

See Also
ThreatExpert Blog: Trojan.Hydraq Exposed
ThreatExpert Blog: Trojan.Hydraq — Part II

About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.