Detecting Namedpipe Pivoting using Sysmon

In this quick post we will be sharing with you a detection trick you can use to detect lateral movement via rogue named pipe (i.e. cobaltstrike smb-beacon). 

Detectioon theory and constraints we can think of are listed below:

• For namedpipes pivoting, communication will happen over SMB ---> we need Sysmon NetworkConnect EventID 3 with SourcePort=445 or DestinationPort=445 
• A new Pipe (rogue) will be created by any process (under operator's control, same apply to the name of the pipe) --> for the directly associated sysmon eventid 17 (PipeCreate), we can't really filter by pipe name or by process name (subject to high # of false positives)
• Since the named pipe will be accessible remotely via SMB, then normally SYSTEM virtual process will be the one receiving the inbound connection from the operator machine and this event will be logged via sysmon eventid 3.
• SYSTEM process will need to connect to the rogue named pipe created by process-X (unknown to us), and this can be detected via Sysmon eventid 18 (PipeConnect).

To test this theory we searched for a simple powershell script implementing this technique and we've found a good candidate by Joe Vest (@joevest), Invoke-PipeShell.

Setup is very simple:

     

   Operator from  [NLT10] --- Open an Interactive Shell ---> [IEWIN7]:"Remote Machine" 

On machine IEWIN7 execute the following command, that will create a listening local named pipe "46a676ab7f179e511e30dd2dc41bd388" (mimic ProjectSauron APT namedpipe name),  and a 16 bytes AES key to encrypt traffic:

We can confirm execution success via process explorer:

On Machine NLT10 we will simply initiate an authenticated (cmd /c runas /netonly /user:IEWIN\IEUser powershell.exe) session to IEWIN7 and using the following command to connect to the remote pipe :

Checking our Sysmon Logs, we can see that our theory is quite correct and can be indeed used to detect/hunt for similar behavior:

As you can see above, we have sysmon 18 (PipeConnection) followed by sysmon 3 (NetworkConnect) within seconds of difference, now let's explore those event's details:

As explained earlier, we don't really care about PipeCreation event for this specifc use case, Sysmon 18 shows us what we need: System process connecting to a named pipe to deliver commands and to return back cmd's execution results to Machine1  (Command from machine1 --- > System:445 on machine2 ---> namedPipe --read---> malicious process on Machine2 and vice versa).

Also as expected System virtual process is receiving an incoming SMB connection from a remote host (SourcePort=445 and DestinationHost eq to Operator machine).

Detection Logic:

(EventID=18 and Image eq "System") followed by (EventID=3 and Image eq "System" and SourcePort eq "445") within less than 1 minutes and both events from same Hostname.

Raw evtx file associated with this test can be found here for download.

N.B: use other pentesting tools tha support namedpipes pivoting and let us know about the results!

The "-" impact of Network Level Authentication on failed logon events - 4625

In this short post we will be highlighting some of the observed abnormal failed logon events (related to RDP brute force activity) and how you can detect them and also how you can leverage them to conduct a "stealthy" RDP brute-forcing attack.

For this, we will be using an open source RDP client xfreerdp (available on Kali Linux by default):

Xfreerdp allow us to control the following parameters:

• source client machine (that the target victim machine should see)
•  /sec:nla will force the use of NLA (Network Level Authentication) as the RDP protocol to use (recommended by Microsoft)
• /u /p and /v for the target username, password (wrong password) and hostname/IP

Once the logon is attempted, those are the events that will be seen on the target machine:

As you can see above: 

• the logon type is marked as 3 (network) instead of 10 (RDP)
• the source network address is equal to "-"
• the source machine is marked as "Kali" (although we've specified a different client-hostname in xfreerdp /client-hostname parameter), but this can be changed by the attacker (hostname)

To investigate further if there other traces of failed RDP logon attempts, we need to check the following event sources (under Applications and services logs\Microsoft):

• TerminalServices-RemoteConnectionManager\Operational
• TerminalServices-LocalSessionManager\Operational
• RemoteDesktopServices-RemoteDesktopSessionManager

As you can see below, no useful events are logged (for failed attemts, those event sources are useful for successful logons):

Even if you change the settings on the target machine to not require NLA authentication, same events are logged when xfreerdp is supplied with /sec:nla:

If we specify other RDP authentication protocol (other than NLA), we can see the source IP of the failed logon activity:

4625 will look like this:

Both of the sourceIP and the correct logon type are recorded, but what's abnormal is the source workstation name equal to the target machine name.

And for eventid 1149, it reports also the correct source IP and the type of logon (RDP), but it marks this logon as succefful logon or it was a failed attempt.

So, the question now is what are the main takeaways?

1. detection correlation rules based on occurences count (i.e. more than x of failed attempts from same source IP or hostname) can be broken if one uses similar technique (rdp client that support setting rdp authentication protocol as NLA). 
2. Look for 4625 events (usually those are the ones that are collected and forwarded to a SIEM) with source network address NULL or equal to "-"
3. Look for 4625 events where source workstation is equal to AccountName or AccountDomain.
4. As a redteamer, if you want to conduct brute-forcing (inside the network), use this technique and you will be fine.
5. Don't trust event logs blindly!

To verify if point 2 matches any false positive, we've run the following query on a real environment:

That's all!

Credential Access - Detecting Browser's secrets stealing

Browser's saved credentials (passwords & permanent cookies) are a juicy target for any attacker for the following reasons:

• elevated privileges are not required
• we all tend to reuse passwords and if not we rely a lot on auto-saving them in the browser
• EDR and AV solutions are quite ineffective at detecting them based solely on their behavior (file read access is a legit action as long as the source process is not a known bad binary)
• Stolen credential allow to log to some web application (business data)

In this short post we will explain you one way to detect rogue processes accessing specific browser's files used to obtain clear text saved passwords, this test is limited to the following browsers, but you can replicate the same logic for other browsers:

• Google Chrome & Opera (both based on chromium browser)
• Mozzila Firefox

Browser's creds dumpers (not in-memory) need to access the following files (mapped per browser):

Windows provide the ability to audit access to chosen folders or files based on the desired audit settings (principal or account, type of access modify, fullcontrol etc. and success of failure attempts):

1st, you will need to edit your GPO advanced audit policy settings to include Object Access > File System:

at this point nothing is logged yet, now we need to deploy a simple PowerShell script (must be run with high privileges) to edit the desired files and folders's audit access control list:

N.B: to reduce generated 4663 events, you can be more specific and change the paths array to point to specific files instead of all the folder and sub-folders & also to set $InheritType to "None" (used to specify that audit settings will be inherited by child objects).

Now let's run the malicious program and check our Security Events:

As can be seen above, you will need to collect 4663 events or use local scheduled task that notifies you based on an events XML filter that exclude legit combination of Process Name and Accesses (usually you will see browser processes, explorer.exe if accessed via GUI, dllhost.exe and eventually backup and restoring related processes). 

From an offensive perspective, it's good to execute your browsers dumping routine from one of those trusted processes (i.e. dllhost.exe or explorer.exe hollowing).

Remember that the same concept can be applied to other sensitive files, below an example of rogue access via renamed rar.exe with an attempt to compress & ex-filtration victim's offline global address book:

Below resulting log:

That's all & remember that key-loggers and browser's creds dumpers are still challenging to detect, test your EDR and AV solution before others do it.