[EXT] Zeek DCE-RPC Analyzer Update

Development
1

Hi Gabriele,

Last year I did a deep-dive into the Zeek DCE-RPC protocol analyzer. I found the same un-used binpac file endpoint-atsvc.pac, and I had similar thoughts about developing analyzers for specific RPC data stubs. Unfortunately, so many RPC data stubs are encrypted by default now. Also, I realized I was able to make useful decisions from just knowing the RPC interface and method and then mapping that function to a threat model. Please see the github repository at the URL below. Also, I am giving a talk on it at ZeekWeek next month.

https://github.com/mitre-attack/bzar

Thanks,

Mark

2

Hi Mark,

I have already analyzed your project and I thank you for the excellent work.

The reasons why we are looking for something more are these:

  1. Currently analyzing the new techniques with DCOM we have noticed that neither the endpoints nor the operations have been included in the project.
  2. We have also noticed in the observed cases that the data stub is encrypted using ntlmssp authlevel packet privacy, this happened in the cases where dcerpc passed over pure through a specific rule on the local windows firewall. However this does not happen neither for the observed cases of DCOM (authlevel packet integrity), nor for the classic code execution dcerpc traffic passed through named pipes (atsvc, svcctl, winreg , […]) (authlevel connect), which are the easiest techniques to exploit with basic AD configuration. This type of traffic is legitimate and widely used in our networks, the content of the stub data in cleartext would help us both to filter the normal uses from the malicious ones and to greatly increase the quality of our analyzes.

Thanks,

Gabriele.

3

Hi Gabriele,

Thank you for the compliment on BZAR. I think it would be great if you were to create a parser for those data stubs. That would add a lot of value.

…nor for the classic code execution dcerpc traffic passed through

named pipes (atsvc, svcctl, winreg , […]) (authlevel connect), which

are the easiest techniques to exploit with basic AD configuration.

I am surprised those RPC interfaces are not encrypted. For example, the current MSDN documentation states the RPC authentication should be Level 6 (authlevel packet privacy) for atsvc, svcctl, and winreg, which would mean the data stubs would be encrypted. I didn’t investigate further to verify if that is true or not, or to find cases when it is not encrypted.

Thanks,

Mark

~WRD000.jpg

image002.jpg