Computer Forensics

Hello All. I had the honor of speaking at the 2024 AtlSecCon Conference in Halifax this past week. What an amazing event. Shout out to the organizers, attendees and sponsors. I had a blast. I delivered a talk on Live Incident Response as part of DFIR. I promised attendees I would post my slides and cheat sheet. Please see below:

Please feel free to reach out if you have any questions.

Read more

Hello All. I am working on a project where I have to enumerate a Windows fileserver and provide details on NTFS permissions and ownership of directories and files. I wanted to provide some thoughts on some of the tools and scripts out there to do this and how well they work.

I am specifically referring here to file/directory permissions (referred to as “Security” in the example below) and not share permissions, these are two totally different things. I will cover share permissions in a follow-up post.

So essentially, unless you want to spend a bunch of money on a commercial tool from someone like Quest Software’s Security Explorer or Varonis’ DataPrivilege Platform. Some things you want to consider when doing this: 1. The time it takes to run this. If you have a huge filesystem, this could take a while. 2. Memory is the other thing.

PowerShell

Enumerating NTFS permissions can be performed using the PowerShell Get-Acl cmdlet to return permissions on objects like files, folders, and registry keys. The example below gets the permissions set on the C:\Program Files folder and all the available properties.

(Get-Acl -Path “C:\Program Files”).Access

Get-Acl is unable to recursively return all the permissions of folders in the directory tree. So, if you want to enumerate all the permissions on all folders in a directory tree, you need to use the Get-ChildItem cmdlet with the -Recurse parameter to list all the folders in the tree and then pass the results to Get-Acl using a ForEach loop.

Here is a quick script – you will still need to update the PS1 to include the path you want to enumerate:

$FolderPath = Get-ChildItem -Directory -Path “C:\Program Files” -Recurse -Force
$Output = @()
ForEach ($Folder in $FolderPath) {
$Acl = Get-Acl -Path $Folder.FullName
ForEach ($Access in $Acl.Access) {
$Properties = [ordered]@{‘Folder Name’=$Folder.FullName;’Group/User’=$Access.IdentityReference;’Permissions’=$Access.FileSystemRights;’Inherited’=$Access.IsInherited}
$Output += New-Object -TypeName PSObject -Property $Properties
}
}
$Output | Out-GridView

This will output a nice looking, grid view of the NTFS permissions:

If you would rather get a spiffy CSV file, the simply replace the last line of the script with: $Output | Export-Csv -Path .\enum.csv

This will create a file called enum.csv:

Ok, one thing to note, you may notice some of the permissions comes back as numerical and not the typical “Full Control” for example.

As per Cjwdev (https://blog.cjwdev.co.uk/2011/06/28/permissions-not-included-in-net-accessrule-filesystemrights-enum) who explains it better than I could. There is a FileSystemRights Enum defined that seems to contain every possible permission that a file/directory can have and calling AccessRule.FileSystemRights returns a combination of these values. However, you may come across some permissions where the value in this property does not match any of the values in the FileSystemRights Enum.

The end result of this is that for some files/directories you simply cannot determine which permissions are assigned to them. If you do AccessRule.FileSystemRights.ToString then for these values all you see is a number rather than a description (e.g Modify, Delete, FullControl etc). Common numbers you may see are: -1610612736, –536805376, and 268435456

To figure out what these permissions actually are, you need to look at which bits are set when you treat that number as 32 separate bits rather than as an Integer (as Integers are 32 bits long), and compare them to this diagram: http://msdn.microsoft.com/en-us/library/aa374896(v=vs.85).aspx

So for example, -1610612736 has the first bit and the third bit set, which means it is GENERIC_READ combined with GENERIC_EXECUTE. So now you can convert these generic permissions into the specific file system permissions that they correspond to.

You can see which permissions each generic permission maps to here: http://msdn.microsoft.com/en-us/library/aa364399.aspx. Just be aware that STANDARD_RIGHTS_READ, STANDARD_RIGHTS_EXECUTE and STANDARD_RIGHTS_WRITE are all the same thing and actually all equal the FileSystemRights.ReadPermissions value.

Free Tools

Now, if PowerShell isn’t your thing, and you just want to run a tool, well there are a few free ones out there. Here are the options I recommend. Don’t be fooled but some of the stuff you find on the Internet. Make sure what you download is reputable, as you will be running it on potentially a very important and maybe sensitive server file system. I also tend to stay away from those “Free Versions” of software or trials. They also may require you install a whole bunch of crap to get them to run (i.e. SQL Server, .NET, etc.). If I want to go this route, well see above about Quest and Varonis.

Sysinternals AccessEnum – OK, let’s face it Mark Russinovich and his crew are gods when it comes to Windows internals. AccessEnum gives you a full view of your file system and Registry security settings in seconds, making it the ideal tool for helping you find security holes and lock down permissions where necessary.

Run AccessEnum against a top-level folder in a folder tree, the tool scans the files and folders beneath and reports back where permissions are different from the parent. You get something like this as an output:

There is a save button at the bottom, so you can move all this data to CSV and Excel. The other thing to be aware of is what this tool will provide from an information perspective:

Sysinternals AccessChk – As a part of ensuring that they’ve created a secure environment Windows administrators often need to know what kind of accesses specific users or groups have to resources including files, directories, Registry keys, global objects and Windows services. AccessChk quickly answers these questions with an intuitive interface and output.

To see all files under c:\, simply use the following command:

accesschk c:\

This will produce the following output:

If you add the -s flag, this will allow the tool to pull permissions recursively (i.e. accesschk -s c:\)

Now the good thing is given this is a command line tool, you can do a quick redirect stdout to a .txt file and you have an external file to play with. Only issue is you may need to do a bit of Excel magic as the output is not in a delineated format like CSV.

Finally, a runner up would go to CJWDEV’s NTFS Permissions Reporter. CJWDEV is who I referred to earlier in this post. This tool is one of those “free” versions of software. It displays group users with either direct or nested access for an entire file system directory. The report can be generated in either a tree or table format with color-coded access levels.  Here it is in action:

Read more

The report is based on a study conducted by staff at FERC, NERC and NERC regional entities. The study is based on information provided by experts at eight U.S. electric utilities of various sizes and functions, and its goal was to help the industry improve incident response and incident recovery plans, which authors of the study say help ensure the reliability of the bulk electric system in the event of a cybersecurity incident.

The study found that there is no best incident response and recovery (IRR) plan model. The IRR plans of the targeted utilities share many similarities — they are based on the same NIST framework (SP 800-61) — but there are also differences, and some organizations have developed separate plans for incidents impacting their operational and business networks.

Read more