Home » News » Roundups » ILOVEYOU

# A Look Inside the Trojan

May 11, 2000 6:30 AM UTC
Taking a peek at WIN-BUGSFIX.exe.

## A First Peek

More and more the key to the ILOVEYOU mystery seems to be in the trojan that the worm script attempts to download off the net. It is this program which steals passwords and sends them on to the Philippines.

WIN-BUGSFIX.exe is simply a configured copy of the trojan Barok version 2.1; only a few bytes are changed by the configuration program.

The build stamps indicate this version of the server was completed on Sunday, April 2, 2000 at 8:37:59 AM UTC and the client on Sunday April 2, 2000 at 3:29:00 PM UTC.

These timelines, if not forged, would roughly coincide with the demise of Onel de Guzman and the graduation of Michael Buen from AMACC.

These times correspond roughly to midnight and early morning Sunday, about eight hours later, local Manila time, and they are in the correct order as well. The server has to be built and tested before the patch machine can be finalized.

Both executables are built with the very latest release of MSVC. Moreover, both executables are debug images, and thereby reveal more about their author's programming character. For what it's worth, the source files to Barok, wherever their machine might be today, are located at:

C:\Knowledge\barok\barok
C:\Knowledge\barok\client

It's important to remember that the purpose of the ILOVEYOU worm was not to create havoc on email servers around the world, but to acquire free Internet access time. Without this 'back end' the entire exercise is pointless. All the worm script really wants to do is open the doors for the trojan.

It's also important to remember that the perpetrators, who ostensibly lacked funds for their own Internet connections, were not about to pay for long distance calls to ISPs from around the globe. More than likely, this was a 'local operation' intended to pilfer local accounts with local Philippines phone numbers. But things, as we know, got out of hand. And maybe, just maybe, someone had the thought of what they could do world wide with all this information. Just maybe...

That Barok is the work of spyder of the AMACC Mkt GRAMMERSoft Group is plastered all over this package. The package comes in two parts: the server or actual trojan, barok.exe, and the client or configuration program, client.exe. Also included in the zipped package is a readme file.

barok v.2.1

->new in v2.1
- server size 16.5 kb;
- auto save password 'Connect To' dialog;
- check 'Run' registry if infected user delete the trojan startup
check every (exitwindows-reboot-shutdown) then if(delete==true)
then disable registry editor;
- changeable icon
- and fix some bugs....

-this v2.1 release is dedicated to all barok users who requested for
the update.... i recieved all of your email but so sorry for not responding~!.\
coz for one reason im busy. )(.)(.)(.)(.)(.)(.)(.)thankz

files:
server.exe ---->> server (trojan)
client.exe ---->> configuration (client)(setup)

by: spyder
email: ispyder@mail.com
Manila, Philippines

## The Client

The client is used to configure a Barok server. The actual Barok executable can be copied to any name - e.g. WIN-BUGSFIX.exe - and then opened in this client via the standard Windows Open file dialog.

Once the server is ready and placed on a victim's machine, it will start sending passwords to the destination address along with phone numbers, user IDs, callback numbers, DNS servers - the works.

This is a straight DialogBox application: no window class, so no message pump, and so no point in sending a WM_QUIT at exit - but the author is not the first to make this error.

The idea with Barok is that every copy is customized for a specific beneficiary, and all necessary data is packed into the customized executable. The server application is patched directly. Patch string lengths are checked, file offsets maintained. This is certainly not the most common way of configuring applications, but in this case, when a single file must sneak unnoticed onto a victim's system, it's the only way to go. Obviously client.exe version 2.1 will only necessarily work with version 2.1 of barok.exe - everything is dependent on the physical file offsets for the data to be modified.

## The Server

The server uses an unexported function in the Win32 network interface MPR.dll, WNetEnumCachedPasswords. This function is not available in the import library MPR.lib and is only found in the Windows 9x versions of the DLL. Therefore, the DLL has to be explicitly loaded and the virtual address of this function found. This very fact points to the program author not being totally asleep, even if the programming itself is rather shoddy.

The server must also be prepared for a user logging off without shutting down the machine. As Windows 9x has no authentic services and as a user logoff will exit all processes spawned by the user logon, another unexported function, RegisterServiceProcess, must be called when the server receives an indication from the operating system that a user logoff is imminent.

RegisterServiceProcess is a documented function, but it is not available in the import library KERNEL32.lib, and therefore KERNEL32.dll must be explicitly loaded and the function's virtual address found. Again, this points to the programmer being very adept at Win32.

Barok basically accesses only two Registry keys:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Network
HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Policies\Network

And two values found at each: DisablePwdCaching and HideSharePwds.

However, an attempt may be made to modify the DisableRegistryTools value under:

HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Policies\System

Which would prevent victims of the trojan from being able to ferret it out or simply turn it off.

There are also a number of calls to rather esoteric RAS functions: RasEnumEntries, which lists all addresses in a RAS phone book; RasGetEntryDialParams, which retrieves the connection information saved by the last successful call, including the entry name, the phone number called, the callback number if any, the user name, the user password, and the domain; and RasGetEntryProperties, which retrieves the country ID, the country code, the local area code, the local phone number, and DNS, WINS, and X25 information. Whoever wrote this program did really know what was what in Win32.

So even at this cursory glance it's apparent that the author is no dummy. It's important to understand that the Win32 API is extensive: there are thousands upon thousands of functions; and simply knowing of these connection hooks says a lot. The programming is the old 'copy and paste' method used so widely in Redmond, but the depth of knowledge is impressive.

There's been mention in the press that this trojan registers a window class, though no explanation has been given as to why this is important. The reason for registering a window class is apparent to any seasoned Win32 developer: the trojan of course wants to run as a single instance app, and one of the most efficient ways of ensuring this is to always check for instances of the registered class on startup. If an instance is found, the program can defer to the previous instance and exit at once.

Finally, there is the signature we've seen so many times before, at offset 3618h:

0000000000003610  0A 00 00 00 0A 00 00 00 62 61 72 6F 6B 20 2E 2E  ........barok ..
0000000000003620  2E 69 20 68 61 74 65 20 73 63 68 6F 6F 6C 20 73  .i hate school s
0000000000003630  75 63 6B 20 2D 3E 62 79 3A 73 70 79 64 65 72 20  uck ->by:spyder
0000000000003640  40 43 6F 70 79 72 69 67 68 74 20 28 63 29 20 32  @Copyright (c) 2
0000000000003650  30 30 30 20 47 52 41 4D 4D 45 52 53 6F 66 74 20  000 GRAMMERSoft
0000000000003660  47 72 6F 75 70 20 3E 4D 61 6E 69 6C 61 2C 50 68  Group >Manila,Ph
0000000000003670  69 6C 73 2E 00 00 00 00 00 00 00 00 2F 01 00 00  ils........./...


Considering the introductory comment lines in the worm script, it would seem the GRAMMERSoft Group either did not expect this machine to be put into the wild, or were rather proud of their work, or both.

## Barok 2.0

Compared to its precursor Barok 2.1, despite all its foibles, is a work of art and quality software engineering. For Barok 2.0 is a typically atrocious Microsoft MFC build, with all the classic warts and bloat factors making it burst at the seams. The client application for this version tips the scale at 1,060,921 bytes, of which over 800,000 bytes are used for extremely chunky code, and over 200,000 for Microsoft's wonderful incremental linking.

This is a straight, out-of-the-box MFC build, with default MFC version information; the inexcusable Ctl3d bitmaps; a string table that Arnie Schwarzenegger wouldn't be able to lift without an effort; the 'New' dialog script; and the MFC help cursor. Curiously, the server image contains no resources at all, yet is still over three times the size of version 2.1 at 53,258 bytes, linking statically with the Microsoft runtime instead of dynamically as version 2.1.

Further, both images get caught in the Microsoft 'let's try to make Windows 98 look good' trap, whereby file alignment is set default at 4096 bytes and not 512 as before. By version 2.1 the author of Barok was to learn about this snag too.

The build stamps indicate this version of the server was completed on Wednesday, January 26, 2000 at 7:38:04 AM UTC and the client on Thursday January 27, 2000 at 8:12:23 PM UTC.

It is also instructive that this build's About box contains the second email address found in the ILOVEYOU worm package, as well as information about the IRC channels where spyder and his cohorts at the GRAMMERSoft Group Mkt most likely hung out.

Again, both programs are built with the very latest release of MSVC - but the author appears to be rather new at this point to the package and perhaps Microsoft tools in general. The server does not contain debug info, but the client does, its source code location similar to that used for version 2.1, indicating that the same machine might have been used to create both versions, and that it might still be found (unless what's-his-name managed to get rid of it right under the noses of the NBI):

C:\Knowledge\barok\Setup

Further, as this debug image does not rely solely on an external program database, we also get the names of the actual source files used:

00000000000E3000  43 3A 5C 4B 6E 6F 77 6C 65 64 67 65 5C 62 61 72  C:\Knowledge\bar
00000000000E3010  6F 6B 5C 53 65 74 75 70 5C 4E 75 6D 45 64 69 74  ok\Setup\NumEdit
00000000000E3020  2E 63 70 70 00 00 00 00 25 64 00 00 00 00 00 00  .cpp....%d......
00000000000E3030  00 00 00 00 43 3A 5C 4B 6E 6F 77 6C 65 64 67 65  ....C:\Knowledge
00000000000E3040  5C 62 61 72 6F 6B 5C 53 65 74 75 70 5C 53 65 74  \barok\Setup\Set
00000000000E3050  75 70 2E 63 70 70 00 00 00 00 00 00 00 00 00 00  up.cpp..........
00000000000E3060  43 3A 5C 4B 6E 6F 77 6C 65 64 67 65 5C 62 61 72  C:\Knowledge\bar
00000000000E3070  6F 6B 5C 53 65 74 75 70 5C 53 65 74 75 70 44 6C  ok\Setup\SetupDl
00000000000E3080  67 2E 63 70 70 00 00 00 65 78 65 63 75 74 61 62  g.cpp...executab


The server has a signature similar to that found in version 2.1, this time at offset b038h:

000000000000B030  01 00 00 00 01 00 00 00 62 61 72 6F 6B 20 2D 3E  ........barok ->
000000000000B040  62 79 3A 73 70 79 64 65 72 20 40 43 6F 70 79 72  by:spyder @Copyr
000000000000B050  69 67 68 74 20 28 63 29 20 32 30 30 30 20 47 52  ight (c) 2000 GR
000000000000B060  41 4D 4D 45 52 53 6F 66 74 20 47 72 6F 75 70 00  AMMERSoft Group.


And another following the window class name at offset b340h:

000000000000B340  42 41 52 4F 4B 2E 2E 2E 20 73 74 75 64 65 6E 74  BAROK... student
000000000000B350  20 6F 66 20 61 6D 61 63 63 20 6D 6B 74 2E 20 70   of amacc mkt. p
000000000000B360  68 69 6C 73 20 2D 3E 62 79 3A 73 70 79 64 65 72  hils ->by:spyder
000000000000B370  20 20 40 43 6F 70 79 72 69 67 68 74 20 28 63 29    @Copyright (c)
000000000000B380  20 32 30 30 30 20 47 52 41 4D 4D 45 52 53 6F 66   2000 GRAMMERSof
000000000000B390  74 20 47 72 6F 75 70 00 2E 65 78 65 00 00 00 00  t Group..exe....


It works the same as version 2.1, but just like the documentation for the update says, it does not attempt to disable Registry Editor.