This is the area for research on the "Iraq Oil" worm being directed by myNetWatchman, and it's where I'm parking the things I find. Collaborators are Lawrence Baldwin, Philip Sloss, and Steve Friedl me.

We believe that Lawrence's advisory was the first public announcement of the details of this worm, and it shows the benefits of distributed intelligence-gathering such as provided by myNetWatchman.

More detailed analysis of the packet behavior and distribution of this worm can be found in the my NetWatchman Research Alert, and it was first released publicly in the DSL Reports Security Forum.

There are a few "holes" in the C++ code when I simply ran out of available time to reverse engineer this worm. It's unlikely that I'll pick up on it much beyond what's here now. This page first went up Sunday night, 15 Dec 2002

iraq_oil_upx.bin (MD5: 6fe6ce9373d784bcc5f65ab5cee39010) -- original binary that is UPX compressed: this was the file that was captured over the net. 16,896 bytes (renamed from .EXE to .BIN to avoid self-execute upon download).
NOTE: file removed, contact me by email if you need it.
iraq_oil.bin (MD5: 345a5df8919fefd52053711535bf8c31) -- the worm binary after uncompressing. 40,960 bytes (also renamed from .EXE to .BIN).
NOTE: file removed, contact me by email if you need it.
iraqworm.cpp -- C++ pseudocode from my reverse engineering.

An important note on the pseudocode in iraqworm.cpp: only the standard library functions have standard names, the rest are all made up by S. Friedl. And the code is not designed to compile or *exactly* match the actual code - it's meant to mainly convey the purpose without getting bogged down in details. We're using C++ just for some of the "better C" features.

I'll release my IDA Pro .idb file of the binary once I get my work mostly finished.

Tidbits

The worm as captured was UPX compressed, but was unpacked for analysis. The disassembled version has no references to any kind of compression.
This worm doesn't appear to talk to the registry or the local filesystem in any way.
The binary itself doesn't provide any clues as to its origin or of why the name "iraq_oil.exe" was chosen.
The code uses the rand() function to generate IP addresses, but it does so badly: this function returns values 0..0x7FFF, so the IP addresses are random only to 30 bits. But because of host/net word order differences, the 0x7F byte is in IP address octets 2 and 4.
This suggests, and Philip Sloss's packet captures confirm, that if the second or fourth octet of your IP address is in the range 128..255, you'll not see any scans from this worm: it turns out that my IP network at home ( 64.170.X.X ) immune.
The code seems to make no provisions for skippin obviously bogus IP addresses, such as 0-dot-anything or 255-dot-somthing. It seems that it could even trip across address 127.0.0.1 and would therefore infect itself. It's dumb.
There are 100 threads spawned that do attacks and there is no provision for stopping, shutdown, or avoiding other similar worms being installed on the same host. There is no sunset provision where it stops propogating after a certain date.
The attack code first tries to do a connect() to the target's port 445/tcp, and it waits up to five seconds for it to complete. If it does, then the more in-depth probing using the Win32 "Net" functions is attempted. This is clever in that the "Net" functions don't seem to provide this level of timeout control, so the worm can bang through address ranges much more quickly without getting hung by machines that aren't around.
The code does have some bugs, where the wrong sizes of buffers are declared and the like, but I don't see any obvious ways to exploit them. There is at least one memory leak. In general, the code is written poorly.
The executable ("iraq_oil.exe" in our captures) is statically bound to three DLLS: KERNEL32.DLL, MPR.dll, and WSOCK32.DLL, and it uses LoadLibrary to load NETAPI32.DLL at runtime.
This worm is almost certainly limited to the NT-based Windows systems (Win2000, XP) and not the personal systems (95/98/ME). This is because the ADMIN$ and C$ shares are not typically present on the personal systems, and they also do not support the "at" task scheduler protocol the same way. It would not be a surprise if this only infected servers. I believe that NT4 doesn't expose 445/tcp.

Rough program flow

The details can be found in the disassembly, but this is the broad flow of the program:

Do a bit of initialization, including loading NETAPI32.DLL
Launch 100 worker threads, and the main thread sleeps forever
Worker thread generates a random, 32-bit IP address
Attempts a connect() to 445/tcp, waiting up to five seconds
If no connection, it moves onto the next one
If a connection was made, it tries to make an anonymous connection to the IPC$ share point on the target machine, via the \\ipaddress\IPC$ resource. It's done with an anonymous connection.
If this anonymous connection is made, it enumerates every user and attempts to brute-force each one with a small (and odd) set of built-in passwords. Passwords are attempted in this order:
```
blank     123       1         asdfgh    !@#$%^&
admin     1234      !@#$      !@#$%     !@#$%^&*
root      123456    asdf      !@#$%^    server
111       654321
```
Without a successful connection, it moves on to the next user.
With a successful connection, it attempts to copy itself (name obtained by GetModuleHandle()) to the target system: it stops once any copy has been successful:
```
COPY myFileName \\remoteIP\\Admin$\system32\iraq_oil.exe
COPY myFileName \\remoteIP\\c$\winnt\system32\iraq_oil.exe
```
Once the target has been copied, it obtains the system's remote time clock in order to schedule a job for execution by the "at" service. It tries to schedule the job 2 minutes into the future, though due to the odd math used, it's possible that servers in time zones east of Grenwich may get scheduled incorrectly.
Once the remote server has been infected, it moves on to the next random IP.

Other resources

Trend Micro's entry for what they call "WORM_LIOTEN.A".
Symantec's entry for what they call "W32.HLLW.Lioten".
McAfee's entry for what they call "W32/Lioten.worm".
Sophos AV entry for what they call "W32/Lioten-A".

Credits

Lawrence Baldwin's myNetWatchman service, which collected the reports and managed to snag the "iraq_oil.exe" worm itself.
Philip Sloss, who helped Lawrence with the dynamic packet tracing and analysis.
Steve Friedl me, who did the static analysis.
DataRescue's IDA Pro Disassembler, which made this reverse engineering possible.

Does this site look plain?

Steve Friedl's Research Projects

"Iraq Oil" worm reverse engineering & analysis

Tidbits

Rough program flow

Other resources

Credits