DIGITAL FORENSICS AND INCIDENT RESPONSE 1.

We will explore the Windows incident surface and learn to discover the top checks on a compromised Windows host.

• Understand the process and procedures of hands-on Windows incident response.
• Explore the Windows incident surface and identify the signs of intrusion and anomalies.
• Hunt and quickly produce actionable results.
• Consolidate your knowledge by investigating a case scenario and a chain of events.

Acquisite, Investigate, Hunt And Respond :

The top response across most use cases, guidelines and recommendations is to implement techniques and procedures from Multiple domains.

• Forensics.
• Threat Hunting.
• Incident Response.

“ Understand the initial hybrid response stage

and outline a roadmap to unravel the incident. “

Creating a proper forensics collection from an investigation scene takes time and effort.

Imaging the entire system is still a beneficial use case, but there needs to be more efficient use of time.

A typical minimum resource requirement for a basic system today would be 256+ GB disc and 8+ GB RAM capacity, meaning imaging will take longer.

Time is one of many issues here.

As the size of the data image increases, the process of evaluation, decision-making, and producing valuable results for the case also becomes a challenge due to data overload.

“ Live approach makes a difference. “

The initial objective is rescuing Electronically Stored Information (ESI) from the battlefield.

Within cyber security, it is more often used in penetration testing and red teaming engagements for easy-to-detect and exploit vulnerabilities.

Easy and weak targets, such as unpatched vulnerability, outdated software, open shares, default credentials, weak access control, and misconfigurations in the attack surface should be noted first.

While it represents something easy to obtain or take advantage of, it also exists in blue and purple teaming operations.

From a defender’s perspective, it means detecting the typical patterns left and abused system resources by the attackers, such as port numbers, services, directories, and system features.

However, you can decide which areas to investigate first.

Approach: Translating Concepts Into Actions:

There are different policies and procedures available for various types of incidents.

Understanding the incident response and forensics foundations is essential.

“ While gaining technical competency is important, mastering the foundations and steps of responding to and handling incidents and forensics processes also matters. “

“ As a security professional, you must know how to handle things before responding to an incident. “

That means you should know how to plan, coordinate, handle the logistics, and implement policies and procedures appropriately, not only by hunting evil or saving the day on the technical side.

Solid knowledge of Windows OS, the six phases of the incident response, and the forensics investigation process and are familiar with typical tools and technologies used in that manner.

The aim is to translate digital forensics and incident response (DFIR) approaches and procedures into technical wins to produce actionable results.

SUMMARY:

• System information
• Accounts
• Sessions
• Startup
• Scheduled tasks
• Processes
• Services
• Network
• Registry
• Files

Compromised Host:

Case: Segmentation Spaghetti.

LMV Co. called us to help them with the new project. A company from previous projects called Team Alfred is back due to a feature in infrastructure improvement implementation failure that led to a severe cyber incident involving system compromise and a potential data breach.

Pseudo notion:

Improper implementation of the following concepts:
Architecture and system design.
Host-level security measures and user group management.

Working on a live system:

You are investigating a compromised host.

All required DFIR principles have been implemented, and you are working on a live clone host.

There may be applications and processes running on the compromised host; do not interact with or terminate them.

Note 1: Ransomware and system destruction controls have been applied, the host has been moved to the decoy network environment, and it’s ready for live examination.

Do not directly interact with the artefacts or pull the malicious samples (executables) out of the machine.

Handle each artefact with care during the examination process.

Note 2: Connect to the host using the default account ‘Administrator’. If the operating system asks you to select a user at any point, you must choose the ‘Administrator’ account and continue!

Pseudo-attack surface and flow:

• We are tasked to examine the host with IP 10.10.166.79, a Windows host and the second compromised host in the attack flow. Note that the device will receive a different IP address in the live examination environment. Still, the relationship of evidence should be made according to the mapping shown in the above graph.
• The first entry point is unsuitable for live DFIR implementation because the attacker destroyed the evidence on the first compromised host. While a team member prepares that device for live or post-mortem, we must examine the assigned device and inform the team quickly.

Essential details from the implemented baseline profile and previous optimisation work are shared in the list below.

• There is no custom configuration implementation at the regular boot-logon process.
• PowerShell profile set to block terminal history.
• All OS versions are updated to version 10.0.25398 and above.
• Time settings are set to UTC.
• OS is configured to allow only one active session at a time.
• Updates are set to be automatic.
• Local Admin and Guest accounts are disabled.
• Policies were updated in January.
• ADMIN-SRV is the trusted admin account.
• RDP is allowed only for trusted Admin.
• SSH is not allowed.
• AnyDesk instance is reserved only for emergency purposes.
• The firewall is in default; only a custom rule is available for AnyDesk.
• LMVCSS is a trusted service used for regular baseline checks.

Caution: Fragile Handle With Care!:

• Write blockers are your friend!
• The live approach is intrusive
• You can easily change file timestamps and overwrite data sectors by mistake
• Each step of the live investigation could alter the data residing on RAM and create new logs

There is no doubt about the value of acquiring the volatile and fragile artefacts such as memory images, registry items, processes, connections and event logs before causing any modification to the actual system.

Common practice is imaging the RAM and mentioning fragile artefacts first, creating a fast triage image with KAPE or your favourite tool, analysing the triage image, and deciding if there is a need to image the entire disk.

The live approach can be positioned right after creating a fast triage image.

You can use Autopsy, KAPE, and Volatility to have a secure copy of the volatile artefacts in a safe environment, such as a USB drive or remote host.

Reliability of the System Tools:

• The reliability of built-in system tools is crucial in collecting evidence and making decisions about the investigation environment.
• Inaccurate or compromised tools could lead to data loss and misinterpretation of data and severely impact the investigation process.

Receiving incorrect information on the system status or executing trapped instructions, scripts, or executables will take the investigation process down a rabbit hole.

First of all, we need a trusted command shell to start.

Verifying the integrity of files and executables in an offline (isolated) environment could be intrusive and take time.

Therefore, it is crucial to initiate a trusted command shell from your toolbox and run all your tools and commands from it.

Note that this approach is a workaround for having a safe shell without executing trapped instructions on the default command shell executables.

However, it is also essential to remember that this is insufficient to elude hijacked DLL files loaded by commands and executables.

Note:

Some features and functions rely on default environment variables, relative paths, and path-specific files, so loading the shell executable from a custom path has drawbacks, such as missing features and receiving error messages.

These limitations are an accepted condition.

Again, it is considered normal for some of the commands to be unavailable and for the results to contain error messages in addition to the expected output.

Additionally, since different processes might consume the resources of the compromised host, you may also encounter error messages when the available resources are insufficient.

The toolbox contains the trusted shell executables and other tools we will use during the investigation.

We didn’t use system recovery utilities (e.g., scf[.]exe), as they would be intrusive and alter some artefacts.

The trusted shell executable can be gathered either from the trusted image of the host owner or prepared by you using the trusted system image.

Our toolbox has two shell executables:

(Windows Command Prompt -CMD-DFIR[.]exe —

and

PowerShell Command Line Interface -PS-DFIR[.]exe — ).

We will start with the command prompt and continue with PowerShell CLI, which provides a richer set of commands, pipelining, and filtering capabilities.

Also, PowerShell CLI supports almost all command prompt commands and features.

First, we are starting with the Windows command prompt (CMD-DFIR[.]exe) to do the initial checks and initiate the PowerShell CLI without a profile.

We’ll review the environment variables to check if a sign of path interception (ATT&CK ID: T1574.007) is present in the system and decide if we can trust native system tools for the live investigation.

Use the given commands to dump and read the environment variables.

Screen the file to detect potential path interception.

Frequently hijacked fields are listed below:

• ComSpec: Windows prompt command executable (cmd[.]exe).
• Path: Environment path values.
• PSModulePath: PowerShell directories.
• Public: Public folder.
• TEMP and TMP: Temp locations.

Everything looks normal in PowerShell paths. Still, we’ll dig deeper and view the profile directories. There are six different profiles in PS paths, but only four are used by the PowerShell console and applications (Windows PowerShell ISE uses two).

First, we must identify which profile files exist.

Remember, we are using the secure shell we bring to the environment, so this shell might not interpret directory variables correctly.

Therefore, we’ll use the absolute paths we discovered in environment variables.

We have obtained the absolute path of the $HOME and $PSHOME directories from the environmental variables.

The USERPROFILE variable shows the absolute path to your $HOME directory.

The PSModulePath variable shows the absolute path to your $PSHOME and other relevant directories.

Multiple directories are likely indicated here.

Suppose you need help determining which one is the $PSHOME.

In that case, you can reference the PowerShell executable’s path.

Profile file needs to reside in the same directory as this executable.

Use the command below to reveal the absolute path of the $PSHOME.

where powershell.exe
where profile.ps1

We have identified the absolute paths for $HOME and $PSHOME; now, let’s start checking the profiles.

UPDATE the following command structure to identify the available profile files.

if exist "C:\[REDACTED]\profile.ps1" (echo PROFILE EXISTS) else (echo PROFILE DOES NOT EXIST)

After controlling all four paths, we discovered that the “All Users, All Hosts” profile file exists.

Let’s dump and read its contents like we did for environment variables.

This control will allow us to determine if an event-triggered execution (ATT&CK ID: 1546.013) is present in the system:

type “C:\[REDACTED]\profile.ps1” > ps_profile_dump.txt

We can see a custom PowerShell profile to clear and turn off the terminal history.

However, two additional statements have a high potential to be malicious.

Removing the terminal history section (ATT&CK ID: T1070.003) could also be considered a potential threat.

However, we have already been informed about that implementation by system admins, so we do not consider this indicator malicious.

Looking at the rest of the profile, the first of the two suspicious lines include:

Attempts to clear the event logs (ATT&CK ID: T1070.001)

and

Turn off the logging service (ATT&CK ID: T1562.002).

The second line consists of an action to keep the credentials stored in the Registry (ATT&CK ID: T1552.002).

These are red flags, as the case manager and system administrator didn’t mention them.

Therefore, we have added these two details to our report for further discussion and evaluation.

At this stage, the evidence proves why we are not relying directly on system resources and starting with Command Shell instead of PowerShell.

There is one more step we need to do before we switch to PowerShell:

We need to make sure that the profile file is not loaded.

To do this, we will use the trusted profile file that we bring with our toolkit.

We will convert the current profile to a backup file (change the extension from .ps1 to .bak ) and move our safe profile file to the corresponding directory.

ren PS-DFIR-Profile.ps1 profile.ps1(Rename the safe PS profile file to be used in the system.)

ren C:\[REDACTED]\profile.ps1 profile.bak(Change the existing profile file extension to backup (.bak) so we can move the safe profile file.)

copy profile.ps1 C:\[REDACTED]\ (Move the safe profile file to the existing profile path.)

The system will use the safe profile after renaming our secure profile file to the original one.

Doing so will immensely reduce the risk of accidentally executing the suspicious profile file.

Remember, as mentioned at the beginning, some commands will be unavailable, and the results will include error messages.

“ You can ignore the error message, as it does not affect the copying process. “

Now that we have ensured that the secure profile file will be used for each PowerShell terminal session, let’s switch to PowerShell and start collecting evidence and interpreting the results.

Note that we’ll still use the trusted shell instance from our toolbox instead of the existing one.

You can load the trusted PowerShell executable (PS-DFIR[.]exe) from the existing terminal session (CMD-DFIR[.]exe) or by double-clicking.

Note:

If you proceed without completing the profile procedures required for a secure PowerShell session, some artefacts will be altered and become unobtainable, necessitating a VM restart in subsequent tasks.

Therefore, DO NOT start the PowerShell command line without simulating the necessary profile implementations for a secure PowerShell session and ensuring the use of the secure profile file.

PS-DFIR.exe:

We must perform two additional PS-related checks.

The first check is to identify the version of PS being used.

The second check is to record the modules that are loaded in the current session and the modules that are not loaded but are installed.

Get-Module | ft ModuleType, Version, Name | tee ps-mods-loaded-modules.txt

Get-Module -ListAvailable | select ModuleType, Version, Name | tee ps-mods-all.txt

The priority is considering the loaded modules as we are focused on the live part.

Remember that we’ll need the second list (part of the baselines) containing all installed modules to spot any malicious PS module usage or legitimate module abuse in the detailed investigation and event correlation phases.

Documenting the summary of the performed actions and narrowing down the focus for manual investigation in the upcoming tasks:

Investigation Notes

In this phase, we focused on assessing the reliability of the system tools and the importance of having:

A Response toolkit (toolbox) for the initial live investigation.

Given the indicators we have uncovered, the host is compromised, and persistence and lateral movement techniques are potentially implemented.

Note that not all IoAs(Indicators Of Attack) and IoCs(Indicators Of Compromise) can be revealed through the checks we implemented in this task.

Quick wins of the procedures implemented in this task:

Environment variables are identified.
The PowerShell profile file is identified.
Secure PS profile file set.

Collected low-hanging fruits:

Manipulated PS profile file
Log clear attempt
Service manipulation attempt
Registry modification attempt
Action points for objective-driven and in-depth investigation:

Investigating registry items for malicious activities, especially for potential credential-stealing attempts.
Investigating status updates for “event log service”.
Investigating logged-in users over time (due to the implemented registry credential steal procedure).

Known changes:

The original PS profile was disabled, and the secure profile file was placed in the system.

Logs.

System Details and Configuration:

System details are an essential source of information which provides an initial contextual understanding of the host being analysed.

It helps us to identify the system at a higher level so we can quickly identify unsupported, vulnerable and malfunctioned systems, along with significant system changes that don’t align with trusted baselines.

First, we’ll identify the host network interface details to address the victim host appropriately during event correlation and data enrichment processes.

Identifying the available and active interfaces is essential to discovering additional malicious network activity involved in the case.

Identifying the assigned IP address of the secondary interface is crucial.

Even if you know the main interface details, such as the IPv4 address, you’ll still need to identify the MAC and IPv6 address details.

Hostname:

Get-CimInstance win32_networkadapterconfiguration -Filter IPEnabled=TRUE | ft DNSHostname, IPAddress, MACAddress | tee interfaces.txt

Time and OS details:

Get-CimInstance -ClassName Win32_OperatingSystem | fl CSName, Version, BuildNumber, InstallDate, LastBootUpTime, OSArchitecture | tee sysinfo.txt

Check the OS version details:

Get-Date | tee systime.txt ; Get-TimeZone | tee systime.txt -Append

Our queries are based on Get-CimInstance.

We can obtain similar information using other typical PowerShell cmdlets, environment variables and administrative tools (for instance, $env:computername, hostname and ipconfig).

“ However, while traditional Windows Management Instrumentation (WMI) classes are switching to the Common Information Model (CIM), reflecting that switch on the operational side is a good practice.

In short, CIM allows access to WMI and offers a richer data set. "

It will enable us to gather more comprehensive system information and implement more sophisticated filters to focus on the event of interest.

CIM-based cmdlets are not new; they have been available since PowerShell v3 and aliased most of the traditional cmdlets, such as Get-Command, in the background, so we have been using CIM cmdlets since quite some time ago.

UTC is not mandatory, it is considered universal best practice as it provides consistency across time zones, accuracy, synchronisation and avoids ambiguity. It is also recommended by industry experts, as well as by best practices and many compliance frameworks.

Policies:

Policies are valuable sources of information as they can cause system-wide modifications that can lead to implementing various persistence and impact techniques and procedures (ATT&CK ID: T1484.001).

Therefore, tracking modifications provides valuable context for creating accurate hypotheses and implementing required investigation and hunting procedures.

Let’s quickly create a report on implemented policy settings.

If you skipped using the safe PowerShell profile and executed the default one, the below command will fail as the report generation uses the event log service, which is trapped to stop by the default profile file.