Introducing the Restart Manager Artifacts Tool

We have recently observed ransomware that relies on Windows' Restart Manager API to unlock files before encryption. Going into the rabbit hole of exploring this functionality, we discovered that using this API leaves traces on the system that can be valuable for digital forensics. Since these artifacts are highly volatile and unsuitable for offline collection, we created Restart Manager Artifacts, an open-source tool to help with their live extraction.

What is Restart Manager?

Restart Manager is a built-in API provided by Rstrtmgr.dll since Windows Vista. It allows programs to politely/forcefully ask other applications to unlock specific resources (mostly files). The intended users of this functionality are installer and updater developers who want to reduce the number of required system shutdowns.

When using this API, the caller registers a list of resources (files, processes, and services) that Restart Manager records in its database. Then, Restart Manager determines which applications and OS components it needs to shut down to unlock these resources and, upon confirmation, proceeds to (gracefully) do so. Later, the caller can request to restart affected applications. Note that the API does not grant additional access and can only shut down other programs if the caller has enough permissions.

Why collect?

Some ransomware families (specifically Conti and Akira) are known to abuse this API to unlock files before encryption. Artifacts from the Restart Manager database can provide valuable insight into the infection timeline for incident response.

Database structure

Restart Manager stores information about its sessions in a per-user registry location:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\RestartManager

Despite being part of the registry, the key only exists in memory and does not persist in the corresponding hive file due to the REG_OPTION_VOLATILE flag. In other words, shutting down the system deletes the key and its content. For the same reason, forensic tools that capture registry hive files for later analysis do not allow exploring the Restart Manager database because it only exists in the live registry.

Restart Manager stores information about each session in a dedicated sequentially-numbered SessionXXXX sub-key. The key can contain several values:

  • Sequence - a numerical value for synchronizing changes between multiple processes that share the session.

  • Owner - a binary value containing the PID and the precise start timestamp of the process that created the session.

  • RegFilesXXXX - a set of sequentially numbered multi-string values containing the registered file resources. Each line stores a path to a file.

  • RegProcsXXXX - a set of sequentially-numbered multi-string values containing the registered application resources. Each line stores three hexadecimal values separated by colons that uniquely encode a process via its PID and the start timestamp.

  • RegSvcsXXXX - a set of sequentially-numbered multi-string values containing the registered service resources. Each line stores a name of service.

  • Several binary values (RegFilesHash, RegProcsHash, RegSvcsHash, and SessionHash) with integrity checksums.

Figure: Restart Manager Session example.
 

Additionally, because the storage medium is the registry, the system maintains the LastWriteTime timestamp for each session and the database root keys.

Tool usage

You can download the tool binary from the GitHub repository page.

A tool for collecting Restart Manager artifacts by Hunt & Hackett.
Usage: RmArtifacts.exe [[-u <User name or SID>]] [[-o <Output XML file>]]

When invoked with no parameters, the tool displays data from the Restart Manager database of the current user. To specify another user, provide their account name or SID via the -u parameter. Note that this operation will most likely require admin rights and only works on currently logged-on users (since the database does not persist after logging out).

Additionally, the tool can capture detailed information (more detailed than the default output) into an XML file. You can use the -o parameter to specify the output file location.

Here is an example printed output:

Using the current user SID...

[*] Session0000
  Modified: 2024-06-20 06:44:29
  Owner: (PID 6244; started 2024-06-20 06:44:28)
  [Resources]
    File: C:\Users\user\Documents\MyFile.docx
    File: C:\Users\user\Documents\MyFile2.docx
    Application: (PID 7508; started 2024-03-21 21:15:48)
    Service: WSearch

Found 1 sessions.

And here is the corresponding XML file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Artifacts CaptureTime="2024-06-20 06:47:47" CaptureTimeRaw="133633324672300121">
  <SystemInfo>
    <System Name="DESKTOP-7P2CBIF" />
    <Boot BootId="2" BootTime="2024-06-20 06:09:33" BootTimeRaw="133633301735280569" />
  </SystemInfo>
  <RestartManagerDatabase UserSid="S-1-5-21-3769690586-2193241444-407356886-1001" LastWriteTime="2024-06-20 06:43:13" LastWriteTimeRaw="133633321933348889">
    <Session Name="Session0000" LastWriteTime="2024-06-20 06:44:29" LastWriteTimeRaw="133633322692406234">
      <Sequence Value="1" />
      <Owner PID="6244" StartedAt="2024-06-20 06:44:28" StartedAtRaw="133633322685746844" CurrentState="Terminated" />
      <RegisteredResources>
        <Group Type="File" Name="RegFiles0000">
          <File Path="C:\Users\user\Documents\MyFile.docx" />
          <File Path="C:\Users\user\Documents\MyFile2.docx" />
        </Group>
        <Group Type="Application" Name="RegProcs0000">
          <Application PID="7508" StartedAt="2024-03-21 21:15:48" StartedAtRaw="133555221488145470" CurrentState="Active" ImageName="\Device\HarddiskVolume3\Windows\explorer.exe" />
        </Group>
        <Group Type="Service" Name="RegSvcs0000">
          <Service Name="WSearch" />
        </Group>
      </RegisteredResources>
    </Session>
  </RestartManagerDatabase>
</Artifacts>

Caveats

The primary limitation of the tool is that it can only capture information about Resource Manager sessions that are currently active or haven't been terminated correctly. Whenever a program calls RmStartSession, Restart Manager either creates a new session key or reuses the first abandoned session key it finds. Explicitly terminating a session via RmEndSession deletes its key and, thus, all artifacts. Failing to call RmEndSession before the session owner exits causes the key to become abandoned and persist until a reboot or an overwrite by another process. Luckily, ransomware samples often fail to clean up Restart Manager sessions and leave artifacts behind.

Detection suggestions

We've observed the following Windows Event Log events on the default Windows configuration. Machines infected with Conti and Akira ransomware show excessive number of these events compared to normal.

Event ID Source Level Description

10000

RestartManager

Information

Starting session

10001

RestartManager

Information

Ending session

10002

RestartManager

Information

Shutting down application or service

10005

RestartManager

Information

Machine restart is required

10006

RestartManager

Error

Application or service could not be shut down

10010

RestartManager

Warning

Application cannot be restarted

While Restart Manager's event log entries don't provide almost any helpful details, it is possible to augment them with Sysmon events 12-14. You can configure logging for the SOFTWARE\Microsoft\RestartManager path under any/specified user hives.

Repository link

You can find the source code and binaries in the tool's GitHub repository.

Other material

Keep me informed

Sign up for the newsletter