Derek Newton

Information security insights and other ramblings

Finding an Active Directory User's SID using PowerShell

I sometimes need a quick and easy way of determining a user’s Active Directory SID (for example, when performing forensics on the Recycle Bin). Yes, there are ways to find out a SID in ADUC (check out how here) – but I think that utilizing PowerShell is more efficient in this case.

To find a user’s SID, within PowerShell run the following (replacing <domain> and <user> with the appropriate information for your query):

$objUser = New-Object System.Security.Principal.NTAccount(<domain>,<user>)
$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
$strSID.Value

To further enhance efficiency, I’ve actually wrapped this into a parametrized PowerShell script, which you can feel free to download here.  Remember, that in order to get the script to run, you need to set your execution policy to “RemoteSigned” by running the following command:

Set-ExecutionPolicy RemoteSigned

Determining the hostname of a Windows machine

A coworker just asked me this question, and I thought that it would be useful enough to create a quick post.  If you’d like to find out the hostname of a Windows workstation/server and only have a drive image available (and don’t want to boot it), you can find the name within the System registry hive in the key named Hostname located here: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Happy Monday.

The relevance of the Access time in timeline analysis

So – you’re working on creating a timeline for a new disk image and you’re finding that the subject accessed a large number of unrelated files in quick succession.  Perhaps they were up to no good, but before utilizing this evidence to support any findings, let’s step back and think.  When analyzing a timeline, if you find a number of files that were accessed in quick succession, you should immediately consider that some sort of program/process actually accessed the files and that they were probably not intentionally accessed by the subject.  The usual suspects can include backup software, antivirus software, and any other software/malware that “scans” a filesystem.  Of course, once you find the presence of one of these tools, you’re going to need to note it in your findings and if you would like to use accessed times in the timeline to build a case, you’re going to need to prove that the timeline was not affected by this tool.  Some strategies to proving that your access times are relevant include:

  • Analyzing and including the AV scan log (if available on your image) that shows that an “on-demand” scan was not running during the time in question.
  • Analyzing and including a backup log (if available) that shows a backup was not running during the time in question.
  • Performing and documenting searches for other automated tasks/processes that may affect the accessed time in the timeline.

It’s interesting to note that most likely due to the proliferation of “scanning tools” and thus the reduction of relevance that an access time can have in an investigation, Microsoft has decided that by default, in Windows Vista and Windows 7, that the OS does not modify the last accessed time when a file is accessed (this behavior can be modified via GPO and/or the local registry). 

My personal reccomendation is that unless you have a very specific reason to use the access time to support your findings, given the active use of tools that automatically access/scan files, you may find that your results are more clear and less challengable if you do not base investigative findings on this timestamp.

Recycle Bin Forensics in Windows 7 and Vista

Microsoft has significantly changed how files and their corresponding details are represented within the Recycle Bin in Windows 7 and Vista.  In Windows XP, when files were placed into the Recycle Bin they were placed within a hidden directory named \Recycler\%SID% where %SID% is the SID of the user that performed the deletion.  The files were renamed D%drive_letter%%index_number%.%file_extension% where %drive_letter% is the original drive letter of the file, %index_number% is an index number, and %file_extension% is the original file’s extension.  Additionally, a file named INFO2 was placed in the user’s Recycler directory and it container entries, identified by index number, which described the original files size, full path/name, and size.

In Windows 7 and Vista, Microsoft did away with the INFO2 file and completely changed the way files were named and indexed within the Recycle Bin.  Firstly, the new Recycle Bin is located in a hidden directory named \$Recycle.Bin\%SID%, where %SID% is the SID of the user that performed the deletion.  Secondly, when files are moved into the Recycle Bin, the original file is renamed to $R followed by a set of random characters, but maintaining the original file extension.  At the same time a new file beginning with $I followed by the same set of random characters given to the $R file and the same extension, is created; this file contains the the original filename/path, original file size, and the date and time that the file was moved to the Recycle Bin.  You’ll also notice at all of the $I files are exactly 544 bytes long.

The behavior is a bit different when you move a directory to the Recycle Bin.  The directory name itself is renamed to $R followed by a set of random characters, but the files/directories under that directory maintain their original names.  A $I file is created just as when deleting an individual file that contains the original directory name, date/time deleted, and size.  When utilizing the information contained in the $I file for forensic purposes, you can safely report that all files found under the $R directory structure within the Recycle Bin were deleted at the same time (and all at once).  If a file was previously deleted out of the now deleted directory (but not yet removed from the Recycle Bin), it would have it’s own $R and $I files and not be grouped with the files that were deleted as part of the directory deletion action.

Unfortunately, unlike the INFO2 file, the new $I files are not in plain/readable text.  In order to decode a $I files, you could use a forensic tool that has the ability to interpret these files (I belive that Encase and FTK can do this), or you can simply open the file up in a hex editor.  The file is structured as follows:

  • Bytes 0-7: $I File header – always set to 01 followed by seven sets of 00.
  • Bytes 8-15: Original file size – stored in hex, in little-endian.
  • Bytes 16-23: Deleted date/time stamp – represented in number of seconds since Midnight, January 1, 1601.  Use a program such as Decode to assist with figuring out the exact date/time, if you don’t want to do the math :).
  • Bytes 24-543: Original file path/name.

So – break out your hex editors and take a look.  The new Vista/Windows 7 Recycle Bin is just as easy to deal with as the XP one – in fact, when it comes to whole directory deletions, I personally find it easier to work with…sometimes change is a good thing!

Have fun!

PsExec Passes Credentials in Clear Text

PsExec can be a very useful tool during incident response and live forensics work.  For those that don’t know, PsExec is a tool that can be used to execute commands on a remote Windows computer andwas initially developed by Sysinternals, which is now owned by Microsoft (additional details can be found on PsExec’s webpage).

However, it seems that PsExec has one significant shortfall – when utilizing the tool one must provide administrator-level credentials for the remote PC.  These credentials are passed in the clear to the remote workstation (thus exposing the credentials to anyone who happens to be “listening in”).  Thankfully, there is a workaround that can prevent this exposure from occurring, which involves connecting to the $IPC share on the target workstation first (with the admin credentials), prior to executing PsExec. 

To find out more, check out an excellent write up on this issue and the workaround found on SANS Computer Forensics blog titled Protecting Admin Passwords During Remote Response and Forensics.

Orphaned Files in an NTFS File System

A discussion came up recently at work around how a file can become identified as “Orphaned” in an NTFS file system and I thought that it would be a good topic to cover on my blog since understanding how this occurs aids in the forensic analysis of NTFS filesystems.

An orphaned file is a file that has been deleted and the parent directory that the file is linked to (within its MFT entry) has also been deleted and then its MFT entry has been reallocated.  You can also have an orphaned directory index for the same reason as you can have orphaned files (same basic concepts apply).

As an aside: when a directory is deleted on an NTFS file system the operating system marks the directory as unallocated within the MFT and also recursively goes through and marks the file MFT records (and other directories) as unallocated (of course, it also checks the hard link count to make sure that the file isn’t linked from any other location prior to marking it in the MFT as unallocated).

Even though a file appears “orphaned,” you may still be able to recover the file the same way that you would recover a deleted file on an NTFS volume (given the clusters for that file have not been overwritten with other data).  Additionally, you may be able to see directory structure information (names, etc) for an orphaned file/directory that is buried several directories deep; the “orphaning” can happen at any point in a directory structure and you’ll be able to find directory information up until the final MFT entry that is pointing to the now overwritten MFT entry.

The bottom line is: orphaned files are simply just deleted files that may be treated the same way you’d treat any other deleted file during an investigation…you’ll just not be able to determine with any certainty the exact location of the file within the directory structure prior to deletion.

What are alternate data streams?

Alternate data streams (sometimes referred to as ADS) are a way for a user to obscure files that they don’t want appearing within a file browser or a standard DIR listing (albeit they are easily discoverable with the right tools).  ADS is specific to Windows environments, specifically on NTFS filesystems, and has been around since Windows NT (and was most likely created to provide compatibility with HFS – the old Macintosh Hierarchal File System, and not intended for malicious purposes).  From a technical standpoint, alternate data streams are possible because NTFS MFT entries (how NTFS represents and locates files on the filesystem), are each capable of containing multiple $DATA attributes and thus a single MFT entry can actually point to multiple (and possibly unrelated) streams/files.

An alternate data stream is created by the use of a semi-colon separator between the existing filename and the name you’d like to use for your alternate stream.  For example, if I wanted to create/edit a text file contained within an attached to calc.exe (and given I had the rights to modify the MFT entry associated with calc.exe), I would use the following command:

C:\Windows\System32>notepad calc.exe:hiddentext.txt

And you then would be able to edit/save to your newly created stream – as you can see, the alternate stream does not have to be of the same filetype as the discoverable file – so the possible combinations are endless.  One can even place executable files within an alternate data stream using the type command, for example:

C:\Windows\System32>type evilfile.exe > calc.exe:evilfile.exe

Running an executable located within an alternate data stream requires the use of the “start” command (notice that I need to give start a resolvable path, even when I’m in the same directory as a file):

C:\Windows\System32>start .\calc.exe:evilfile.exe

Locating an alternate data strea is straight forward and a number of tools are available that will list them, including the DIR command in Windows Vista and Windows 7 (however, the DIR command still does not list alternate data streams by default).  A sampling of the available tools include:

Additionally, as mentioned above, if you’re running a Windows Vista or Windows 7 workstation, you can run DIR with a /R flag to show the alternate data streams within your current directory.

Utilizing alternate data streams is a very basic method for evading simple forensics techniques and a quick recursive scan looking for alternative data streams can sometimes yield interesting results when dealing with a less sophisticated subject (additionally, malware sometimes uses this technique to obscure related files).  In order to ensure that you don’t miss the low-hanging fruit during your investigation, or the lurking malware, consider adding an alternate data stream discovery step to your standard forensic analysis procedure.