mainegasil.blogg.se - Secure pipes for windows

Secure pipes for windows how to#
Secure pipes for windows windows#

So we could look for Windows processes that connect to an anonymous pipe and investigate from there. The interesting result is that native Windows processes do not use anonymous pipes that often. In theory, we could baseline processes that use anonymous pipes.

Is there anything that we can do using pipes? We can confirm that by debugging the sacrificial process spawned after launching a long-running assembly:Ī breakpoint was set on the "ntdll!NtWriteFile" function, and as it is possible to see, the handle where the sacrificial process was trying to write to was associated with an unnamed file that belonged to the pipe filesystem (Npfs):Īs we can see, spotting commands such as "execute-assembly" is not as trivial as the examples above. The image below shows an instance of a pipe created after issuing the "execute-assembly" command: Not every Cobalt Strike command creates a named pipe, some of them will use anonymous (unnamed) pipes to achieve the same result. We will use this information later to create Splunk searches that use Sysmon and a Yara rule to scan the processes memory. The screenshot below shows an example of Sysmon event ID 17 and 18 (pipe created and accessed, respectively) after the "keylogger" command was executed:Ī limited number of experiments were made, but no other legitimate application was found to create named pipes with the same naming convention.

Mimikatz (dcsync, dpapi, logonpasswords).

Some of the modules that were found to have this behaviour: 10 characters for the screenshot module). More specifically, it was observed that once a "job" was launched, the beacon created a named pipe the name of the pipe comprised only hexadecimal characters, and its length was found to be equal to the length of the module name (e.g. Prior to version 4.2, this named pipe's name could not be modified by operators. Note that these named pipes are not the SMB named pipes used for lateral movement that can be customised via the malleable profiles. Named Pipesį-Secure observed that when using some of the Cobalt Strike's modules that injected a reflective DLL into a sacrificial process, a named pipe was created with a predictable pattern. This can be done in a number of ways.Ĭobalt Strike uses both named and unnamed pipes to exchange data between the beacon and its sacrificial processes.

Unnamed pipes, that need their handle to be passed to the other communicating process in order to exchange data.

Named pipes, as the name implies, have a name and can be accessed by referencing this.

Fundamentally there are two types of pipe: named and unnamed. Pipes are shared memory used for processes to communicate between each other. But since the "keylogger" module is fully fileless, how does the communication with the main beacon process happen? The "keylogger" module, for example, is able to send the pressed keys back to the main beacon process. More specifically, a characteristic that remained unchanged was the ability to retrieve the output of an injected module. However, some general aspects haven't changed much, and that's what we are going to focus on.

Secure pipes for windows how to#

Recent versions of the framework have given operators great flexibility in how to customise the capability injection process.

Often, these capabilities are implemented as Reflective DLLs. This pattern offers a number of benefits, one being the ability to execute long running tasks, the "keylogger" being a prime example, without blocking the main Beacon thread. The "Fork-n-Run" pattern comprises the spawning of a new process (also referred to as a sacrificial process) and injecting capabilities into it. AnalysisĬobalt Strike is known to use a specific pattern, known as "Fork-n-Run", when executing some of its commands. The hope is that this post will help both defenders in strengthening their detection capabilities, and force red teamers to use more sophisticated and customised techniques. It must be noted that the IoC/behaviour was raised with the Cobalt Strike's author and subsequently exposed to operators as a customisable setting in the 4.2 malleable profile. Instead, we will focus our attention on some of the built-in modules that provide Cobalt Strike's post exploitation capability, such as the keylogger, Mimikatz and the screenshot modules. This post is not going to cover signatures for the default Cobalt Strike configuration - other papers offer an in-depth look at this. The aim of this post is to examine some previously unknown Indicators of Compromise (IoCs). Its functionality, flexibility and stability make it the state of the art when it comes to commercially available Command & Control frameworks.Ĭonsiderable efforts have been made to build robust signatures for Cobalt Strike and its implant, Beacon. During recent years, the Cobalt Strike framework has gained significant popularity amongst red teamers and threat actors alike.