Scribd
Upload
13 views3 pages

Detecting Malware Persistence Mechanisms

This document discusses techniques for detecting malware persistence mechanisms, including: - Timeline analysis can help determine when a system was compromised and reveal artifacts of unknown persistence mechanisms. The author discovered a keylogger's mechanism by analyzing DLL modifications in a timeline. - The DLL search order can be hijacked to load malicious DLLs, as the author found on a system where ntshrui.dll was loaded from C:\Windows instead of the system32 folder. - Incorporating intelligence into timeline creation tools, like checking for suspicious paths in Registry keys, can help detect persistence without relying only on timestamps.

Uploaded by

williferr281
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
13 views3 pages

Detecting Malware Persistence Mechanisms

This document discusses techniques for detecting malware persistence mechanisms, including: - Timeline analysis can help determine when a system was compromised and reveal artifacts of unknown persistence mechanisms. The author discovered a keylogger's mechanism by analyzing DLL modifications in a timeline. - The DLL search order can be hijacked to load malicious DLLs, as the author found on a system where ntshrui.dll was loaded from C:\Windows instead of the system32 folder. - Incorporating intelligence into timeline creation tools, like checking for suspicious paths in Registry keys, can help detect persistence without relying only on timestamps.

Uploaded by

williferr281
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

HowTo: Detecting Persistence Mechanisms

[Link]/2013/07/[Link]

This post is about actually detecting persistence mechanisms...not querying them, but
detecting them. There's a difference between querying known persistence mechanisms,
and detecting previously unknown persistence mechanisms used by malware; the former
we can do with tools such as AutoRuns and RegRipper, but the latter requires a bit more
work.
Detecting the persistence mechanism used by malware can be a critical component of an
investigation; for one, it helps us determine the window of compromise, or how long it's
been since the system was infected (or compromised). For PCI exams in particular, this is
important because many organizations know approximately how many credit card
transactions they process on a daily or weekly basis, and combining this information with
the window of compromise can help them estimate their exposure. If malware infects a
system in a user context but does not escalate it's privileges, then it will mostly likely start
back up after a reboot only after that user logs back into the system. If the system is
rebooted and another user logs in (or in the case of a server, no user logs in...), then the
malware will remain dormant.

Detecting Persistence Mechanisms


Most often, we can determine a malware persistence mechanism by querying the system
with tools such as those mentioned previously in this post. However, neither of these tools
is comprehensive enough to cover other possible persistence mechanisms, and as such,
we need to seek other processes or methods of analysis and detection.

One process that I've found to be very useful is timeline analysis. Timelines provide us with
context and an increased relative confidence in our data, and depending upon which data
we include in our timeline, an unparalleled level of granularity.

Several years ago, I determined the existence of a variant of W32/Crimea on a system


(used in online banking fraud) by creating a timeline of system activity. I had started by
reviewing the AV logs from the installed application, and then moved on to scanning the
image (mounted as a volume) with several licensed commercial AV scanners, none of
which located any malware. I finally used an AV scanner called "a-squared" (now
apparently owned by Emsisoft), and it found a malicious DLL. Using that DLL name as a
pivot point within my timeline, I saw that relatively close to the creation date of the malicious
DLL, the file C:\Windows\system32\[Link] was modified; parsing the file with a PE
analysis tool, I could see that the PE Import Table had been modified to point to the
malicious DLL. The persistence mechanism employed by the malware was to 'attach' to a
DLL that is loaded by user processes that interact with the keyboard, in particular web
browsers. It appeared to be a keystroke logger that was only interested in information
entered into form fields in web pages for online banking sites.

1/3
Interestingly enough, this particular malware was very well designed, in that it did not write
the information it collected to a file on the system. Instead, it immediately sent the
information off of the system to a waiting server, and the only artifacts that we could find of
that communication were web server responses embedded in the pagefile.

Something else to consider is the DLL Search Order "issue", often referred to as hijacking.
This has been discussed at length, and likely still remains an issue because it's not so
much a specific vulnerability that can be patched or fixed, but more a matter of functionality
provided by the architecture of the operating system.

In the case of [Link] (discussed here by Nick Harbour, while he was still with Mandiant),
this is how it worked...[Link] is listed in the Windows Registry as an approved shell
extension for Windows Explorer. In the Registry, many of the approved shell extensions
have explicit paths listed...that is, the value is C:\Windows\system32\some_dll.dll, and
Windows knows to go load that file. Other shell extensions, however, are listed with implicit
paths; that is, only the name of the DLL is provided, and when the executable
([Link]) loads, it has to go search for that DLL. In the case of [Link], the
legitimate copy of the DLL is located in the system32 folder, but another file of the same
name had been created in the C:\Windows folder, right next to the [Link] file. As
[Link] starts searching for the DLL in it's own directory, it happily loaded the
malicious DLL without any sort of checking, and therefore, no errors were thrown.

Around the time that Nick was writing up his blog post, I'd run across a Windows 2003
system that had been compromised, and fortunately for me, the sysadmins had a policy for
a bit more extensive logging enabled on systems. As I was examining the timeline, starting
from the most recent events to occur, I marveled at how the additional logging really added
a great deal of granularity to thing such as a user logging in; I could see where the system
assigned a token to the user, and then transferred the security context of the login to that
user. I then saw a number of DLLs being accessed (that is, their last accessed times were
modified) from the system32 folder...and then I saw one ([Link]) from the C:\Windows
folder. This stood out to me as strange, particularly when I ran a search across the timeline
for that file name, and found another file of the same name in the system32 folder. I began
researching the issue, and was able to determine that the persistence mechanism of the
malware was indeed the use of the DLL search order "vulnerability".

Creating Timelines
Several years ago, I was asked to write a Perl script that would list all Registry keys within a
hive file, along with their LastWrite times, in bodyfile format. Seeing the utility of this
information, I also wrote a version that would output to TLN format, for inclusion in the
timelines I create and use for analysis. This allows for significant information that I might
not otherwise see to be included in the timeline; once suspicious activity has been found, or
a pivot point located, finding unusual Registry keys (such as those beneath the CLSID
subkey) can lead to identification of a persistence mechanism.

Additional levels of granularity can be achieved in timelines through the incorporation of


intelligence into the tools used to create timelines, something that I started adding to
RegRipper with the release of version 2.8. One of the drawbacks to timelines is that they
will show the creation, last accessed, and last modification times of files, but not
2/3
incorporate any sort of information regarding the contents of that file into the timeline. For
example, a timeline will show a file with a ".tmp" extension in the user's Temp folder, but
little beyond that; incorporating additional functionality for accessing such files would allow
us to include intelligence from previous analyses into our parsing routines, and hence, into
our timelines. As such, we may want to generate an alert for that ".tmp" file, specifically if
the binary contents indicate that it is an executable file, or a PDF, or some other form of
document.

Another example of how this functionality can be incorporated into timelines and assist us in
detecting persistence mechanisms might be to add grep() statements to RegRipper plugins
that parse file paths from values. For example, your timeline would include the LastWrite
time for a user's Run key as an event, but because the values for this key are not
maintained in any MRU order, there's really nothing else to add. However, if your
experience were to show that file paths that include "AppData", "Application Data", or
"Temp" might be suspicious, why not add checks for these to the RegRipper plugin, and
generate an alert if one is found? Would you normally expect to see a program being
automatically launched from the user's "Temporary Internet Files" folder, or is that
something that you'd like to be alerted on. The same sort of thing applies to values listed
in the InProcServer keys beneath the CLSID key in the Software hive.

Adding this alerting functionality to tools that parse data into timeline formats can
significantly increase the level of granularity in our timelines, and help us to detect
previously unknown persistence mechanisms.

Resources
Mandiant: Malware Persistence without the Windows Registry
Mandiant: What the fxsst?
jIIR: Finding Malware like Iron Man
jIIR: Tracking down persistence mechanisms

3/3

Common questions

Powered by AI

Timeline analysis is critical because it contextualizes incidents by providing details such as the creation, modification, and last accessed times of files. It helps analysts identify suspicious activities and potentially discover malware presence and mechanisms that are not detected through standard queries . However, its limitation lies in its inability to provide content information about files or events, which necessitates secondary analysis to understand the implications of file modifications or accesses .

The DLL search order issue impacts system security by allowing unauthorized loading of malicious DLLs simply by placing them in directories that the program searches before the directories containing legitimate DLLs. This issue is not a vulnerability per se, but a feature of Windows that can be exploited for persistence since malware can persist by masquerading as legitimate DLLs, thus bypassing regular security checks .

Malware that immediately transfers keystroke data to a server avoids leaving persistent file traces that could be detected by traditional analysis tools. This design prevents the creation of logs or files that can be inspected for malware activity, thus requiring investigators to use advanced methods like analyzing network traffic patterns or investigating server responses stored in volatile memory areas such as the pagefile .

Implicit paths pose a security risk because they require the system to search for the DLL, starting with directories nearer to the application binary. This behavior allows attackers to place malicious DLLs in high-priority directories such as next to explorer.exe, which may be loaded instead of the legitimate DLL due to this search order, enabling stealthy persistence .

Intelligence incorporation into tools like RegRipper enhances timeline analysis by adding context-specific alerts and checks based on past analyses. By incorporating intelligence, tools can identify potentially suspicious patterns or anomalies — such as file paths from uncommon directories — which increases timeline granularity and aids in detecting previously unknown persistence mechanisms, potentially alerting for automatically launched programs from suspicious locations like 'Temporary Internet Files' .

Creating timelines can enhance the detection of registry-based persistence by mapping the changes in Registry keys over time, allowing the analyst to identify unusual or suspicious entries. Timelines can pinpoint when specific registry keys were modified, potentially indicating the activation time of persistence mechanisms, and by integrating intelligence, they can selectively highlight keys related to known malware behaviors .

Modifying the PE Import Table helps malware persist by redirecting legitimate program functionality to load malicious code under the guise of legitimate processes. This redirection complicates detection because the malware can operate under an apparent legitimate context, which prevents traditional detection mechanisms from recognizing it as anomalous, thus maintaining the system’s appearance of integrity .

Incorporating functionality for assessing binary file contents into timeline tools helps in malware detection by enabling the tools to determine whether a file, although seemingly innocuous, contains executable data or other payloads indicative of malware. By analyzing contents, these tools can raise alerts for files whose file types or contents do not match expected harmless categories, allowing for more accurate assessments of potential risks .

Querying known persistence mechanisms involves using tools like AutoRuns and RegRipper to identify potential hooks used by malware based on pre-defined signatures and paths. Detecting previously unknown persistence mechanisms, however, requires more complex investigative methods like timeline analysis because these mechanisms do not have identifiable fingerprints and might involve creative ways of achieving persistence that are not documented or detectable by standard toolsets. This form of detection is crucial in investigations to establish the compromise timeline and analyst confidence in the data collected .

Identifying the window of compromise allows organizations to estimate the duration during which transactions may have been vulnerable to unauthorized interception by malware. This estimation helps determine the volume of potentially compromised transactions, aiding in the assessment of financial exposure and informing decisions on reporting and remediation efforts .

You might also like