Shifting yourself to space

May 25, 2011

The case of the spying eyes

Filed under: Uncategorized — shift32 @ 10:48 pm
Tags: , , , , , ,

I found this sample of an interesting spyeye malware packed with UPX and ASPack,
and decided to reverse it on my own.
As I’ve never unpacked ASPack I decided to look around and found two interesting anchors,
both are interesting win32-api memory allocation functions which are called VirtualAlloc and ZwAllocateVirtualMemory

But before reversing the malware itself I wanted to see what goes “on the hood”, as Mark Russinovich documents in his blog
In other words – before dwelling into an unpacking nightmare I want to see what sort of files it adds to the system, what registry keys it modifies, what sort of hooks it adds etc

So onward my small journey I’ve hooked up several processes (sysinternals + rku, rootkitRevealer)
I’ve set a snapshot on the vm to return to my initial status after executing and executed the binary

And there I’ve had it, after just executing it everything remained the same, I’ve looked at procmon and regmon to see what sort changes in their process tree and started investigating.

Before running the malware I’ve used shellrunas to first run the malware in a Guest user restricted mode, just to see how it handles things, and I saw that the malware forks itself to a new process called “algonic.exe”,

I’ve set the process in suspended mode and started looking at the log of procmon to see which values it tried modifying

Considering that the malware doesn’t have any zerodays it couldn’t leave Guest user, and execute code in ring0, this helps a bit as I know I’m dealing with any kernelmode malware

Now onto the interesting part, I’ve looked at procmon and saw that the process fork itself and looks for certain specific registry values such as ComputerName,
“HKU\S-1-5-21-1547161642-152049171-839522115-501\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders” ,
“HKU\S-1-5-21-1547161642-152049171-839522115-501\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache” , “HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\Paths\{dda3f824-d8cb-441b-834d-be2efd2c1a33}” etc,

it tries to lower down the security attributes ie has, open different know dlls (ntdll, wininet, usp01 (??), windows Shell manifest etc),

At this time of writing I do not know the purpose of all those, I can only think it wants to hide itself (with hooks, though), and add different malicious things
I can also ponder that it tries to collect information about the system, if the malware is smart enough it will detect that it’s running inside VirtualBox ( as vbox has two main processes with *vbox* initials inside them, though there are other ways to detect you’re inside a vm like timing-attacks etc )

One interesting thing my eyes caught was that the malware tries to read the

E:\Documents and Settings\Guest\Application Data\Microsoft\SystemCertificates\My\CRLs

This path is quite important as it includes the local system certificates the user has, adding the virus’s certificate to the trusted path will probably break any av or scanner that tries to look for malicious things automagically

Aight, enough for that now –
Let’s move onto the real binary – the algonic.exe which seems to do all the dirty job
[btw, as this time of writing, since no dynamic/static analysis of the binary is done, it is quite unknown what the malware is looking for, I can only assume that I’m missing alot of under the hood stuff, but that’s only an assumption which must be analyzed and faced ]

The algonic.exe is located in the same root drive the malware was originally located, in my own situation it’s located in


The folder is secret and probably well protected if ran with administrator privileges.
The folder contains to files – algonic.exe and config.bin

I’ve hit PEiD on algonic.exe and I wasn’t surprised to see that it is indeed also packed with UPX and
probably also with ASPack,
at this point I’ve unpacked the UPX packing protection by simply putting a bp at 497F3 which is probably the most classical way to unpack most UPX versions

I’ve set also two hardware breakpoints – one for each unique function I was hint’ed, one for VirtualAlloc and one for ZwAllocateVirtualMemory,

Once I’ve hit both bp’s I’ve managed to get the decryption stub, and also the function which calls the EP, I’ve seen the real PE header (at 0x4000000) and currently I’m reversing the last part of the loop before reaching the last popad + ret part.
(I do want to apologize for not writing too much about this phase, but since it’s incomplete I’m still unsure what I am missing and what’s not)
Wish me luck.

To be continued



  1. I’m working on this as well and was wondering how you got access to the algonic.exe and config.bin files. I’ve tried shellrunas and couldn’t get it to work for some reason. I also tried running the malware from a guest account on xp sp3 but it was somehow still able to create the necessary hooks before I could get access to those files. A quick rundown of exactly what you did to get them would be cool.

    Comment by xploit35 — May 26, 2011 @ 10:11 pm | Reply

    • I’ve enabled the Guest account and only then ran the malware using shellrunas (there’s a possibility to register “shellrunas” as an extension to windows shell)

      spyeye creates a hidden folder, in the root directory it was downloaded to, and hooks certain functions so you won’t be able to see it with explorer/any other process (as it infect them too, if you try opening rku with administrator (and spyeye runs under administrator), you’ll see that rku points that spyeye hooked it (rku)

      Also – which md5sum of spyeye version are you working with ?

      I’d appreciate if you could inform me if it worked or not

      Comment by shift32 — May 27, 2011 @ 2:51 am | Reply

  2. The md5 of the one I’ve got is 34bd32ff879c86b48e8eaf4d0cfebc8c

    I did register the shellrunas contextual menu item and by moving the exe to a directory that guest could read from I was able to execute it. It still hides the algonic directory and files from me though, even when I run it as guest and then try to retrieve the files from an admin account. It seems like it might be transitioning from guest to admin on its own.

    I’d be curious to hear if you are messing with the same version, and if you have any other ideas on how I can get to those files.

    Comment by xploit35 — May 27, 2011 @ 3:24 am | Reply

    • That’s quite weird, as this is the same md5sum I have
      I’ve ran the “shellranas” as administrator, and when prompted with new credentials I just hit “Guest” and had procmoc, procexp, regmon up and running (under administrator) so once it finished executing I could view the results

      Eitherway, the algonic.exe is basically the same .exe (from what I’ve seen), it’s still packed with UPX and possibly/probably ASPack
      did you manage to unpack it on your own ?

      Comment by shift32 — May 27, 2011 @ 1:01 pm | Reply

      • Mostly. I used standard UPX to unpack the outer UPX layer and ollydbg + ollydump to unpack the majority of the secondary packing layer (which I also believe is ASPack). The imports aren’t fully fixed up (because ImpRec couldn’t find them all and I haven’t taken the time to manually do it) but it produces a good amount of readable disassembly in olly/ida. I think ASPack is also known for messing with the imports.

        I say mostly because there is still more packed code in my dumped binary although I ran through the final jump to OEP after ASPack was finished. I’m not sure whether the packed code is the code for algonic.exe and config.bin that are copied out, or if there is also a custom packing/encryption applied.

        I say that because in my mostly unpacked version, the “call ebx” instruction at 0x3240 that ida assumes is a call to CloseHandle, actually seems to call into code that is copied into memory and ran there from the unpacked exe. It also looks to me like algonic.exe does all the work, while the outer file is just the dropper which is why I’d like to be able to actually take a crack at algonic.exe

        Anyway here’s my dumped dropper if you want to take a look:
        It will still infect an uninfected system but seems to behave a bit differently than the originally when launched on an already infected system (the dropper doesn’t delete itself).

        Comment by xploit35 — May 28, 2011 @ 5:26 am

  3. Hey,

    I just managed to fully unpack (and also rebuild the imports) spyeye, it seems that the sample we have is triple packed with UPX – ASPack (?) and another layer of UPX, so once you return from ZwFreeVirtualMemory you hit UPX – again

    It’s quite easy to unpack UPX – as you know – if not you can take a look here –

    I will look at your sample after I’ll finish my analysis (decryption of the config and behavior etc)

    Comment by shift32 — May 28, 2011 @ 3:19 pm | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at