Daily Blog #22: 7/14/13 Sunday Funday Winner

Sunday Funday winner by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
           We had three great submissions yesterday to our Sunday Funday contest. The question was:
"It's believed that a user account had an interactive login on a Windows Server 2008 R2 system. The suspect is thought to be a senior IT architect and may have used anti-forensic techniques to hide his activities. Please answer the following:
1. Where by default would you find evidence of an interactive login, please list all locations
2. What would you do to determine if anti-forensic methods were taken
3. What would your next steps be"

I had three good responses but the best came from Harlan Carvey and 'Steve M'. I'm going to post both of their answers and then explain which one I chose and why. 

Here is Harlan's answer:
Windows 2008 R2 system

1. Where by default would you find evidence of an interactive login, please 
   list all locations

An interactive logon can be performed locally, at the keyboard/console, or
remotely via Terminal Services.  For just the login information itself, 
artifacts that you'd want to check include:

Security Event Log, specifically event IDs 4648 (explicit credentials attempted)
and 4624 (successful logon).

I would then check pertinent Registry entries to determine if Terminal Services
were enabled, and that remote, interactive logins were allowed.  I would verify
the settings for the Terminal Services Windows service, allowing it to start at
system boot, and then check the fDenyTSConnections value within the System 
Regitry hive:

\ControlSet00n\Control\Terminal Server\fDenyTSConnections - should be 0 to 
allow connections

*Note: ControlSet00n refers to the control set marked as 'current' in the
System hive

http://technet.microsoft.com/en-us/library/ee891289(v=ws.10).aspx Microsoft-Windows-TerminalServices-LocalSessionManager - event IDs 21 and 22
for session logon and shell start, respectively.  Also, look to event IDs 23
and 24, for session logoff and session disconnect, respectively.

http://technet.microsoft.com/en-us/library/ee891120(v=ws.10).aspx Microsoft-Windows-TerminalServices-RemoteConnectionManager
event ID 1146 (remote control session initiated)
event ID 1147 (remote control session succeeded)  

I would also check the last modification time for the NTUSER.DAT hive for
the account in question.  

I would then determine if any VSCs were available by first visually examining
the contents of the SPP-clients Registry key, as well as the contents of
the System Volume Information folder.  If VSCs are available, I would mount
the image file using the VHD or VMDK methods outlined in WFAT 3/e, and 
sweep the VSCs (using Corey Harrell's rip-vsc.bat batch file as a basis)
for the last modification time of the NTUSER.DAT hive file, as well as
check for any differences in user profiles, specifically accounts that may
have existed at one point, but no longer do.

If the account used to logon to the system is a local account, I would 
parse and examine the SAM hive file for indications of account activity 
(last logon, account creation, last failed logon attempt, etc.).  

Any examination of the SAM hive (as well as the Software, System, and
Security hives) should include not just those hives found in the 
system32\config folder, but also the system32\config\RegBack folder, as
well.  Be sure to note the creation/last modification times of those 
files, and sweep available VSCs, as mentioned above.
If the account is a domain account (check the ProfileList key within the
Software hive, and check the account SID against the local account SIDs...)
then I would pursue retrieving the Security Event Logs from a central 
location in order to determine logon activity.
2. What would you do to determine if anti-forensic methods were taken

Anti-forensics can cover a wide range of activities.

I would look for:

- indications of application installation (and removal) via the 
Application-Experience/Operational Event Log, as well as via Registry 
artifacts such as the Uninstall and MSIs keys. 

- indications of program execution in accordance with:

This includes the appcompatcache values, UserAssist, etc.  Windows 2008 R2
does not perform application prefetching by default, but if the system had
been configured to do so, I would perform analysis of these files, as well.
Just because it's not enabled out of the box doesn't mean that I wouldn't 
check and see if there were such files.

Along with these, I would examine less obvious indications of program execution
artifacts, including the user's MUICache entries, as well as others listed in
the above listed blog post.  Some of these are entries that are not "cleaned
up" by commonly used "cleaner" tools, so they would likely provide some 
excellent indications of activity.  I would also look to the Direct* and 
Tracing keys, as indicated in the above listed blog post.

- examine the contents of the user shellbags artifacts; this may provide 
indications of access to resources where other artifacts may have been 
removed and are absent.  For example, these artifacts may show indications 
of access to other systems within the infrastructure, as well as web-based
access (FTP via Windows Explorer) and access to removable devices.  These may
also illustrate access to Control Panel applets and functionality that could
be correlated with other activity to indicate the removal of data (anti-

Note: I would not assume that resource time stamps embedded within the
shellbags artifacts would, nor should, be consistent with logon sessions
for the user, as a means for determining indications of the use of anti-
forensics techniques.  First off, Windows 2008 R2 does not update last 
accessed times on files, by default (this is trivial to verify).  Second, 
actions outside of the purview of the creation of shellbags artifacts on 
Windows 2008 R2 systems can cause modifications/changes in the last 
modification time of the resource (usually a folder).  Third, when the
shellbags artifacts are created, the FILETIME time stamps from NTFS are
translated into DOSDate format time stamps, which includes truncating the
time value to the second, and then multiplying the second value times 2. 
As such, the embedded DOSDate creation time of the resource can be "off" 
significantly (with respect to seconds) from the 'real' creation time.

- I would check the LastWrite time of the Policy\PolAdtEv key within the Security
Registry hive, to see if the audit policy had been modified 'recently'.  This 
would have an impact on what information you would expect to find within the
Windows Event Logs; verify the previous settings by accessing the same Registry
information in previous versions of the Security hive file, if available.

- I would determine if the user profile(s) used had any web browser history
intact, and then look for indications of searches for information regarding
anti-forensics activities or tools, as well as downloads of files and/or 
tools.  I would also parse the pagefile and unallocated space for web history
artifacts, paying particular attention to items such as queries to Piriform
(creators of CCleaner), as well as searches for anti-forensics tools and

- If I were to find indications of user activity associated with a specific
account, I would examine the contents of the user profile, including items
such as Recent folder shortcut/LNK files, as well as Jump Lists.  Indications
of activity, with no corresponding *.automaticDestinations-ms Jump Lists may
indicate the use of anti-forensics tools and techniques.  

I would compare this information (or lack thereof) to what I find (or don't)
in the user profile.  For example, some anti-forensics tools will delete the
user's RecentDocs key all together, while others will delete all values and
subkeys.  I would check other locations in the user's Registry hives that 
would indicate access to files, in accordance with:

For example, if the user had entries in their TrustRecords Registry key, 
indicating access to MS Office documents accessed via the network, but no 
corresponding Jump Lists indicating the use of MS Office applications, 
this may be an indication of the use of a tool such as "CCleaner".  

- I would look for indications of lateral movement, from the system in question,
in accordance with:

If the account used is a domain account, this is something I would strongly 
consider.  Anti-forensics techniques involve the use of activities to hide 
user actions and interaction on a system, and one way to do so is to move
laterally to another system.  If the IT admin is able to access this system
via Terminal Services, it is likely that they could also access other systems,
as well, so I would check the contents of the user's "Terminal Server Client\
Default" and "Servers" keys to see if RDP had been used to access remote 
systems, from the Win2008 R2 system being examined.  I would also check for 
the existence of a corresponding Jump List for this activity.

Note: I would then confirm this access, as anti-forensics techniques can 
include not just removing artifacts to hide activity, but creating them, as
well.  Creating values beneath the appopriate Registry keys is relatively
simple to do, so verifying what is found through the correlation of other
artifacts is important for establishing what actions were actually taken.

- I would check to see if unallocated space contains any indications of the use
of wiping applications.  Specifically, I would export unallocated space to a 
separate file using blkls from the TSK tools, and then check to see if there are
indications of repeating patterns of characters.  One simple way to do this is
to run 'strings' (from MS/Sysinternals, include the '-o' switch to get offsets)
and then use a command such as 'type strings_output.txt | more' to quickly begin
examining the output of the command.  No strings found, repeating patterns, or
completely random strings of characters might indicate the use of anti-forensics
tools, specifically for wiping unallocated space.  

I might also consider writing a Perl script to check for unique strings; that
is, run through the output of strings.exe, and keep a count of all lines 
retrieved in a Perl hash, using the line as the key, and keeping a count of
each line.  Then, I'd have the code do a reverse sort, and start by 
displaying the top ten (or twenty) most commonly-found lines, and their 
relative counts.  This might take some time to run, but it would automate
what I'm looking for, as well as reduce mistakes that I might make, due to
fatigue, while looking through each line manually.

- I would review David Cowen's NTFS Tri-Force article, and employ the tool
to look for indications of deleted files that may indicate anti-forensics 

3. What would your next steps be

I would create an overall timeline of system and user activity, incorporating
information from VSCs (as well as other historical information, such as hive files
in the RegBack folder).  I would incorporate artifacts specific to user accounts
identified from previous analysis, and then identify 'pivot points' or 'items of
interest' within the timeline in order to identify gaps, areas where there are
'obvious' gaps in activity (consider the scene from "Battle: Los Angeles", when
the Marines identify the location of the command and control center by the 
absence of lights and electrical power...).  This is relatively easy to do using
the techniques and tools outlined in Ch. 3 & 7 of WFAT 3/e, and using an updated
version of parse.pl/.exe that removes redundant entries from the various time

Something else I would look for specifically in a timeline (or micro-timeline) 
is the LastWrite times for Registry keys within the user's hive files.  
Having a number of keys that maintain information about user activity (ie, 
UserAssist, RecentDocs, ComDlg32 subkeys, shellbags artifacts, etc.) that
all have LastWrite times relatively close together, but the keys themselves
are empty, might indicate the use of anti-forensics tools/techniques.

This is quite an answer, longer than most of my posts! It goes in depth into not only finding indications of logins, and anti forensic techniques but further goes into tracking movement and access across the network.

The other top answer came from 'Steve M'
1. Where by default would you find evidence of an interactive login, please list all locations.

Depending on the system audit policy, you can find evidence of interactive logon in several places.  Ideally, these logs would be centralliy collected by a trusted SIEM system and be considered "tamper-proof".

Event Logs:

- If the "Audit logon events" policy is configured (success) on the Windows 2008 R2 system, an event in the Security event log with ID 4624 showing a logon type code of 2 (Interactive), 7 (Unlock), 10 (RemoteInteractive), or 11 (CachedInteractive).

- If the "Audit Account Logon events" policy is configured (success) throughout the domain and the logon is initiated by a domain account, an event in one of the domain controller's Security event log with ID 4776 may be used to corroborate the local event log.  Similar events may appear on the server in which the suspect's home drive is located, assuming a home drive is configured for this user and the target system is also Windows Server 2008 R2.  Note that this event alone does not independently confirm an interactive logon but should contain information tying the suspect user to the system in question.

- If the suspect has local printers configured and attempts a logon via RDP, an event in the server's System log with ID 1102 and source "Microsoft-Windows-TerminalServices-Printers" may be logged.  This event may include the source workstation which has the local printers configured, and can potentially be used to verify the interactive logon by the suspect.

- If the Windows 2008 R2 server has "Process Tracking" auditing enabled (success), events with ID 4688 showing new process launches of typical shell components like "%SYSTEMROOT%\explorer.exe", "%SYSTEMROOT%\system32\dwm.exe", and "%SYSTEMROOT%\system32\userinit.exe"

File System/Registry:

- The file modification time for "%USERPROFILE%\ntuser.dat" for the suspect in question can be inspected to determine the time of last interactive logon.

- The shellbags can be exported from the registry and have their timestamps manually reviewed for evidence of interactive user activity.


- The Windows SAM stores the last logon timestamp for local accounts.  If the suspect used a local account to logon, a tool like llogon.exe can be used to extract the last logon timestamp.  Again, this may not independently confirm that an interactive logon was issued (scheduled tasks, services, etc. could update this value), but it can be used as corroborating evidence.

2. What would you do to determine if anti-forensic methods were taken?

Anti-forensics techniques can be broad, ranging from modification of system settings to overall destruction of the system.  Here are how some of the most common anti-forensics techniques can be detected:

- Review the security event log for events that may indicate audit policy changes (security event ID 4719) or clearing of the event log (security event ID 1102).

- Review the system event log for events that show starting/stopping of services (system event ID 7036), specifically for system utilities like the "Windows Event Log" or anti-virus agents.  If the "Windows Event Log" system was stopped, the event logs may not be trusted.

- Review the security event log for modifications to the system time (event ID 4616), which may indicate attempts by the suspect to throw off timelines.

- Review anti-malware events for the system in question to determine if any off the shelf anti-forensics tools were identified, or if the services were tampered with.

- Typically, a user must elevate to LocalSystem to stop these critical services.  Common indications that this may have happened include the presence of the "Psexec" service either on the system or in event logs (system event ID 7036), present or deleted files under "%SYSTEMROOT%\Tasks" (created via the "at.exe" command), or other service executables/dll's in the path showing signs of compromise based on modification date/comparison with a known trusted system.

- Review the admin's recylce bin ("C:\RECYCLER\") to determine if deleted files are present, or to see if previously stored file names can be forensically recovered.

- Create a timeline of all filesystem modifications (inculding deletions), and either manually review all recent changes or compare the filesystem against a known trusted backup.  This would ideally reveal any anti-forensic tools (winzapper, clearlogs) that were planted on the system.

3. What would your next steps be?

After reviewing the system itself (ideally an image) and trusted external log facility (SIEM), I would expect to have a decent understanding if the admin had interactively logged into the system.  In addition to the steps outlined previously, I would perform the following as well:

- If enterprise change control processes must be followed before access is granted to the system, this system should be reviewed to see if the admin had potentially scheduled his malicious activities under a different context.

- If the system in question is a virtual machine, it is possible the administrator took a snapshot of the system, accessed it, and then reverted it to avoid leaving an audit trail.  The audit logs for the virtual machine control applications should be consulted to see what actions were taken on the system recently.

- If there is still suspicion for the admin in question, I would then seek access to the source system (probably the admin's workstation) and other enterprise security logs like SIEM and DLP for additional evidence of malfeasance.

What I really liked about Steve's answer is that it stayed within the question and brought up some interesting artifacts that were not mentioned by anyone else. While Harlan wrote a longer response I thought Steve wrote something that was concise and fascinating.

What none of the answers pointed out is one of my favorite event log artifacts for Win server 2008. When Microsoft split up the event logs into a multitude of topics they made one just for the task scheduler. This may not seem interesting to you but tasks have been vastly overhauled since Windows 7 and now contain many triggers for a logon. I've had a couple cases now where I can recover logins farther back from the task manager event logs than any other event log on the system and I've never  seen them targeted.

So with all that said, the winner is... a tie.

I like both answers, well done gentlemen. I'll be sending both of you a 4TB external drive, Steve please email me your address to dcowen@g-cpartners.com.

Post a Comment