Autoruns

  • 2/17/2017

Autoruns and malware

One of the goals of most malware is to remain active on an infected system indefinitely. Malware has therefore always used ASEPs. Years ago, it usually just targeted simple locations such as the Run key under HKLM. As malware has become more sophisticated and difficult to identify, its use of ASEPs has become more sophisticated as well. Malware has been implemented as Winsock providers and as print monitors. Not only are such ASEP locations more obscure, but the malware doesn’t show up in a process list because it loads as a DLL in an existing, legitimate process. Malware has also become more adept at infecting and running without requiring administrative privileges, because there are increasing numbers of users who only ever have standard user privileges.

In addition, malware often leverages rootkits, which subvert the integrity of the operating system. Rootkits intercept and modify system calls, lying to software that uses documented system interfaces about the state of the system. Rootkits can hide the presence of registry keys and values, files and directories, processes, sockets, user accounts, and more, or they can make software believe something exists when it doesn’t. In short, a computer on which malware has run with administrative privileges cannot be trusted to report its own state accurately. Therefore, Autoruns cannot always be expected to identify malicious autostart entries on a system.

That said, not all malware is that sophisticated, and there are still some telltale signs that can point to malware:

  • Entries with a well-known publisher such as Microsoft that fail signature verification. (Unfortunately, not all software published by Microsoft is signed.)

  • Entries with an image path pointing to a DLL or EXE file that is missing Description or Publisher information (unless the target file is not found).

  • A common Windows component that is launched from an unusual or nonstandard location—for example, svchost.exe or another service launching from C:\Windows or C:\Windows\SysWOW64 (instead of from System32) or from C:\System Volume Information.

  • Entries with names that can be mistaken for common Windows components, such as those with slight misspellings—for example, “Isass.exe” with a capital “I” instead of a lower-case “L”, “scvhost.exe” instead of “svchost.exe,” or “iexplorer.exe” with the extra “r” at the end.

  • Entries for which the file date and time of the launched program correspond to when problems were first noticed or a breach is discovered to have occurred.

  • Disabling or deleting an entry, pressing F5 to refresh the display, and finding the entry still present and enabled. Malware will often monitor its ASEPs and put them back if they get removed.

Malware and antimalware remains a moving target. Today’s “best practices” will seem naïve and insufficient tomorrow.

There are some entries you might come across that seem suspicious but are innocuous:

  • A default installation of Windows Vista might have a small number of “File not found” entries on the Drivers tab for NetWare IPX drivers and for “IP in IP Tunnel Driver.”

  • Default installations of Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 might have a WMI entry named “BVTConsumer”. This code is inoperative and can be safely ignored.

  • A default installation of Windows 7 might have a small number of entries on the Scheduled Tasks tab under “\Microsoft\Windows” that show an entry name but no further information.

  • As explained in the “KnownDLLs” section earlier in this chapter, on 64-bit Windows Autoruns reports “File not found” for WOW64 support DLLs in the SysWOW64 directory. These known DLLs exist only in the System32 directory.