Skip to content

detection

Diving into RPC – Exploring a Deeper Layer of Detection

Introduction

In this article, we explore the defensive capabilities of Microsoft RPC (MSRPC) and introduce a powerful tool called RPCFirewall. While many discussions focus on identifying vulnerabilities within MSRPC, we will examine how to use RPCFirewall to detect and mitigate malicious activities that exploit this protocol.

MSRPC is a critical component of the Windows operating system, enabling various functionalities and communications. Due to its extensive use, numerous lateral movement techniques leverage MSRPC, including attacks like PSExec, Remote Scheduled Task, DCSync… Differentiating between legitimate and malicious MSRPC traffic can be challenging when relying solely on traditional network metadata like IP addresses and ports.

Remote Procedure Call (RPC) is a protocol for interprocess communication (IPC) that allows a program to execute a procedure on a remote server as if it were local. In Windows, MSRPC is Microsoft’s implementation of this protocol, following a client-server model. The server defines the interface it exposes using the Interface Definition Language (IDL), which includes a unique universal identifier (UUID) and the definitions of the functions available for remote invocation.

When discussing RPC, it is important to recognize that there are various way of interaction available. Examples include RPC over TCP/IP (ncacn_ip_tcp) and RPC over named pipes (ncacn_np). Detailed information on these protocols can be found at the following link: MS-RPCE Protocols.:MS-RPCE Protocols

RPC FILTER & RPC FIREWALL, make the difference

1. Is rpc filter sustainable?

Windows offers the ability to filter RPC calls through its firewall, allowing you to permit or block incoming RPC calls while auditing them. You can achieve this with the following commands, for example:

rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
quit

Each time these rules are triggered, windows is supposed to generate the EventCode 5712.

EventCode 5712 Official documentation

Result Evilginx

However the big point is this log is inconsistent. It lacks of information and it’s not generated each time.

2. The capabilities of RPC Firewall

That’s where RPCFirewall from Zero Networks comes in. The project aims to improve the logging of RPC Audit and ETW, creating a more informative logging journal in Windows. They have an excellent article explaining their solution, available at the following link: Stopping lateral movement with RPC Firewall and you can find the GitHub project here: Zeronetwork github

With RPCFirewall, you can easily create a configuration file and choose to allow, block, and audit based on interface_uuid, op_num, or src_ip. The parameters you can use are:

  • fw: Applies the RPCFirewall configuration and logs in the RPCFW journal.
  • flt: Uses the RPC Filters.

In our case, we mainly performed our tests with the fw option, with action allow and audit enabled. However, Microsoft introduced a technology called « Protected process Light », and for these protected process, we can only use the flt option as the RPCFW dll can’t inject into it. So we could still use the EventCode 5712

That’s why we prepared to ingest everything into Splunk for testing. But first, we need to find a way to identify all the functions associated with an RPC interface_uuid and op_num.

How to retrieve RPC Interfaces?

To retrieve all the information about RPC interfaces, I personally use the script from enigma0x3 which I modified slightly to generate a CSV.

To use the following DLL: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll, you will need to install the Windows SDK debugger

$rpc = ls C:\Windows\System32\*.exe, C:\Windows\System32\*.dll | Get-RpcServer -DbgHelpPath "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll"

$results = @()

foreach ($rpc1 in $rpc) {
    # Write-Host $rpc1  # You can uncomment this for debugging if needed.
    foreach ($proc in $rpc1.Procedures) {
        $ourObject = New-Object -TypeName psobject
        $ourObject | Add-Member -MemberType NoteProperty -Name InterfaceID -Value $rpc1.InterfaceID
        $ourObject | Add-Member -MemberType NoteProperty -Name FileName -Value $rpc1.Name
        $ourObject | Add-Member -MemberType NoteProperty -Name ProcedureName -Value $proc.Name
        $ourObject | Add-Member -MemberType NoteProperty -Name ProcedureNumber -Value $proc.ProcNum
        $results += $ourObject
    }
}

# Now export $results to CSV
$results | Export-Csv -Path "C:\Users\Administrator\Documents\rpc.csv" -NoTypeInformation

Now we can have the lookup that determine the Procedure Name(the function) and the file name depending on the UUID_Interface and the Procedure_Number (opnum)

A bit of Splunk Configuration

Let’s prepare the splunk configuration with the RPCFW logs. Firstly we add the following configuration on our DC (LAB-DC) :

[WinEventLog://RPCFW]
checkpointInterval = 5
current_only = 0
disabled = 0
index = windows
renderXml = true
start_from = oldest

Then we prepare the transforms.conf on the application on the Search Head cluster Deployer to push on the Search Head Cluster :

XmlWinEventLog:RPCFW]
EXTRACT-event_details = <EventID Qualifiers='\d+'>\s*(?<event_id>\d+)\s*</EventID>.*<TimeCreated SystemTime='(?<system_time>[^']+)'/>.*<EventRecordID>(?<record_id>\d+)</EventRecordID>.*<Execution ProcessID='(?<process_id>\d+)' ThreadID='(?<thread_id>\d+)'/>.*<Computer>(?<computer>[^<]+)</Computer>
EXTRACT-user_activity = <Data>(?<activity>[^<]+)</Data><Data>\d+</Data><Data>(?<path>[^<]+)</Data><Data>(?<protocol>[^<]+)</Data><Data>(?<source_port>[^<]+)</Data><Data>(?<src>[^<]+)</Data><Data>(?<interface_uuid>[^<]+)</Data><Data>(?<procedure_number>\d+)</Data><Data>(?<user>[^<]+)</Data><Data>(?<privacy>[^<]+)</Data><Data>(?<auth_type>[^<]+)</Data><Data>\d+</Data><Data>(?<destination_ip>[^<]+)</Data><Data>(?<destination_port>\d+)</Data><Data>(?<sid>[^<]+)</Data>
LOOKUP-interface = interface-lookup interface_uuid AS interface_uuid procedure_number AS procedure_number OUTPUTNEW file_name, procedure_name
````

And then the props.conf :
```conf
[interface-lookup]
filename = rpc_procedures.csv
external_type = file
fields_list = interface_uuid, file_name, procedure_number, procedure_name

Analysing of some attackers tools.

If you’re working in cybersecurity, you know that detecting malicious behavior can sometimes be a challenging task. Microsoft interactions are really complex, and even though EDR/NDR solutions are improving, they can still miss some behaviors. In Windows, many of these interactions are based on RPC, which is also used by attacker tools. In this section, we will use many various famous attacker tools and analyze their behavior

We will execute various lateral movement, reconnaissance, or credential harvesting payloads from different tools such as Impacket , Sysinternals, Ghostpack, Mimikatz , and analyze them using both Wireshark and Splunk. For Wireshark, we can apply the following filter to specifically view the RPC calls and the interface_uuid:

dcerpc and ip.src == 172.16.16.22 and dcerpc.cn_bind_to_uuid

1. Impacket Atexec.py

We can start our analysis with a first tool from impacket : atexec.py. Atexec.py permits to eecute remote tasks scheduler through the task Scheduler.

First, Let’s analyze some part of the python code:

Code analysis

On this function, we see the dce.bind function on the MSRPC_UUID_TSCHS Interface. If we look on the Microsoft documentation about TSCHS (MS-TSCH), we find the following interfaces :

Code analysis

Now if we look back to the code deeper, we can see the following functions executed :

Code analysis 2

So what are we expecting from these? If we’re using TCP, we expect to see a GUID of 86D35949-83C9-4044-B424-DB363231FD0C with the functions :

– SchRegisterTask – SchRpcRun – SchGetLastRunInfo – SchRpcDelete

Let’s have fun and play with wireshark and Splunk.

atexec.py 'FTRSEC/Administrator:Toto1234!@LAB-DC' cmd.exe /c calc.exe
Wireshark analysis - TaskScheduler

Code analysis 2

We got right on the interface. After executing the payload we can effectively see the corresponding_uuid.

Let’s see what we have on splunk :

Splunk analysis - TaskScheduler

Code analysis 2

Bingo ! We got exactly the expected behavior and were able to detect fully the atexec.py in the second it was launched !!

Let’s see some other example with splunk following the same procedures :

2. Impacket LookupSids.py

python lookupsid.py 'FTRSEC/Administrator:Toto1234!@LAB-DC'
LookupSids - Splunk

LookupSids

3. Net view from powershell

Net view \\LAB-DC
Net view - Splunk

Net view - Splunk

4. Impacket dcomexec.py

python .\dcomexec.py -object MMC20 Administrator:Toto1234!@LAB-DC
Dcomexec - Splunk

Dcomexec

5. Impacket secretsdump.py

python secretsdump.py ftrsec/Administrator:Toto1234!@LAB-DC
Secretsdump - Splunk

Secretsdump

6. DCSync with Mimikatz

.\mimikatz.exe "lsadump::dcsync /domain:ftrsec.local /user:krbtgt" exit
DCSync - Wireshark

DCSync - Wireshark

DCSync - Splunk

DCSync - Splunk

7. PSExec

Note

For psexec, we couldn’ see on the RPCFW journal because psexec work by starting the service psexesvc.exe on the remote destination. However, the service is protected, so we will detect using the EventCode 5712

.\PsExec64.exe \\LAB-DC ipconfig /all
Psexec - Wireshark

Psexec - Splunk

Psexec - Splunk

DCSync - Splunk

Now because we didn’t use the blocking functionality on this article, we will try to modify our configuration line to : flt:audit:true uuid:367abb81-9844-35f1-ad32-98f038001003 action:block.

And we can see it blocked perfectly our psexec !

Psexec - Blocked

DCSync - Splunk

Recapitulative table of the attacks detected by RPC Firewall

Recapitulative table

Conclusion

To conclude, we were highly impressed by the RPC Firewall project by Zero Networks. It enabled us to detect advanced lateralization, reconnaissance, and credential dumping tools utilizing the RPC protocols more quickly and thoroughly than current EventCodes, when detection was possible.

In this article, we primarily focused on the detection aspect. However, as demonstrated with PsExec, the RPC Firewall also possesses effective blocking capabilities. Due to the protected process light, we still need to rely on the native Windows filtering, but only when necessary.

We recommend using both RPCFW and EventCode 5712 for improved detection coverage.

Next step will be to try their project LdapFirewall !

Happy RPC-Splunking!

REFERENCE

https://www.akamai.com/blog/security/guide-rpc-filter https://zeronetworks.com/blog/stopping-lateral-movement-via-the-rpc-firewall https://youtu.be/hz_YPIMeBMI

Detecting browser data theft using Splunk

During my daily cyberwatch, I recently found this great article by Will Harris about browser data theft using a Windows Event Log 16385: security.googleblog.com

I decided to try implementing it in my own Splunk infrastructure and to create detection rules around it. This article will mainly discuss the Splunk aspect; if you want to know the details, I invite you to read the article linked above.

1. Splunk Universal Forwarder Configuration

On my Windows system, I started by activating the EventCode to see it in the Debug Channel using the PowerShell commands provided by Will Harris:

$log = New-Object System.Diagnostics.Eventing.Reader.EventLogConfiguration Microsoft-Windows-Crypto-DPAPI/Debug
$log.IsEnabled = $True
$log.SaveChanges()

Then, I prepared my Splunk logging on the UF. I placed the following configuration in the inputs.conf file of my application:

[WinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug]
index = windows
disabled = 0
start_from = oldest
current_only = 0
checkpointInterval = 5
renderXml = true

2. Splunk Search Head Configuration

I added some parsing for the relevant data I needed for my PoC in the props.conf file of my search head application.

We need the application field because we want to identify when Chrome data is being accessed, and we need the caller_process_id because we have to correlate it with the process_id from EventCode 4688 to identify the originating process. To achieve this goal, we translated the decimal caller_process_id to the hexadecimal parent_process_id.

[XmlWinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug]
EXTRACT-DataDescription = <Data Name='DataDescription'>(?<application>[^<]*)</Data>
EXTRACT-CallerProcessID = <Data Name='CallerProcessID'>(?<caller_process_id>\d+)</Data>
EVAL-parent_process_id = lower(printf("%x", caller_process_id))

3. Splunk Detection Rule

Then, we created a quick Splunk detection rule to identify this behavior, and we observed that it successfully triggered when we ran the Python stealer.

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Crypto-DPAPI/Debug" application="Google Chrome"
| bin _time span=5m
| rename parent_process_id as process_id
| join type=inner process_id [search index=windows source=security_4688]
|`convert_time(_time)`
| table _time src_user parent_process_name process_name process_command

Splunk detection rule

Stealer execution

Now we’re pleased that we’ve detected suspicious behavior with a new EventCode. (Time difference is cause of TZ, my infrastructure is located in FR while I’m in HK :)) This EventCode doesn’t appear to be too verbose in my lab environment, but I’m unsure of its real impact in a production environment. So, proceed carefully and test thoroughly before making any decisions.

Happy Splunking!

Decoding HTTPS CONNECT in Proxy Environments

In this short article I'd like to talk about a mistake I often met during my work about HTTPS CONNECT request, especially in proxy setups like Zscaler.

1. Zscaler Agent’s Role

When using Zscaler, think of the agent as your secure internet guide. When you access an HTTPS site, the Zscaler agent sends a CONNECT request to the proxy, setting up a secure tunnel, not fetching content.

2. CONNECT Method Basics

The CONNECT method creates a tunnel for encrypted data. When you get a 200 OK response, it means the tunnel is ready for secure data transfer.

3. Common Misconceptions and Proxy Configurations

Analysts might mistake the lack of GET requests after a CONNECT for no connection. Actually, encrypted data is moving through the tunnel. Proxy visibility varies:

  • Standard Setup: Proxy forwards encrypted data.
  • SSL Inspection: With SSL inspection, proxies like Zscaler can decrypt, inspect, and re-encrypt traffic, offering more visibility.

Conclusion

A CONNECT request followed by a 200 OK response means a secure session is established. Understanding these secure channels helps interpret network logs accurately.

Resources

When to Use CONNECT and GET HTTP Methods at an HTTP Proxy Server

Web Proxy Tunneling (IETF Draft)