Anatomy of a virus: iTunesHelper.vbe 2/2

Nov 20, 2013   #iTunesHelper  #security  #virus 

Disclaimer: This post is about a real virus, really seen in the wild. It was written on the sole goal of helping the reader to better protect itself. This post is NOT about writing viruses. I will NOT provide any source code nor any directions to build a virus. If this is what you were looking for: Please, I beg you to change your mind and start building something useful to the community instead of attacking it. Thanks for reading.

This post is the source-code analysis part of the article. For an introduction to the iTunesHelper.vbe virus and a more qualitative approach, you may be interested in reading the first part… first.

1/ What does it look like ?

  • Name: iTunesHelper.vbe
  • Target system: Windows >= XP
  • Propagation vector: Replace files by shortcuts to virus code on USB drive root
  • Hiding techniques:
    • Hides real files as well as himself as “system files”
    • Use a name close to a real world program “iTunesHelper.exe”
  • Symptoms:
    • All files on USB drive root are shortcuts to “strange/suspect” script
    • Process “wscript” using ~1/2GB of memory
    • Real files visible when “system files” are not hidden

2/ How does it work ? - Dissimulation

1st level of dissimulation: dissuasion. The file appears to be 65MB big. While this seems small, most text editors (who said Notepad ?) just assumes text files are no more than a couple of KB big. It makes it almost impossible to read it. Moreover, it starts with empty lines discouraging to scroll down to the real code. We’ll make it fast.

jean-tiare@laptop:~$ grep -E "^\\s*$" iTuneHelper.vbe | wc -l
34 598 142 # huh huh, ~34 *millions* of empty lines. Useful...
jean-tiare@laptop:~$ grep -vE "^\\s*$" iTuneHelper.vbe | wc -l
43 # "real" code
jean-tiare@laptop:~$ grep -vE "^\\s*$" iTuneHelper.vbe > iTuneHelper-trimmed.vbe

The code now looks like:

Audi = Mercedes("<base64 'hidden' payload>")
EXECUTE (Audi)
Function Mercedes(data)
     Mercedes=decodeBase64(data)
End Function
Function decodeBase64(ByVal base64String)
' trimmed
End Function

This basically decodes a base64 encoded the payload and run it. `decodeBase64` is standard and has been removed from this snippet for brevity. Nothing fancy, here apart from the variable’s name.

2nd level of dissimulation: base64, fun var names. That’s an easy one. It can be manually decoded for example with the following one liner. Notice that I also trim empty lines as it re-uses the same trick as before:

jean-tiare@laptop:~$ head -n1 iTuneHelper-trimmed.vbe | cut -d\" -f2 | base64 -d > iTuneHelper-decoded.vbe

It basically takes the part between double quotes on the first line and feeds it to base64 decoder and finally stores the result.

We notice the same kind of fanciness in the variables names but with names (Benjamin, Christophe, Raphael, Damien, Pierre) instead of cars.

3/ How does it work ? - Virus skeleton

As stated in the disclaimer, I wont provide real source code. But here is what the code roughly looks like once all “obfuscation” techniques have been bypassed.

' Init
Benjamin = "<command server fqdn>"
Christophe = -1 'Port on command server
Raphael = "<install dir on target>"
Damien = True
Pierre = True

' Main loop:
'   - install (*each*) iteration
'   - contact command server
'   - execute command
'   - sleep 5s</p>

' Command handlers

Sub install
On Error Resume Next
' trimmed code
' handles USB propagation
End Sub

Sub information
On Error Resume Next
' trimmed code
' leaks informations, especially Installed AV software, if any.
End Sub

'and so on...

4/ How does it work ? - (Un-)Install

The main loop runs roughly every 5s. The first thing it does is call `install` function. (no, the last thing is not a call to `uninstall` function).

Here is what it basically looks like:

Sub install

' 1/ ensure start mode
' make sure it starts on session start
setRegistryKey "HKEY_CURRENT_USER\software\microsoft\windows\currentversion\run\<virus name>"
' attempts to even set it globally (Admin session ?)
setRegistryKey "HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\run\<virus name>"

' 2/ copy virus file
filesystemobj.copyfile wscript.scriptfullname, "<destination 1>", True
filesystemobj.copyfile wscript.scriptfullname, "<destination 2>", True

' 3/ infect each USB Mass Storage
For each drive in filesystemobj.drives

    ' 3.1/ is it a mass storage ?
    If isUsbMassStorage drive Then
        ' 3.2 install file
        filesystemobj.copyfile wscript.scriptfullname, "<usb root>", True
        ' 3.3 hide it (no snippet)
        ' 3.4 for each file (and folder) on storage root:
        For Each file in filesystemobj.getfolder( drive.path & "\" ).Files
            ' 3.4.1 hide each reach file (no snippet)
            ' 3.4.2 create *visible* shortcut to each real file *first* calling the virus (no snippet)
            ' 3.4.3 pretend to be the real file by forcing the icon (no snippet)
        Next
    End If

Next

End Sub

On the opposite, the `uninstall`does exactly the reverse with one noteworthy difference: It is executed only after the control server requests so, never automatically.

5/ How does it work ? - Backdoor

So, this virus is build around a main loop sleeping for 5s after each run. It also starts by (re-)installing the virus. Up to this point that still is a common virus. What it does right after makes it also a Trojan Horse. Nice :(

To make it short it

  1. Connects to a server
  2. Reads the command from the answer
  3. Execute it

There are 13 supported commands, some of them doing similar things. The most important is that it allows an attacker to trigger an auto-update, (up|down)-load arbitrary files, run arbitrary commands, …: do anything. And that is the scary part.

6/ Last word

I find strange to find such simple script-based viruses in the wild, while not being detected by Antivirus software. This makes me wonder if they are of any use, but that’s another question. The most important point I would like to stress is: User behavior and vigilance is the most efficient way to protect himself. Being infected happens even to the best but noticing this strange behavior and asking around has been, in this case, the most efficient response.

This said, even very simple, this virus has most characteristics one would expect:

  • Efficient dissimulation.
  • Clever propagation mechanism.
  • Centralized command server.
  • Background command loop.

This last point makes me think this virus is part of a botnet. But I may be wrong.

There are nonetheless a couple of interesting vulnerabilities in the conception itself:

  • Interpreted language makes it easy to analyze.
  • Code “obfuscation” with only base64 ???
  • No attempts to dissimulate itself better than “system files”.
  • Essential registry key is still visible.
  • “What are all theses shortcuts doing here ???” user suspicion.
  • and HEAVY on memory usage !