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)

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

[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!

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.

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?