What is this blog post about?

This blog post is about why incident responder artifacts not only play a role on the defensive but also offensive side of cyber security. We are gonna look at some of the usually collected evidences and how they can be valuable to us as red team operators. We will be putting everything together in a proof of concept tool that tries to simplify collecting that information.

Incident Response Process

According to the NIST incident response process the process can be split in the following 4 process steps:

Step #1: Preparation

“Incident response methodologies typically emphasize preparation—not only establishing an incident response capability so that the organization is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.”

Source: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Step #2: Detection and Analysis

“An incident response analyst is responsible for collecting and analyzing data to find any clues to help identify the source of an attack. In this step, analysts identify the nature of the attack and its impact on systems. The business and the security professionals it works with utilize the tools and indicators of compromise (IOCs) that have been developed to track the attacked systems.”

Source: https://www.eccouncil.org/cybersecurity-exchange/incident-handling/what-is-incident-response-life-cycle/

Step #3: Containment, Eradication and Recovery

“Containment is important before an incident overwhelms resources or increases damage. Most incidents require containment, so that is an important consideration early in the course of handling each incident.
Containment provides time for developing a tailored remediation strategy. An essential part of
containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions).”

Source: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

Step #4: Post-Incident Activity

“The final phase of the incident response life cycle is to perform a postmortem of the entire incident (Cynet, 2022). This helps the organization understand how the incident took place and what it can do to prevent such incidents from happening in the future. The lessons learned during this phase can improve the organization’s incident security protocols and make its security strategy more robust and effective.”

Source: https://www.eccouncil.org/cybersecurity-exchange/incident-handling/what-is-incident-response-life-cycle/

During the second incident response step, Detection and Analysis, incident response tools provide capabilities for deep technical investigation. They analyze the collected data, including log files, network traffic, and system artifacts, to gain insights into the nature and scope of the incident. This helps incident response teams understand the attack vectors, identify affected systems or assets, and assess the overall impact of the incident accurately.

Why can they be interesting for red teaming?

Artifacts are invaluable to a red team operator as they provide critical insights into how defenders detect and respond to malicious activities. By studying these artifacts, red team operators can understand what traces their actions leave behind and how those traces are analyzed by incident responders. This knowledge allows them to refine their techniques, making them stealthier and more effective. For example, understanding common logging practices and endpoint detection mechanisms can help a red team operator adjust their tactics to minimize detectable footprints, evade detection, and prolong their presence within the target environment. This constant adaptation is essential for staying ahead of defenders and achieving the red team’s objectives.

In the case of a successful session takeover or initial access through payload execution, artifacts can provide critical insights into how the user used the compromised system and what kind of actions blend into the environment and into the previous user behavior.

Logs of suspicious login attempts, unusual network traffic patterns, and changes in system configurations are all typical artifacts that incident responders scrutinize. By analyzing these, red team operators can identify the actions where their activities may set off an alert. An example for this can be a specific registry entry, which altered by their payloads, may generate an entry in the used endpoint protection solution. Armed with this information, they can develop countermeasures, such as custom payloads that blend in with legitimate traffic or techniques that clean up or avoid creating incriminating artifacts. This proactive approach helps red teams enhance their operational security and effectiveness, ensuring that their simulated attacks provide valuable insights for improving an organization’s defense mechanisms.

What are artifacts?

Incident responder artifacts are pieces of evidence or information that an incident responder collects and analyzes during an investigation of a cybersecurity incident. These artifacts help in understanding the nature, scope, and impact of the incident, as well as in identifying the attacker, their methods, and any compromised systems or data.

What kinds of artifacts exist?

Incident responders utilize various artifacts to manage and analyze security incidents. These artifacts can be broadly categorized into several types based on their purpose and the phase of the incident response process in which they are used.

For this blog post the following artifacts will be relevant to us:

User Activity Artifacts

Browser: Logs of web browsing activity, bookmarks, installed extensions and more.

Command Histories: Histories from command-line interfaces (Windows Run prompt, Command prompt history, PowerShell command log and more).

Host Artifacts

File System Artifacts: Files, directories, and their metadata (timestamps, permissions).

Registry Hives (Windows): Captures of the Windows Registry for analyzing system and user configurations.

This blog post as well as the developed tool will focus on artifacts that can be collected during the active user session from the registry and file system with regular user privileges.

What data can we collect and what do we learn from it?

The following table provides an overview of what information the developed tool collects and what we as red team operators can learn from the collected information.

Artifact	Learning
Recently used Office files and folders	Has our victim worked on documents related to our target systems or sensitive information that can be used to achieve an objective?
Shortcuts (LNK or URL) in common locations	Are commonly used work folders on network shares or cloud applications linked in common locations? This gives us an insight on commonly used internal portals for IT service desks, intranet pages, code repositories as well as if network profiles or other cloud syncing solutions are in use.
Explorer files and folders	What are recently accessed files and their locations? What are executed commands using the Run dialog? What paths have been manually entered into the Windows Explorer?
History of connected USB storage devices	Are mobile storage devices allowed or can they be used for data exchange? This would allow for a malicious USB stick scenario or data exfiltration using USB storage devices.
Browser Favorites (Microsoft Edge for now)	Browser favorites can give us an insight on commonly used internal portals for IT service desks, intranet pages, code repositories and more.
Usage of executable files and applications launched by the user (UserAssist)	What application did the user launch and when have they been used last? This gives us an insight into possible persistence targets.

As a red team operator I spend a lot of my time in the C2 framework executing tools and collection information. In order to minimize the time spent to curate the needed information, the next logical step is to automate the collection and integrate it into the daily operation.

Choosing a programming language

Most C2 frameworks as of today support Beacon Object Files (BOF) or In-Memory execution of binaries (PE) or In-Memory execution of .NET C# binaries.

Because C# is a high-level, versatile language that can be easily read and is more accessible, I chose C# over the development of a BOF. It integrates seamlessly with the .NET framework, providing access to a vast array of libraries and tools that can significantly accelerate development. Its strong type system, garbage collection, and robust standard library help in writing more reliable and maintainable code.

C# is compatible with in-memory execution, making it an ideal choice for developing tools to be used with command and control (C2) software. In-memory execution is a technique that allows code to run directly from memory without being written to disk, significantly reducing the likelihood of detection by traditional security measures. C# can easily leverage the capabilities of the .NET framework to load and execute assemblies in memory.

Therefore the developed tool can be used in common C2 frameworks such as Cobalt Strike or Brute Ratel, Sliver, Havoc and similar.

Choosing a name for the tool

Knockout was chosen as it resembles a day at work after getting knocked out in an accident and having forgotten what you every day work life looks like, so you ask the computer to tell you what actions and documents you usually interact with.

What does the execution look like?

The developed tool KNOCKOUT can be executed after compilation by using either the binary as a standalone executable, or by using your favorite C2 framework and its built-in C# execution command.

A screenshot of the tool being executed using in-process C# using the command “sharpinline” of the C2 framework Brute Ratel C4:

The tool can also be executed as a standalone binary:

Using KNOCKOUT now gives us the opportunity to collect multiple sources of information in one step to efficiently assess our situation on the compromised endpoint. This otherwise would require multiple steps to query the different sources (file system, registry, etc.), then aggregate the information from the various output formats which as a result is taking a chunk of time which is already very valuable and limited during initial access, where every minute counts to proceed with persistence or lateral movement to avoid loosing the foothold.

The tool has been open sourced and can be found in the following GitHub repository:

https://github.com/NVISOsecurity/KNOCKOUT

Future improvement ideas

Unhooking of used dynamic-link libraries (DLL)

Because the amount of operational security depends on the C2 framework used, it would be best practice to make sure to unhook used dynamic runtime libraries, so the endpoint security solution gets minimal information about the execution of the tool.

Create structured output for automated processing

Engineers do love automation! By formatting the content into a common format such as JSON, XML or whichever you prefer, other tools could built actions upon the output of this tool.

Bypass local registry interaction

In the beginning of the tool development a decision had to be made to access the registry on the live system as access to the underlying file of the user hive “NTUSER.DAT” was not possible as a low privileged user as the file is in use. With higher privileges there are ways to access this file and exfiltrate it to query the data on a local system and evade the endpoint protection.

Development of a Beacon Object File (BOF)

It should be possible to develop a Beacon Object File (BOF) to read and parse the registry values and files just like this tool, allowing the flexibility for the operator to choose to run a BOF or .NET executable based on the process the implant is running in.

Add currently unsupported artifacts

Of course there are always artifacts for which parsing is a lot more complex to implement and as such the following two examples have not been integrated into the tool (yet):

• HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU

Detection opportunities

Unmodified original binary

The unmodified tool when downloaded from the release tab of the GitHub repository has the following properties:

Filename	KNOCKOUTx64.exe
SHA256	3B248C3E8B64719D5991A762330A0B2BB58E116247DA89E781EC1A53F4ED1D00
SHA1	86C0199B6A9305621B011DAAF999A4FE0F266BA9
MD5	58B142287E47B5605363639F5C4ABB45
Application GUID	ad5cead9-cde0-4362-83eb-7d80de0025c9

The repository also includes a YARA rule which can be used to detect the unmodified tool and can be found here:

https://github.com/NVISOsecurity/KNOCKOUT/blob/main/KNOCKOUT.yar

Accessed system resources

The tool accesses the following locations during its runtime:

Location	Type	Usage
HKEY_CURRENT_USER\Software\Microsoft\Office\<VERSION>\<APPLICATION>\File MRU	Registry	Retrieve information about recently opened office files.
HKEY_CURRENT_USER\Software\Microsoft\Office\<VERSION>\<APPLICATION>\Place MRU	Registry	Retrieve information about recently used folders.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs	Registry	Retrieve information about the recent files and folders accessed by the user.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU	Registry	Items typed into the Windows Run dialog are recorded in the Registry under the RunMRU key.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths	Registry	The last 25 paths typed or inserted into the path bar of File Explorer are saved into the TypedPaths registry key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR	Registry	The USBSTOR registry key holds information about the plugged in USB storage devices.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist	Registry	The User Assist key contains settings and data of programs that were launched via Windows Explorer (explorer.exe).
C:\Users\<USERNAME>\Appdata\Roaming\Microsoft\Windows\Recent	File system	Look for shortcut files (LNK) in order to list recently accessed filenames and folders.
C:\Users\<USERNAME>\Desktop	File system	Look for shortcut files (LNK, URL) in order to list recently accessed filenames and folders.
C:\Users\<USERNAME>\AppData\Roaming\Microsoft\Office\Recent\	File system	Look for shortcut files (LNK) in order to list recently accessed filenames and folders.
C:\Users\<USERNAME>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations	File system	Retrieve recently launched applications by matching their AppID with a known list.
C:\Users\<USERNAME>\Documents\	File system	Look for internet shortcut files (URL) in order to retrieve browsing targets.
C:\Users\<USERNAME>\Downloads\	File system	Look for internet shortcut files (URL) in order to retrieve browsing targets.

Used WinAPI calls

The following Windows API calls are being used by the tool:

As we are working with .NET C# some of the calls, for example “Directory.GetFiles(directory)” have been monitored using the API Monitor (Warning: Insecure Link HTTP) in order to determine the corresponding Windows API calls CreateFile, ReadFile) and as such can be incomplete.

Win32 API Call	Implemented in DLL	Usage	Resource
RegOpenKeyEx	advapi32.dll	Opens the specified registry key.	https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regopenkeyexa
RegCloseKey	advapi32.dll	Closes a handle to the specified registry key.	https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regclosekey
RegEnumKeyEx	advapi32.dll	Used to enumerate registry keys Enumerates the subkeys of the specified open registry key.	https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regenumkeyexa
RegEnumValue	advapi32.dll	Enumerates the values for the specified open registry key.	https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regenumvaluea
RegQueryValueEx	advapi32.dll	Retrieves the type and data for the specified value name associated with an open registry key.	https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexa
SHGetKnownFolderPath	Shell32.dll	Retrieves the full path of a known folder identified by the folder’s KNOWNFOLDERID.	https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath
CreateFile	Kernel32.dll	Creates or opens a file or I/O device.	https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
ReadFile	Kernel32.dll	Reads data from the specified file or input/output (I/O) device.	https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile
CloseHandle	Kernel32.dll	Closes an open object handle.	https://learn.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-closehandle

Conclusion

In conclusion, artifacts are a crucial asset for red team operators, providing them with the intelligence necessary to refine their techniques and remain stealthy within target environments. By thoroughly understanding how defenders detect and analyze these artifacts, red teamers can continuously adapt their strategies to evade detection and prolong their presence. This deep knowledge of defensive mechanisms and logging practices allows them to craft custom payloads and tactics that minimize detectable footprints, thus enhancing their operational security. Ultimately, this proactive approach not only improves the effectiveness of red team operations but also delivers invaluable insights for strengthening an organization’s overall security posture.

About the author