Security

Follow these steps to troubleshoot a Trojan horse

Nine steps you can use to recover from a Trojan Horse infection


Recently, I got a telephone call from a frantic user who booted her computer and noticed a new, mysterious shortcut (icon) on her desktop. The image was a risque picture—always a bad sign. The user was worried about potential damage to her system caused by a hacker.

This week, I’d like to share the steps I took to troubleshoot this problem, which included editing the registry. If you’ve encountered similar problems, I invite you to share your experiences with fellow TechRepublic members.

Step 1: Find or make an ERD
My first question to this Windows 98 user was, "Do you have a good boot disk?" In a disk caddy, she found a disk that was clearly labeled "Win98 boot." That was good news, because without knowing what damage had been done to the computer, any disk we would have created from scratch would have been suspect.

If you or your users don’t keep a good boot disk or an Emergency Repair Disk (ERD) handy, you may want to make creating such a disk part of your standard operating procedure when you deploy a workstation. Many tech support analysts keep boot disks for all flavors of Windows in their toolkits, just in case.

When you find yourself in the field with no access to your toolkit, here’s another option: Surf over to Bootdisk.com and use the free downloads there to create boot disks for every operating system from DOS 3.3 through Windows XP.

Step 2: Reimage if you can
If the user’s files are backed up on disk or on the network—and that’s a critical "if" test—you may be able to save troubleshooting time by simply reimaging the machine. That wasn’t an option in this case, but it sure would have been easier than trying to talk this nervous user through the cleanup process.

Step 3: Identify the enemy
I asked the user to read the label associated with the new icon, and she said "1-1-35-1," which didn’t sound like any bugs I’d dealt with before. While the user waited on the phone, I searched the Usenet Archive on Google for that string but came up with no clues.

I had the user go to the DOS command prompt, change the directory to C:\Windows\Desktop, and enter DIR 1* at the command prompt. Doing so revealed that the file’s extension was .exe—another bad sign.

Step 4: Blow away the bad files
Next, I asked the user to delete the desktop icon. Unfortunately for the troubleshooting efforts, one of her coworkers stopped by to help. I heard the other person say, "I know how to delete it," and then, "Hey, what’s that?"

The other user had tried to click-and-drag the object over to the Recycle Bin. Unfortunately, in making the attempt, the other user apparently had inadvertently launched the application. The result was that there were now two identical, offensive images on the desktop. I politely asked the user who called me to politely ask her coworker to leave the computer alone.

At this point, I had the user right-click on the icon and choose Delete from the context menu. When she received an Access Denied error, I assumed the program must be running in the background.

I instructed the user to give the three-finger salute by pressing [Ctrl][Alt][Delete] to display the Task Manager. Sure enough, two separate instances of a program called 1-1-35-1 were running.

The user selected each of those apps in turn and clicked End Task. Both times, the system reported that the application was busy. Fortunately, we were able to terminate the applications by clicking End Task a second time. Redisplaying the Task Manager confirmed that the processes had been stopped, and the user was then able to delete the desktop icons by right-clicking and choosing Delete.

Step 5: Check the whole disk
As a precaution, I asked the user to go to Start | Find | Files And Folders and do a search of the entire hard drive for the file skeleton 1*, which yielded no files or folders found.

Did I mention that Outlook Express was installed on this machine? Fearing the worst, I had the user launch the application and check the Sent folder. Fortunately, there was no evidence that the bug had done any malicious mailing.

Step 6: Check Add/Remove
After deleting the desktop icons, I had the user go to Start | Settings | Control Panel | Add/Remove to look for suspicious applications. There, we found two instances of a program whose name included the string Just***** along with the 1-1-35-1 from the label we had seen on the desktop.

When the user attempted to remove these applications, the message windows that appeared were in German—yet another bad sign—but we were able to successfully remove the offending applications using the Add/Remove Programs tool.

Step 7: Check the registry
I didn't feel confident that I could talk this user through the process of checking the registry, so I decided to make an on-site support call and check it myself. The user was anxious to work on a document, and I told her it was probably safe to do so. "But," I told her before we hung up, "don't reboot the machine yet."

When I got to the site, we closed all open applications, and I went to Start | Run and launched Regedit. I exported a copy of the registry to a file named oldreg, just in case. Next, I looked for suspicious entries in the Software folders under HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and HKEY_USERS.

In two of those Software folders, I found entries labeled Just*****, with subfolders labeled 1-1-35-1, and strangely named files ending in Dialer.exe.

I deleted those entries faster than you can say dialer.

Step 8: Scan, scan, scan
This client had antivirus software, but it wasn't running! As a final precautionary measure before rebooting, we scanned the entire disk. Fortunately, no infected files were found, and we had a clean restart.

Step 9: Reinforce security policies
In a secure network environment, one equipped with firewalls and proxy servers, this little Trojan horse probably would never have had a chance to deliver its payload. Access to the site that carried the malware would have been denied.

I heaped praise upon the user who had the good sense to pay attention to her desktop environment, to realize that the offensive icon had no place on a business machine, and to call tech support instead of trying to deal with the problem herself.

So who caused the problem? One of the caller's coworkers admitted to using the machine to surf the Web the night before. When asked about it, that person didn't remember clicking on anything that would have authorized a Web site to install an application or shortcut on the local hard drive. Mm hmm.

In many companies, that user would have been terminated, or at least "written up." In this small company, in addition to being humiliated, the user had to endure a lecture from the on-call tech support technician—yours truly—regarding security policies. Here are the highlights from my rant:
  • This computer is networked. This computer appears to be stand-alone, but it's actually connected to the building network for Web access. Careless surfing not only could have damaged this machine, but it could have infected your business neighbors' machines as well.
  • This computer is for business use only. Surf your brains out if you want to, but do it on your computer, in your home.
  • Read before you click. I'd like to believe that the careless surfer didn't intentionally click on anything that said "Okay to install," or "Yes to install." To avoid accidentally clicking such links, I advised, Read The Full Screen (RTFS).
  • Do not install. I stressed to all the users in this company that they should never install software off the Web onto their machines without prior authorization from the business owner or the on-call support technician.
  • Log out. I reminded the users not to leave the workstation when they're logged in to their e-mail accounts, and to close out all applications—including the Web browser—before they leave for the day.

Until I convince the business owner to upgrade the workstation's operating system, the only passwords for which the users are responsible apply to their e-mail and accounting applications. I reminded them not to leave those passwords where snoops can get to them, and not to share them with fellow users.

If you don't have written security policies in your organization, how will your users know what they can and cannot do with their systems? You can download TechRepublic's virus protection policy and customize it according to the standards established by your employer.

Calling all support techs
Have you had to clean up a machine infected by a virus or Trojan horse lately? To share your experience with fellow TechRepublic members, post a comment below or write to Jeff.

 

Editor's Picks

Free Newsletters, In your Inbox