@night 1803 access accessdata active directory admissibility ads aduc aim aix ajax alex levinson alissa torres amcache analysis anjp anssi answer key antiforensics apfs appcompat appcompatflags applocker april fools argparse arman gungor arsenal artifact extractor attachments attacker tools austin automating automation awards aws azure azuread back to basics backstage bam base16 best finds beta bias bitcoin bitlocker blackbag blackberry enterprise server blackhat blacklight blade blanche lagny book book review brute force bsides bulk extractor c2 carved carving case ccdc cd burning ceic cfp challenge champlain chat logs Christmas Christmas eve chrome cit client info cloud forensics command line computer forensics computername conference schedule consulting contest cool tools. tips copy and paste coreanalytics cortana court approved credentials cryptocurrency ctf cti summit cut and paste cyberbox Daily Blog dbir deep freeze defcon defender ata deviceclasses dfa dfir dfir automation dfir exposed dfir in 120 seconds dfir indepth dfir review dfir summit dfir wizard dfrws dfvfs dingo stole my baby directories directory dirty file system disablelastaccess discount download dropbox dvd burning e01 elastic search elcomsoft elevated email recovery email searching emdmgmt Encyclopedia Forensica enfuse eric huber es eshandler esxi evalexperience event log event logs evidence execution exfat ext3 ext4 extended mapi external drives f-response factory access mode false positive fat fde firefox for408 for498 for500 for526 for668 forenisc toolkit forensic 4cast forensic lunch forensic soundness forensic tips fraud free fsutil ftk ftk 2 full disk encryption future gcfe gcp github go bag golden ticket google gsuite guardduty gui hackthebox hal pomeranz hashlib hfs honeypot honeypots how does it work how i use it how to howto IE10 imaging incident response indepth information theft infosec pro guide intern internetusername Interview ios ip theft iphone ir itunes encrypted backups jailbreak jeddah jessica hyde joe sylve journals json jump lists kali kape kevin stokes kibana knowledgec korman labs lance mueller last access last logon lateral movement leanpub libtsk libvshadow linux linux forensics linux-3g live systems lnk files log analysis log2timeline login logs london love notes lznt1 mac mac_apt macmini magnet magnet user summit magnet virtual summit mari degrazia mathias fuchs md viewer memorial day memory forensics metaspike mft mftecmd mhn microsoft milestones mimikatz missing features mlocate mobile devices mojave mount mtp multiboot usb mus mus 2019 mus2019 nccdc netanalysis netbios netflow new book new years eve new years resolutions nominations nosql notifications ntfs ntfsdisablelastaccessupdate nuc nw3c objectid offensive forensics office office 2016 office 365 oleg skilkin osx outlook outlook web access owa packetsled paladin pancake viewer path specification pdf perl persistence pfic plists posix powerforensics powerpoint powershell prefetch psexec py2exe pyewf pyinstaller python pytsk rallysecurity raw images rdp re-c re-creation testing reader project recipes recon recursive hashing recycle bin redteam regipy registry registry explorer registry recon regripper remote research reverse engineering rhel rootless runas sample images san diego SANS sans dfir summit sarah edwards saturday Saturday reading sbe sccm scrap files search server 2008 server 2008 r2 server 2012 server 2019 setmace setupapi sha1 shadowkit shadows shell items shellbags shimcache silv3rhorn skull canyon skype slow down smb solution solution saturday sop speed sponsors sqlite srum ssd stage 1 stories storport sunday funday swgde syscache system t2 takeout telemetry temporary files test kitchen thanksgiving threat intel timeline times timestamps timestomp timezone tool tool testing training transaction logs triage triforce truecrypt tsk tun naung tutorial typed paths typedpaths uac unc understanding unicorn unified logs unread updates usb usb detective usbstor user assist userassist usnjrnl validation vhd video video blog videopost vlive vmug vmware volatility vote vss web2.0 webcast webinar webmail weekend reading what are you missing what did they take what don't we know What I wish I knew whitfield windows windows 10 windows 2008 windows 7 windows forensics windows server winfe winfe lite winscp wmi write head xboot xfs xways yarp yogesh zimmerman zone.identifier

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

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


Author Name

Contact Form


Email *

Message *

Powered by Blogger.