The Case of the Persistent Executable

This is the first of the 2 case studies which won me a signed copy of Windows Internals, 4th Edition, by Mark Russinovich, Microsoft last year.

I woke up last Saturday around 11:00 in the morning to find my friend sitting at the computer typing some document in MSWord, he then minimized the document and proceeded to open the D: drive from My Computer. My usually fast Windows responded extremely slowly to the double click. I sat bolt upright in my bed and asked him to repeat the procedure with the other drives. The same delay was noticed on the other drives too. I then asked him to right click on any drive expecting a change in the context menu due to the presence of an autorun file. The menu was intact. I then got down and sat at the chair and used the attrib command at the prompt for each drive. This is what I got.

Certainly signs of malicious presence. I used the type command to read the contents of autorun.inf although I knew what it would point at.

I then immediately fired Process Explorer to see if the process was running. Failing to find the process or a handle to it, I then used the attrib –s –h –r fppg1.exe to reset attributes and proceeded to delete it using del fppg1.exe. I repeated the same procedure with the autorun.inf file. Since I have 6 partitions on my hard drive, I wrote a bat file, named it clean.bat and saved it in %systemroot% with the following contents.

@echo off
attrib -s -h -r fppg1.exe
del fppg1.exe
attrib -s -h -r autorun.inf
del autorun.inf
echo All done
echo.

I then ran clean.bat from the console on each partition. Happy that my system was back to normal, I restarted explorer to remove the effects of the autorun.inf file on the default open option on the drives. I then proceeded to open F: drive using the double click through My Computer. I was surprised to see the delay occurring again. The attrib command confirmed my doubts. The two files were back. I decided to dump the strings from the fppg1.exe file to see if I could find any clues. I ran the strings utility and piped the output to a text file called fppg1.text.

The file contained loads of ASCII characters and just three APIs that I recognized. That didn’t help much.

I then fired up Process Monitor to see what process was writing these files to disk. I used two filters with Path contains autorun.inf then include and Path contains fppg1.exe then include. I was surprised to see which process was writing, setting attributes and querying information.

It wasn’t only explorer.exe that drained my happiness out of me.

I then right clicked on Explorer to view its stack when IRP_MJ_CREATE Operation was performed. The stack had one unfamiliar entry.

I used the find handle or dll feature of Process Explorer to search for amvo0.dll. The returned results didn’t raise my spirits.

The dll had attached itself to other processes I had opened after restarting explorer. I then opened up cmd, changed to C:\Windows\System32\ and used the attrib command to confirm my suspicions about the attributes of amvo0.dll. I wasn’t disappointed.

I suspected that there could be an associated executable also present in the same directory and hence used attrib amv*. With my suspicions confirmed, I used strings.exe to dump strings from amvo.exe and did a file compare with fppg1.txt. Bingo! They were the same files in essence. The dll amvo0.dll was making explorer.exe and the system process to recreate the files fppg1.exe and autorun.inf whenever they were not found in the root of the drives. I used attrib again to remove the system and hidden attribute from amvo.exe and amvo0.dll and deleted amvo.exe through the command prompt. The file amvo0.dll was in memory and hence could not be deleted. One shortcoming of Process Explorer, I found would have really helped me, was to unload dlls which would have allowed me to delete the file immediately. I used autoruns.exe, another of Sysinternals creations, and found that amvo.exe created a registry entry in HKCU\Software\Microsoft\Windows\CurrentVersion\Run that caused it to be run at system startup. With the file gone, I restarted my system and then deleted amvo0.dll manually, fppg1.exe and the autorun.inf file using the bat file.

Case closed. I then went on to start my morning.

5 thoughts on “The Case of the Persistent Executable”

  1. Very nice. I probably would have just screamed @ the antivirus or anti-spyware for not detecting the rogue processes/files. But seriously Windows security is just flawed. It is inherently insecure. Too many user programs and applications are allowed access to core system files. Thats why I am loving linux. No viruses/worms and malicious programs to be worried about.

    But seriously I would preffer having you scan my system for security issues rather trust Avast AV 🙂 Do post the 2nd case study also 🙂

  2. Windows is a secure operating system. I wouldnt say it is the most (which for several reason, is obviously not) secure OS, but i stand by what I say. The problem lies with the user. For example a security aware user would never double click on a removable drive in my computer before verifying if the root of the drive does not contain a autorun.inf file and would always disable autorun on drives in general. The user is part of the security of a system. If the user is flawed then the system is too.

    Using the administrator account for mundane tasks is definitely not advisable. You could always use a restricted account to check emails, play music and watch movies. The administrator account should only be used for administrative tasks, not otherwise. As Spiderman's Uncle has said: “With great powers come great responsibilities” 🙂

  3. “The problem lies with the user. For example a security aware user would never double click on a removable drive in my computer before verifying if the root of the drive does not contain a autorun.inf file”

    That's the craziest thing I've heard all week. It is obviously a bad design to have one action which will unpredictably either: a) display the contents of a drive, b) run arbitrary code contained on the drive, or c) do b. then a. That's also setting aside the behavior of automatically running arbitrary code simply when a new drive is detected.

    This was an error on the part of Windows developers (though a well intentioned one), and it's something that other modern operating systems do not do. Blaming it on the user is counter-productive.

  4. Maybe I was a bit harsh when I said that the problem lies with the user. Autorun was devised to increase interactivity, simplify application installation for non-technical users and lower the cost of software support calls. It’s a feature, albeit heavily abused as a malware attack vector. Security conscious users would either disable Autorun or use a restricted account when using the computer or both. In any case the user would be expected to practice caution when accessing USB drives, atleast after he has been informed of the consequences.

Leave a Reply

Your email address will not be published. Required fields are marked *