Quick Recap:
More DFIR:
Startup Sequence: Boot, Logon and Startup:
The Windows startup sequence is a traditional location for implementing:
Execution tactics (ATT&CK ID: TA002).
and
Persistence (ATT&CK ID: TA003) tactics.
A vast amount of implementations here are based on already compromised systems, so we expect to have potential maintenance of backdoors, C2 implants, malicious tasks and services here.
Since abusing this sequence is quite popular in the wild, implementations have a higher chance of having the appearance of legitimate entries.
Also, this is the phase where the connection between details gains more importance for a successful hunt.
Therefore, investigating and identifying anomalies at this level requires a detail-oriented approach.
Also, this is the phase to remember the scope and purpose of the live investigation and avoid the track of the entire chain of each detail. Let’s start with the boot process using Sysinternal’s Autorunsc tool.
Since we discovered multiple user accounts and identified some suspicions in previous stages, we need to consider the potential of the different user profile spaces when feasible.
We can see that three entries were assigned to different user profiles.
Even if the list entries look standard and brief, we need to consider the additional user profile spaces and note down the entries linked with unexpected user profiles.
if a user profile path exists in any of the execution artefacts, the user account has a higher chance of being active at least once.
These user profile paths indicate a more extensive attack surface from the analyst’s perspective.
That’s why we keep considering this fact.
As we mentioned earlier, at this phase, we’ll reveal more details on the findings regarding linked executables, commands, user accounts, particular DLL references, and registry records.
Almost all entries seem expected and legitimate, except the second one.
Remember, we expect stealthier implementations at this phase, so considering everything according to the planned baselines and TTPs used in the wild is essential for a successful investigation.
Starting from this fact, let’s skim through the findings again and elaborate on why the second entry has attracted attention and should be in our report.
This registry value’s functionality is to execute the required programs when a user logs on (specifically establishing the user environment during the boot and login phases).
By default, and in most cases, it’s supposed to execute only the userinit[.]exe,
which is responsible for initialising the user session during the OS boot-logon sequence.
While it is possible to have additional executables at this phase, this must be known by the system administrator or exist in baselines.
“ Still, we can’t mark kludge solutions as IoC or IoA if they are documented and acknowledged by the system designers and administrators.
We can suggest improvement points at the end of our report, but we can’t judge the implementation method used during the investigation. “
We will focus on the Userinit hive, cmd executable, and all linked directories and resources, including its main registry path and DLLs.
Registry:
System details such as configuration and custom preferences in a hierarchical format.
Almost all system-wide changes implemented by system administrators or adversaries can be identified and verified through registry hive keys and values.
“ An all-in-one vital artefact for any DFIR case. “
Examine the two essential registry paths associated with the logon setting and user initialisation phases.
we can see that the userinit key contains two values. It looks slightly different from the autorunsc tool results, where we initially noticed the non-generic implementation of netshell.
The autorunsc tool highlighted this correctly, but due to the output format and long list of available details, more attention is required to identify this detail.
The suspicious cmd executable starts the netshell executable silently, which is anomalous!
There is a suspicious entry named “****shield”. According to our knowledge, it’s not a part of the default OS configuration.
We note this down for further investigation part with high priority.
If you compare this entry with the rest, you’ll see it’s the only one with a different pattern.
The potential reason is loading this DLL using the netshell executable from a temporary location.
Probably, the adversary implemented this remotely through the command line; that’s why the “.\” pattern is recorded here.
This finding underscores why we shouldn’t rely on compromised system utilities. Instead, we should implement lightweight approaches and bring our trusted utilities (mentioned as toolbox in T5) as much as possible.
Based on this finding, the suspicious DLL would have been loaded if we had used the netshell executable to list the firewall rule details in the previous steps.
Loading unknown and potentially malicious processes would be one of the last things we want to experience during a live investigation.
Some privilege escalation and persistence techniques rely on a netshell executable to trigger arbitrary code executions through helper DLLs (ATT&CK ID: 1546).
That’s why we take it into account so much, and the registry rooms of this module will guide you through the registry to reveal anomalies, IoCs, and IoAs.
Investigation Notes:
In this phase, we focused on identifying the startup sequence and registry-level details. Below are the quick wins of the procedures implemented in this task.
- Boot executables are identified
- Autostart applications are identified
- Boot-logon triggers are identified
Collected low-hanging fruits:
- AnyDesk runs for a different user account
- Userinit hive triggers cmd executable
- The cmd executable triggers the netshell executable
- DLL hijack or load attempt on netshell hive
Action points for objective-driven and in-depth investigation:
- Considering the processes that are capable of sharing remote screens in the following phases
- Considering the potentially active user profile folders in the following phases
- Identifying and mapping the activities linked with the netshell executable and the suspicious DLL file
Known changes:
- Dump data files stored in the toolbox folder
- Logs
