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 target="_blank">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 href="https://code.google.com/p/lnk-parser/">lnk-parser,
depicting the relative path to the WSH (in yellow) and an argument
(in green) which points to a JScript file:
![]()
src="https://www.fireeye.com/content/dam/legacy/ammo/JScript-File.jpg"
width="660" height="42" />
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:
![]()
src="https://www.fireeye.com/content/dam/legacy/ammo/Image-2.jpg"
width="655" height="246" />
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:
![]()
src="https://www.fireeye.com/content/dam/legacy/ammo/Example-IOC.png"
width="373" height="119" />
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:
![Image 4]()
src="https://www.fireeye.com/content/dam/legacy/ammo/Image-41.jpg"
width="659" height="62" />
