About a month ago, I was involved in an investigation that revealed a targeted attacker using an interesting variation of a well-known persistence mechanism - a technique that is relevant both to incident responders hunting for evil and penetration testers looking to add post-exploitation methods to their toolkit. Today, I'm going to talk about this persistence mechanism and discuss some ways you might go about identifying it in your environment.

I think that the majority of folks reading this blog have encountered malware that maintains persistence via the startup folder. The startup folder is a directory that may contain binaries, scripts or shortcut files. A folder exists for each user on the system as well as for "all users." On Windows 7, for example, the Administrator startup folder resides at "C:UsersAdministratorAppDataRoamingMicrosoftWindowsStart MenuProgramsStartup".

When a user successfully authenticates, Windows will attempt to execute any binary, run any script, or follow-up and execute any shortcut that is present within that user's startup folder. If scripts or applications are placed in the "all users" startup folder, these will be executed shortly after the system boots.

I often see the startup folder used legitimately to execute maintenance scripts written in Visual Basic or in Microsoft's batch scripting language. I also frequently see that applications install shortcut, or LNK, files within the startup folder that point to applications on disk. Malicious use of this directory, however, is most often associated with commodity malware - often accomplished by dropping an executable into the startup folder.

I've also seen a few variants of commodity malware that install a LNK file in the startup folder and deploy an EXE into a directory that the user can write to, like " C: users local settings emp ". LNK files contain several kinds of useful metadata, but for today's purposes we're interested in LNK files as pointers to other files.

In this recent case, we identified a novel technique that indirectly loads malicious scripts by means of LNK files in a user's start-up folder. The LNK file was designed to invoke the Windows scripting host (WSH). The WSH comes in both a GUI version, "wscript.exe", and a command-line version, "cscript.exe". The WSH can interpret Visual Basic scripts, commonly denoted by the file extension ".vbs", and Jscripts (Microsoft's implementation of JavaScript), commonly denoted by the file extension ".js". The malicious LNK file invoked "wscript.exe" to interpret a JScript file stored within a specific user's profile. Here's a cleaned-up excerpt parsed from the LNK file using lnk-parser, depicting the relative path to the WSH (in yellow) and an argument (in green) which points to a JScript file:

The JScript we found used an ActiveXObject object to create an instance of Internet Explorer and open a URL hosted by a code-sharing cloud service. Here's what that looks like:

This script connected to a remote system that provided command and control (C2) functionality , which included collecting system information from the infected machine and providing the attacker with the ability to execute commands via the command console, "cmd.exe". During analysis of the affected system, we found significant evidence in URL History for the Internet Explorer browser that depicted requests to the malicious URL. The requests for URLs looked like "http://hostname-4. legitcloudservice .com/?action=get&mt==". As depicted in the code snippet above, the base64-encoded string consisted of the Windows domain, username, and NetBIOS name values separated by the pipe (|) character.

Though somewhat convoluted and reliant on basic techniques, this persistence mechanism provides several advantages to an attacker. It avoids the need to create or execute a malicious binary on the targeted system, and similarly does not require any registry keys or settings to automatically load upon start-up or user login. This can help bypass application whitelisting and host-based intrusion prevention systems tuned to detect or block such activity. In this specific case, the attacker used network traffic generated by the malicious script to access legitimate, commonly-used web sites via HTTP. This traffic would blend into the normal "noise" of an enterprise network and evade detection.

One way to detect this form of persistence is to use an IOC that examines files within the Startup folder for references to the WSH. Investigators should examine each LNK file that this IOC identifies to determine whether the WSH is being used to launch a script; investigators should also analyze all scripts for malicious functions and network indicators. Here is an example IOC:

Network detection is a little trickier because an attacker could implement network communication in a multitude of ways, depending on the purpose of the script, the scripting language and the protocol. For the example we referenced, the URL parameters "?action=get&mt=" might make a good network indicator; here's an example SNORT signature to identify those parameters: