NTFS Object IDs in EnCase – Part 3

In a previous post, I showed you how to make a condition to find all files in an NTFS volume that have Object IDs associated with them in NTFS. In this post, I will be showing you how to create a condition to search through the values of the Object IDs to filter on specific strings.

The condition I build below is designed to search for a provided value, and then remove that from the filtered list. The goal is to allow the examiner to use this to identify files that were created on computers with difference MAC addresses.

In the image below, I found 229 files that have Object IDs but don’t have my VM’s MAC. The previous condition found 442 total files on this disk with Object IDs. Many Windows files were in the list, but the EnCase.exe file jumped out. MAC address of the engineer that executed the build process?

encase-objid-c2-result

Using EnCase Conditions to Search Inside Object IDs

Similar to the last condition, this requires the mini-filter feature inside the condition to dig inside the attributes for each file. Here is how to build that condition:

  1. Find the conditions pane in the bottom right corner and click on the ‘user’ folder. Use the ‘new’ option in the toolbar or mouse right click to open the condition dialog. I created a folder to organize a bit. EnCase throws an error if you try to create a new condition in the ‘default’ folder.
  2. Click on the ‘filters’ tab and then double click on the ‘AttributeValueRoot’ item in the list.
    encase-objid-c1-filters
  3. Five things to do in this window. We need to give this a unique name since it will show up in the property list later. I chose to use the FullPath property to reduce false positives over using a name only check. The path I used is based on what EnCase displays when viewing in the attributes tab of the details pane.
    1. Name mini-filter ‘zFindObjectId’
    2. Use ‘new’, choose ‘fullpath’, choose ‘find’, type ‘object identifiers\own id’ in the value
    3. Use ‘new’, choose ‘value’, choose ‘Find’, type ‘NOT value’, and check ‘prompt for value’
    4. Right click on ‘Value find [NOT value]’ and choose the ‘Not option’
    5. Right click on the ‘Main’ item at the top of the tree and use ‘change logic’ to flip the ‘or’ to ‘and’
    6. Click ‘ok’
      encase-objid-c2-filter-terms
  4. Back on the main condition window, click on the conditions tab.
    1. Use the ‘new’ option
    2. Scroll to the bottom of the list and click on ‘zHasObjId’
    3. Click on ‘has a value’
    4. Click ‘ok’
      encase-objid-c2-term
  5. Name your condition and click ‘ok’
    encase-objid-c2-final

 

Let me know if you find other uses to search for using this condition. I would love to read about it.

James Habben
@JamesHabben

NTFS Object IDs in X-Ways

Another post in the series of using commercial tools to access Object IDs, only this time switching over to X-Ways Forensic (XWF). I don’t think that it is any secret that EnCase has been my primary forensic tool suite for a really long time, but I like to have options and XWF is one I have available. This will be a pretty short post and mini-series, however, because it doesn’t seem that XWF does much with Object IDs other than simply display them.

Using XWF to View Object IDs

Open up a preview on a disk, and browse to a file or folder that you know has an Object ID assigned to it. Click on the ‘Details’ tab in the bottom pane and scroll all the way down. If you don’t have the viewers properly setup, then you have to configure those first.

xwf-objid

Comparing XWF to EnCase

This section is the one that will bring the hater comments, but I will put it in anyways. Let me state here that I think XWF has a lot of great and unique features, many that EnCase doesn’t, and I like having it as an option for those times.

Let’s borrow the image from my previous EnCase post:

encase-attr-objid-long

The Object ID shows the same value. The parsed values match up as well (0x2bb==699). Always great to see validation across tools, not that this is a really hard problem.

The point that caught my attention was the missing ‘Birth’ IDs. EnCase shows three total values here, and I haven’t been able to locate either ‘Birth Volume ID’ or ‘Birth Object ID’ in XWF. Let me know if you know where these are located!

XWF Filtering on Object ID

One of the things I really like about XWF is the ability to add columns for many of the fields that we might want to quickly see and even filter on. When the column is available, it makes for extremely quick filtering by clicking on the funnel in the column header (much faster than creating a condition in EnCase). Unfortunately for us on this topic, there is no column available for the Object IDs.

xwf-objid-columns

XWF will show you the associated Object ID, but it doesn’t seem to give you the option to narrow down your file sets based on those having or not having Object IDs assigned. If you are following Dave’s quest, you know that these IDs get created as part of the link tracking system and there are numerous user actions that are associated with their existence. If you know the file you are looking for, then XWF will show you. If you are looking for any files that have the IDs, then you will have to use EnCase or one of the many open source options.

 

James Habben
@JamesHabben

NTFS Object IDs in EnCase – Part 2

I posted previously about how to view the Object ID values, stored by NTFS, using EnCase as a forensic tool. In this post, I will show you a method to identify the files in your case that have an Object ID assigned to them. You can follow this using EnCase v7 or v8.

Using EnCase Conditions to Find Object IDs

This method requires a user-built custom condition because EnCase doesn’t have any in the default set to search for these values. Because the Object IDs are shown in the attributes tab of EnCase, it makes for a little more advanced condition than the typical. Here is how to build that condition:

  1. Find the conditions pane in the bottom right corner and click on the ‘user’ folder. Use the ‘new’ option in the toolbar or mouse right click to open the condition dialog. I created a folder to organize a bit. EnCase throws an error if you try to create a new condition in the ‘default’ folder.
  2. Click on the ‘filters’ tab and then double click on the ‘AttributeValueRoot’ item in the list.
    encase-objid-c1-filters
  3. Four things to do in this window. We need to give this a unique name since it will show up in the property list later. I chose to use the FullPath property to reduce false positives over using a name only check. The path I used is based on what EnCase displays when viewing in the attributes tab of the details pane.
    1. Name mini-filter ‘zHasObjId’
    2. Use ‘new’, choose ‘fullpath’, choose ‘find’, type ‘object identifiers\own id’ in the value
    3. Use ‘new’, choose ‘value’, choose ‘has a value’
    4. Right click on the ‘Main’ item at the top of the tree and use ‘change logic’ to flip the ‘or’ to ‘and’
    5. Click ‘ok’ to save it
      encase-objid-c1-filters-terms
  4. Back on the main condition window, click on the conditions tab.
    1. Use the ‘new’ option
    2. Scroll to the bottom of the list and click on ‘zHasObjId’
    3. Click on ‘has a value’
    4. Click ‘ok’
      encase-objid-c1-term
  5. Name your condition and click ‘ok’
    encase-objid-c1-final

It is ready to use now. This condition is doing an extra lookup for every file in your case and it causes the operation to take a bit longer. Be patient and it will finish. If you haven’t changed any settings with the view after running a condition, it will come back without the tree pane. I used the ‘ctrl+space’ shortcut to have EnCase blue-check everything in the view. As you can see, I have 442 out of 363,168 files on this disk with Object IDs associated in NTFS.

encase-objid-c1-result-table

You can change from the table-only view with an easy fix. Just use the drop down and select ‘tree-table’.

encase-objid-c1-change-view

Click on the attributes tab in the bottom pane, and you get the same view as before.

encase-objid-c1-result-detail

 

Next post will be another condition that will allow you to search for a partial or full Object ID value across the evidence in your case. Let me know if you have any questions or other thoughts on something to filter on.

 

James Habben
@JamesHabben

NTFS Object IDs in EnCase

Over on the Hacking Exposed Computer Forensics blog, David Cowen has been posting up weekly challenges. I love that he is investing in the DFIR community (literally with $100 prizes).

He posted a challenge on September 9, 2018 for readers to develop a python script to parse the NTFS $ObjId:$O alternate data stream. He apparently didn’t get any takers since on September 15, 2018 he put up a short post stating exactly that.

Commercial Solution

I am all for Open Source and Free Software options in the DFIR community, and I also frequently contribute to that collection through my various GitHub repositories. I have also spent an insane amount of time working with EnCase in my years past, so I wanted to show the way to view the data related to Dave’s challenge in a tool that some of you might have available.

Don’t blink!

Here are the steps to see the Object IDs that are assigned to files in EnCase v7+:

  1. Load your local preview or evidence file into the evidence tab
  2. Click on the evidence name to have EnCase start parsing the file system
  3. Find a file you know to have an Object ID
  4. Click the Attributes tab in the view pane

Here is what that looks like:

encase-attr-objid

You can also see that EnCase parses the GUID and displays the various components. Just expand the field, or hover the mouse over like this:

encase-attr-objid-long

This was just a short post for now. Next one, I will show how to build a condition to narrow down the view to only those files having Object IDs assigned.

 

James Habben
@JamesHabben

Show and Search for NTFS Owner in EnCase

Windows can be such a weird and wonderful thing, both at the same time. In a digital forensics sense, the artifacts left behind from user activity often give me delight. The same artifacts can often leave me scratching my head about why it exists in the first place. One of those features is the owner property in the NTFS file permissions.

User Activity

When a user creates a file, Windows typically drops that user account as the named owner of that file in the NTFS permissions. Sometimes, it assigns a local user group (say administrators) instead of a specific user, though I do not know the details of conditions surrounding that difference. Not the point of this post anyways.

To steps to see the owner of a file will vary a bit depending on the version of Windows you are using. The artifact itself is not affected by the version.

In Windows 8, right click on the file and choose properties. At the top, switch from the general tab to the security tab. Then, click the advanced button at the bottom. A new window will show, and the owner is listed near the top.

encase-owner-win-prop

Showing in EnCase

To see the very same data in EnCase is fairly straight forward. Choose a file in the table pane. Then in the view (lower) pane, you will see a tab called permissions. The view will switch and list one of the records as the owner.

encase-owner-view

Forensic Usefulness

As you might have noticed, the file system in the above image looks a lot like a CMS package on a web server. If you did, great eye! Web servers use a specific account to access and store content for the anonymous users that make requests. This user account is assigned permissions on the file system to prevent that anonymous user from going where they aren’t allowed.

Some web applications allow those anonymous users to upload files to be used by the web application or even submitted to the company for some purpose. Because the web server user account is used for these interactions, you will find that user account as the owner for any files that were uploaded through the web application.

In the event of a web server compromise, this web server user account is often the early stages of attackers interacting with the computer. Attackers want to get their files into that file system to allow more control. These are called web shells and offer nearly identical functionality to the typical remote access tool category, only through a website interface.

What if we could get EnCase to display all files that are owned by this web server user account? I am glad you asked!

Filtering in EnCase

EnCase offers conditions and filters to limit the files shown on screen. Simply put, conditions are easier to create (point and click) while filters are hard (type EnScript code). I will show you the steps to create a condition that will show you only the files with the prompted value in the owner field. This can be done in EnCase v5 through v8 and the windows will look nearly identical.

First step, find the conditions tab and create a new one. I name mine “find sid as owner”, but you can call it whatever makes sense to you.

Next, we have to create a mini-filter before the condition can function. Go to the filters tab, then double click on the PermissionRoot option on the right. Name it “prm_sid2owner”.

Add a new term. Choose ID in the properties list, choose find in the operators list, leave the value box empty, and check the ‘prompt for value’ checkbox. Click ok.

Add another new term. Choose property in the properties list, choose matches in the operators list, type ‘owner’ in the value box. Click ok.

Now right click on the ‘main’ at the top of the tree and choose change logic. Click ok. You should see ‘prm_sid2owner’ listed on the left.

encase-owner-filter-list

Now, go back the conditions and add a new term. At the bottom of the property list, you will find the mini-filter we just created.

encase-owner-condition-list

Now you can apply this to your case. You can supply a fill SID value or a partial. You can also give a list of SID values to search for if you were looking for multiple users.

 

Hope this helps! Reach out with any questions or comments.

James Habben
@JamesHabben

Show Your Timezone in X-Ways

I posted earlier about how to enable EnCase to show the timezone for all of the timestamps that it displays. I wanted to follow that up with a post on how that can be accomplished with X-Ways Forensic (XWF) as well.

Showing Your Timezone

This is a pretty simple one. Don’t do anything. The default setting already has the timezone offset displayed with times. Well, you have to do one small thing, and that is to expand the column. XWF has it displayed in a slightly greyed color and all you have to do is make the column wider to show it.

xwf-time-display

Setting Time Zones

I haven’t done extensive testing on this, but it seems that XWF is similar to EnCase in that it takes the timezone setting of the machine your are running on to use inside the case.

To change that setting, use the ‘Options’ menu and select ‘General Options’. In there, you will find a button at the button at the bottom of the window for ‘Display Time zone…’. Click that.

xwf-time-general

Once you have that window open, choose your timezone and click OK and OK.

xwf-time-timezone

Edit: Jarle gave me a couple more ways to change the timezone.

You can set the timezone with a right click at the top of the case tree in the Case Data window on the left of the screen. Choose the ‘Properties…’ option.

xwf-time-click

On that window, you have two options. Set the timezone for the entire case (orange arrow), or unlock the option (pink arrow) to set the timezone for each evidence file or even for each partition of each evidence file.

xwf-time-case

If you check the box, then you do another right click > properties on each item you need to change the setting for and you will get this window.

xwf-time-partition

Thanks for reading!

James Habben
@JamesHabben

Fileless Application Whitelist Bypass and Powershell Obfuscation

Organizations are making the move to better security with application whitelisting. It is shown in the offensive side of the computer security industry. The frameworks, such as Metasploit, PowerSploit, BeEF and Empire, are making it very easy to build and deploy obfuscated payloads in all sorts of ways. It has become so easy that I am frequently seeing attackers using these techniques on systems that do not employ the added security measures.

There are plenty of solutions to mitigate these types of attacks, however I find they are not always configured properly. Take a read through @subTee’s Twitter feed and GitHub for many of the more creative ways he has shared. The attackers have raised the bar with the use of these techniques. If defenders aren’t deploying appropriate defenses, shame on them.

It Works

I wanted to share with you a few things from a recent engagement. The attacker had installed the backdoor almost a year before detection. They got in through a phishing attack, as in most cases. The detection? A kind and friendly letter from a law enforcement agency that had taken control of the command and control (C2) and was observing traffic to identify victims. The beaconing was surprisingly frequent for as careful as the attacker was in some other areas.

Can you confidently say that your endpoints are safe from these types of attacks? You don’t have to deploy prevention or detection tools for every part of the kill-chain, but you would be best served to have at least one. Or not, YOLO.

Persistence

In order for any malware to be effective, it has to run. I know, it is a revolutionary statement. It is a concept that is missed by some and it is a very critical piece. There are a finite number of places that provide malware the ability to get started after a system has been rebooted. Keep in mind that the user login process is a perfectly acceptable trigger mechanism as well, and there are a finite number of places related there too.

Just like the various creative and new application whitelist bypass techniques, there are creative and new persistence mechanisms found periodically. Adam has posted quite a few of them on his blog. The good news is that the majority of attacks don’t get that creative because they don’t have to.

The run mechanism in this system was HKCU\Software\Microsoft\Windows\CurrentVersion\Run

You can see that the attacker has chosen to use cmd to start mshta. The code following that command is javascript that when run creates an ActiveX object that loads more code from a registry path. So many layers!

Obfuscation

The run mechanism loads in code that has been obfuscated by the attacker. It starts off creating another ActiveX object and then using powershell.exe to interpret the code following. The obfuscation is enough to prevent keyword searches from hitting on some of the known API function involved with these attacks, but it is not a difficult one to break. All you need is a base64 decoder. I recommend that you use a local application based since you never know what kind of thing will be showing up and an online javascript based decoder is susceptible to getting attacked, whether intended by the attacker or not.

The path referenced in the run value and pictured below is HKCU\Software\Licenses. I have blurred some code and value names in an abundance of caution for potential unique identifiers.

Decoding

My preferred tool for decoding this is 010 Editor. It is not free, but it is worth its license cost for so many things.

First thing to do is copy the text inside those quote marks. Don’t include the quotes since that will throw off your base64 decoding.

Now you just create a new document in 010 and use edit > paste from > paste from base64.

Magically you have some evil looking PowerShell code.

Take a look over at this powershell code from @mattifestation and you will hopefully notice that it follows the same flow. It looks like someone simplified the code from the blog post by removing the comments and shortening the names of the variables. Otherwise it is identical.

Payload

Line 2 of the PowerShell code loads the registry data from a different value in the same path. Line 14 then copies the binary data from the variable into the memory space for the process that was created, about 15kb of it. Line 15 then kicks it off, and the binary code takes over.

The binary is a shell code that decompresses a DLL image with aPLib and writes it into the same process space. The resulting DLL has not been identified by any public resources, so I can’t share it with you here. It is very similar to Powersniff and Veil, for those interested in the deeper analysis.

Raise Your Bar

Defenders, the bar has been raised by the attackers. Make sure that you are following suit, or better yet, raising it even higher.

James Habben
@JamesHabben