Blank Name Field in Windows.Sys.Users Collection of Velociraptor

For internal SOC teams and DFIR consultants alike, collecting triage data from an infected system is often one of the few things they do when an incident comes in. This is to allow them to determine the correct response according to the evidence or IOCs they discover and validate.

One of the tools that can be used to collect triage data from an infected system is Velociraptor’s offline triage collector. And in this post, we will talk about one of the things you might encounter when you use it in one of your cases. The behavior is something I encountered for the first time when I used the tool in one of the cases I handled. I wasn't able to find any reference to this (or my Google-fu is just not working at the time. lol), hence, I decided to create this post to document everything and eventually help other people who might also stumble upon it.

Velociraptor’s offline triage collector can collect system information and artefacts that can be used for incident response, one of which is a list of user accounts present in the infected system(s). The tool uses the Windows.Sys.Users artefact to collect that information. Below is the full description from Velociraptor’s artefact reference site.

List User accounts. We combine two data sources - the output from the NetUserEnum API (termed local users) and the list of SIDs in the registry (termed remote users).

The tool produces an output that looks like this:

This triage data can be useful to look for any user accounts that might be maliciously added by a threat actor. You can also use this data to correlate activities to user accounts using the recorded UUIDs. However, you might encounter an output that looks something like this:

Notice in Line 10 in the image above that the Name field is blank but other details about the user account are recorded such as its home directory, UID, etc. It was first assumed that it might be due to an issue during the data collection but checking the logs didn’t show any errors. The only interesting was the following line in the triage collection log before starting Windows.Sys.Users.

{"level":"info","msg":"LookupSID: No mapping between account names and security IDs was done.\n","time":"2022-10-31T11:58:08+08:00"}

It was then assumed that it may be caused by the deletion of the account from the Active Directory (AD). Let’s do some tests to see if this was the case.

Below will be our testing environment. The setup is basic and does not contain any other configurations typically found in a properly configured AD server. For this test, we will assume one of the AD accounts was used to log in to a machine that is a member of the domain.

Let's go ahead and add a user to the AD server.

Let’s then use the newly created user account to log in on the user machine.

Let’s log off and log back in using an administrator account so we can start using the Velociraptor offline triage collector to create a triage collection including the list of users. We won’t be covering how we can create an offline collector here in this post. You can visit https://docs.velociraptor.app/docs/offline_triage/ if you want to know how you can create your own offline collector.

For this test, we will be using the collector we created, Collector_velociraptor-v0.6.6-2-windows-amd64.exe. The tool was created using velociraptor-0.6.6-2.exe from https://github.com/Velocidex/velociraptor/releases. You will need a command prompt with elevated privileges to be able to properly use the tool.

Once the tool is done collecting triage data, you should see the tool exiting and show the name of the ZIP file containing the collection.

You should also see the following files in the directory where the tool was located or in an output directory specified during the creation of the collector. In this test, the collected data and a log file were in the Desktop folder.

Once all of the content has been extracted from the ZIP file, opening the Windows.Sys.Users.json will show the list of users the tool was able to collect from the user machine. The image below shows the newly created user testaccount4 which we also used to log in to the user machine before collecting triage data.

Notice in the image above that the Name field is not blank and instead contains the user account’s name. Now let’s try to remove the account from the AD server and see what happens.

After deleting the account testaccount4, let’s go back to the user machine and collect the triage data again.

Once the collection is complete, let’s look at the Windows.Sys.Users.json again and see what happened to the account testaccount4.

Looking at Line 12, we see that the Name field for testaccount4 is blank but still retains some of its information such as its home directory and UUID.

This shows that Velociraptor offline triage collector will be able to gather data about user accounts even if they have already been removed or deleted from the AD/DC server. However, as pointed out, the Name field will be blank. If you encounter this kind of output, it would be safe to verify if the account(s) was indeed removed or deleted from the AD server. This would ensure that the behavior is expected like what was demonstrated in this post and not because of some issues in terms of collecting triage data or other issues that might be present in the system in question.

That's about it for this post. I hope this helps you learn something new and be able to recognize the behavior regarding user triage data collected by the Velociraptor offline collector should you happen to use the same tool in your incidents.

We will explore and test other scenarios with the tool in the next posts. Until next time!