Okay, as a DFIR analyst, you’ve never run into a situation where the Windows Event logs rolled over, had insufficient auditing settings, and were not being forwarded to a log aggregator or SIEM, right? Never ever.. YEAH RIGHT! I’m sure we’ve all had cases where we collect forensics Event logs, such as the ‘Security’ Windows Event log, only to find out its been rolling over every hour, few hours, day, etc. Especially on busy servers, such as Domain Controllers (DC), this can unfortunately be very common. If someone doesn’t adjust the retention rate of various logs, we may only find out that they’re insufficient after an incident occurs. What about the scenario where a Threat Actor (TA) clears the Event logs and these weren’t being forwarded any where? Let’s say that memory, backups, volume shadow copies, etc. weren’t an option (work with me here). What do you use now? Enter, System Usage Monitor (SUM) User Access Logging (UAL), the logs that are slept on in 2024.
The Rundown:
Used by Windows servers to aggregate client usage data by role and products on a server.
Used to assist Administrators quantify requests from client computers for roles and services, as described by Microsoft
Installed by default on
Windows Server 2012, 2012 R2, 2016, 2019, 2022
Collects data going back 3 years
Records the following information
Username
First and last seen
Role
Source IP address
Login count
From a forensics perspective, we can use these to identify access/logon events going back 3 years
Resides within C:\Windows\System32\LogFiles\Sum
Format of the UAL database is ‘Extensible Storage Engine’ or ESE
Collection of this database(s) file will likely need to be repaired using ‘esentutl’, as the database file was likely in use during the time of collection
Eric Zimmerman’s ‘SUMeCMD’ tool can be used to parse this database
There are multiple database files that will need to be collected, repaired and parsed
Understanding the SUM UAL database can be daunting at first, but it’s important to note that, like other Windows artifacts, this is a database file that is not specifically designed for “forensics”, but rather, provides basic functionality and features to Windows admins. As mentioned above, this database file is intended to store information regarding “server role requests” such as File Server, DHCP, Fax, Web Server, FTP, Remote Access, Windows Server Update Services, and more. These roles will vary based on the configuration and setup of the server in question. However, these are specifically tied to the roles you’d find when opening your “Server Manager” and clicking “add roles and features”. It goes without saying that in order to find this artifact, you’ll need to analyze not only a server, but an domain joined server, such as a DC, as this will have the database of roles associated with Active Directory.
As mentioned, the database files can be found within ‘C:\Windows\System32\LogFiles\Sum’. Upon navigating to this folder, you’ll see multiple database files in a ‘mdb’ or Microsoft Database file format. Please note that the format of these database correspond to the following:
current.mdb (current year and the file actively in use) Please note that this is updated every 24 hours
<GUID>.mdb (Current year)
<GUID>.mdb (Previous year)
<GUID>.mdb (three years)
Systemidentity.mdb (contains configuration information for server roles, GUIDs and various mapping information)
I won’t go into the specifics and granular detail of these roles and whatnot for the sake of time, but I’ll go ahead and provide a link that explain what the User Access Logging does. https://learn.microsoft.com/en-us/windows-server/administration/user-access-logging/get-started-with-user-access-logging
So now that we have a decent understanding of what the UAL database is in a nutshell, let’s discuss how we can use this from a forensics/investigative perspective. Let’s say we have a TA that is mounting various file shares via SMB for lateral movement or using other tools that use the SMB protocol, such as PSexec (SysInternals) to laterally move and execute commands. Obviously we could look at other artifacts that may leave remnants of this, such as Security Event logs (Event ID: 4624 Type 3 logons) or ‘psexesvc.exe’ being installed as a service; but what if the Security Event logs rolled over or were cleared and we don’t exactly know where the TA logged in from? We don’t know if they came from our VPN subnet, another workstation, another server, or what. Obviously this is very important in DFIR in order to work our way backwards to identify our “patient-zero” or the beachhead host. So, identifying a source IP address where someone is connecting from can make or break an investigation. As mentioned above, not only does the SUM UAL database go back three years, it logs usernames, first time of access, last access, number of accesses from that IP address and the source IP address. Some juicy information!
So, how can we use this from an analyst approach? Well.. lets talk about frequency analysis or “baselining” the system. If we’re seeing a username logon to the server via UAL for the first time around our time of the incident and according to the number of accesses, this isn’t a “normal” thing to see from that username/IP address combination, we can consider that suspicious in terms of frequency.
Lets first start by collecting these database files as part of our “collection” or analysis of the system. In my instance, I’m using Eric Zimmerman's KAPE to collect these files. However, you can use whatever collection tool you use in your processes.
Shown below, we can see the aforementioned database files. Lets run Eric Zimmerman's ‘SumECMD’ tool against these files by running the following command
SUMeCMD.exe -d ‘path_to_UAL_files_here’ —CSV output_directory_here
Wait what?… we got an error? Well.. Yes! As I mentioned earlier, when these database files are collected, they were likely in use by the operating system and are considered to be “corrupt” because they were interacted with during this time. No worries though, there’s an easy fix for this. Let’s use the built in Windows tool ‘esentutl.exe’ to repair these files. We can do this by running the following command for each file
Esentutl.exe /p ‘database_file_here’ 
Please note that if you’re getting permission errors, you’ll likely need to assign permissions to the directory you’re working in or the entire folder, which should allow the child folders/files to inherit those permissions. However, in most cases, you won’t need to do this.
After repairing each database file, let’s rerun ‘SUMeCMD.exe’.
Boom! Now we have multiple CSV files in the specified output directory. As mentioned, you’ll have a CSV file for each year of observed role access and the corresponding ‘GUID’ that define the “role that was accessed. This is correlated with the 'SumECmd' tool and translated to 'Role Name'.
Let’s say that our analysis of this server found that a suspicious executable was interacted with, commands were executed, psexec was used, or some other anomalous activity occurred, but we don’t know what user conducted this activity or how they did it; we can check the UAL database to search for users that logged on to the server during those timeframes. See where I’m going with this?
How about if we already know the IP address or username of our compromised asset? Well.. parse the UAL database and filter on that username or IP address. BAM, we have a few timestamps of when that activity was observed.
Even if we have a username but not a source IP address, we can just filter on the known username and identify a source IP address here! At that point, we can work to collect an image of that system for additional analysis! Now obviously on a production server, the content in this file will have numerous entries. Shown below is just an example of what these will look like.
Obviously, as with other artifacts, this shouldn’t be considered a silver bullet, as there are “roles” that may not get recorded here or other reasons, but I can honestly say that this artifact has been extremely reliable when all other sources fail, such as Security Event logs. With this said, I collect this artifact for every incident or review of a server and parse it each time, as its saved my analysis multiple times and continues to be an extremely useful and relevant artifact! Especially when correlated with other artifacts collected and placed within your timeline, the timestamps and activity identified with SUM UAL can really fill in blank spots of activity and help place those missing pieces of the puzzle together.
I also feel like this artifact is “slept on”, because not enough analysts know about it or what its purpose is, so hopefully this brief blog post can help shed some additional light on why you absolutely need to collect this artifact as part of your triage or analysis.
Shoutout to the team at CrowdStrike for also writing a fantastic article on this artifact. This article really interested me to the artifact a few years back and its a great read: https://www.crowdstrike.com/blog/user-access-logging-ual-overview/
Additionally, as always, 13Cubed also doing a great video on this: https://youtu.be/rVHKXUXhhWA?si=KSE2sKtV5Hd7gxm1