How to mitigate DCE/RPC and MSRPC Services Enumeration Reporting

[mstjohn1974]

I am running security and vulnerability scans against a few Windows Server and I cannot figure out how to resolve or mitigate DCE/RPC and MSRPC Services Enumeration Reporting issues. Here is the scan result slightly altered to protect my network:

Summary​

Distributed Computing Environment / Remote Procedure Calls (DCE/RPC) or MSRPC services running on the remote host can be enumerated by connecting on port 135 and doing the appropriate queries.

Detection Result​

Here is the list of DCE/RPC or MSRPC services running on this host via the TCP protocol:

Port: 49664/tcp

UUID: d95afe70-a6d5-4259-822e-2c84da1ddb0d, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49664]

Port: 49665/tcp

UUID: f6beaff7-1e19-4fbb-9f8f-b89e2018337c, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49665]
Annotation: Event log TCPIP

Port: 49667/tcp

UUID: 0b1c2170-5732-4e0e-8cd3-d9b16f3b84d7, version 0
Endpoint: ncacn_ip_tcp:192.168.100.7[49667]
Annotation: RemoteAccessCheck

UUID: 12345778-1234-abcd-ef00-0123456789ac, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49667]
Named pipe : lsass
Win32 service or process : lsass.exe
Description : SAM access

UUID: 51a227ae-825b-41f2-b4a9-1ac9557a1018, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49667]
Annotation: Ngc Pop Key Service

UUID: 8fb74744-b2ff-4c00-be0d-9ef9a191fe1b, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49667]
Annotation: Ngc Pop Key Service

UUID: b25a52bf-e5dd-4f4a-aea6-8ca7272a0e86, version 2
Endpoint: ncacn_ip_tcp:192.168.100.7[49667]
Annotation: KeyIso

Port: 49687/tcp

UUID: 0b6edbfa-4a24-4fc6-8a23-942b1eca65d1, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49687]

UUID: 12345678-1234-abcd-ef00-0123456789ab, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49687]
Named pipe : spoolss
Win32 service or process : spoolsv.exe
Description : Spooler service

UUID: 4a452661-8290-4b36-8fbe-7f4093a94978, version 1
Endpoint: ncacn_ip_tcp:192.168.1007[49687]

UUID: 76f03f96-cdfd-44fc-a22c-64950a001209, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49687]

UUID: ae33069b-a2a8-46ee-a235-ddfd339be281, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49687]

Port: 49691/tcp

UUID: 6b5bdd1e-528c-422c-af8c-a4079be4fe48, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49691]
Annotation: Remote Fw APIs

Port: 49692/tcp

UUID: 201ef99a-7fa0-444c-9399-19ba84f12a1a, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: AppInfo

UUID: 29770a8f-829b-4158-90a2-78cd488501f7, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]

UUID: 2e6035b2-e8f1-41a7-a044-656b439c4c34, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: Proxy Manager provider server endpoint

UUID: 3a9ef155-691d-4449-8d05-09ad57031823, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]

UUID: 552d076a-cb29-4e44-8b6a-d15e59e2c0af, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: IP Transition Configuration endpoint

UUID: 58e604e8-9adb-4d2e-a464-3b0683fb1480, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: AppInfo

UUID: 5f54ce7d-5b79-4175-8584-cb65313a0e98, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: AppInfo

UUID: 86d35949-83c9-4044-b424-db363231fd0c, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]

UUID: a398e520-d59a-4bdd-aa7a-3c1e0303a511, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: IKE/Authip API

UUID: c36be077-e14b-4fe9-8abc-e856ef4f048b, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: Proxy Manager client server endpoint

UUID: c49a5a70-8a7f-4e70-ba16-1e8f1f193ef1, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: Adh APIs

UUID: d09bdeb5-6171-4a34-bfe2-06fa82652568, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]

UUID: fb9a3757-cff0-4db0-b9fc-bd6c131612fd, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: AppInfo

UUID: fd7a0523-dc70-43dd-9b2e-9c5ed48225b1, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49692]
Annotation: AppInfo

Port: 49697/tcp

UUID: 12345778-1234-abcd-ef00-0123456789ac, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49697]
Named pipe : lsass
Win32 service or process : lsass.exe
Description : SAM access

UUID: 51a227ae-825b-41f2-b4a9-1ac9557a1018, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49697]
Annotation: Ngc Pop Key Service

UUID: 8fb74744-b2ff-4c00-be0d-9ef9a191fe1b, version 1
Endpoint: ncacn_ip_tcp:192.168.100.7[49697]
Annotation: Ngc Pop Key Service

UUID: b25a52bf-e5dd-4f4a-aea6-8ca7272a0e86, version 2
Endpoint: ncacn_ip_tcp:192.168.100.7[49697]
Annotation: KeyIso

Port: 49709/tcp

UUID: 367abb81-9844-35f1-ad32-98f038001003, version 2
Endpoint: ncacn_ip_tcp:192.168.100.7[49709]

Note: DCE/RPC or MSRPC services running on this host locally were identified. Reporting this list is not enabled by default due to the possible large size of this list. See the script preferences to enable this reporting.

Impact​

An attacker may use this fact to gain more knowledge about the remote host.

Solution​

Solution Type:
Mitigation
Filter incoming traffic to this ports

 

[Neemobeer]

Unless you have no critical, high or medium vulnerabilities in your environment and I doubt you have none. I wouldn't even bother with basic host info disclosure vulnerabilities.

 

[mstjohn1974]

Unless you have no critical, high or medium vulnerabilities in your environment and I doubt you have none. I wouldn't even bother with basic host info disclosure vulnerabilities.

Well, our Security Policy doesn't allow and Medium to High risk findings in the scans and unfortunately those are in the medium range. Does anyone knows how to resolve this?

 

[Neemobeer]

Seems unusual they would be mediums. The only fix is to enable a firewall to block the incoming connections. Since it's best practice to allow the scanner continued access to identify further vulnerabilities you will essentially never resolve them from the scanners POV. I would challenge the scoring with the vendor.

 

[mstjohn1974]

Seems unusual they would be mediums. The only fix is to enable a firewall to block the incoming connections. Since it's best practice to allow the scanner continued access to identify further vulnerabilities you will essentially never resolve them from the scanners POV. I would challenge the scoring with the vendor.

Well, then the firewall is already enabled.......I think I will mark to ignore this for now until my boss tells me otherwise. Thank you though for the explanation

 

[Neemobeer]

I would, any decent scanner will generally categorized them as info

 

[SchoolITMan]

I could be wrong, but IIRC, Active directory needs MSRPC for nodes joining the domain and pushing out GPO. So in AD, this can not be disabled. But as long as it is blocked from public access (ie: ports are blocked at the firewall) you should be ok. MSRPC uses port 135 and multiple random high ports to communicate. PLEASE correct me if I am wrong!

 

[Edgar Soto]

No deberías bloquear el puerto TCP 135, únicamente cerrar los puertos que indica el reporte y validar si el conjunto de puertos esta vinculado con un servicio.

Lee el documento adjunto.

Introducción a los servicios y requisitos de puerto de red para Windows - Windows Server

Una guía básica de los puertos, protocolos y servicios que, para funcionar en una red segmentada, necesitan los sistemas operativos cliente y servidor de Microsoft, así como las aplicaciones basadas en servidor y sus subcomponentes.

learn.microsoft.com

 

[Edgar Soto]

Estoy ejecutando análisis de seguridad y vulnerabilidades en algunos Windows Server y no puedo averiguar cómo resolver o mitigar los problemas de informes de enumeración de servicios DCE/RPC y MSRPC. Aquí está el resultado del escaneo ligeramente alterado para proteger mi red:

No deberías bloquear el puerto TCP 135, únicamente cerrar los puertos que indica el reporte y validar si el conjunto de puertos esta vinculado con un servicio.


Lee el documento adjunto.

Introducción a los servicios y requisitos de puerto de red para Windows - Windows Server

Una guía básica de los puertos, protocolos y servicios que, para funcionar en una red segmentada, necesitan los sistemas operativos cliente y servidor de Microsoft, así como las aplicaciones basadas en servidor y sus subcomponentes.

learn.microsoft.com

 

[Edgar Soto]

Podría estar equivocado, pero IIRC, Active Directory necesita MSRPC para los nodos que se unen al dominio y expulsan GPO. Entonces, en AD, esto no se puede deshabilitar. Pero mientras esté bloqueado del acceso público (es decir: los puertos están bloqueados en el firewall) debería estar bien. MSRPC utiliza el puerto 135 y varios puertos altos aleatorios para comunicarse. ¡POR FAVOR corrígeme si me equivoco!

No deberías bloquear el puerto TCP 135, únicamente cerrar los puertos que indica el reporte y validar si el conjunto de puertos esta vinculado con un servicio.

Lee el documento adjunto.

Introducción a los servicios y requisitos de puerto de red para Windows - Windows Server

Una guía básica de los puertos, protocolos y servicios que, para funcionar en una red segmentada, necesitan los sistemas operativos cliente y servidor de Microsoft, así como las aplicaciones basadas en servidor y sus subcomponentes.

learn.microsoft.com

 

[Edgar Soto]

A menos que no tenga vulnerabilidades críticas, altas o medias en su entorno y dudo que no tenga ninguna. Ni siquiera me molestaría con las vulnerabilidades básicas de divulgación de información del host.

Lo dudo, ve el siguiente video del como es faciul vulnerar estos puertos.

 

[Neemobeer]

Well yes, nothing is 100% secure and RPC can be attacked, but you would have to have a foothold in the network to do much damage, and if an attacker has a foothold in your network you clearly have bigger concerns.

Trying to remediate every finding on every system is both unrealistic and depending on your network size likely impossible. Security experts running vulnerability programs take a risk-based approach to their TVM programs and will always focus on the higher-risk CVEs. Trying to fix info findings is mostly pointless as many systems rely on these ports being open. It's called risk acceptance.

 

[Edgar Soto]

Well yes, nothing is 100% secure and RPC can be attacked, but you would have to have a foothold in the network to do much damage, and if an attacker has a foothold in your network you clearly have bigger concerns.

Trying to remediate every finding on every system is both unrealistic and depending on your network size likely impossible. Security experts running vulnerability programs take a risk-based approach to their TVM programs and will always focus on the higher-risk CVEs. Trying to fix info findings is mostly pointless as many systems rely on these ports being open. It's called risk acceptance.

El phishing es preocupante y como parte de los controles de estos hallazgos de puertos abiertos hay que hacer conciencia en ciberseguridad de la organización y principalmente quienes tienen acceso a perfiles con privilegios amplios en AD, AWS, Google cloud y Azure, es ahi donde los ataques ( MITRE ATTACK) estan al dia con vectores ataque laterales y no necesitas estar dentro de la red. los mismos usuarios dan ese acceso, por ello es un contról complementario dentro de la remediación de este riesgo.

 

[Neemobeer]

I don't disagree. Phishing will continue to be one of the top attack vectors. Good defense in depth will help reduce the risk and success of phishing though

 

[bashtonmcse]

We are running AlienVault in our environment and this issue is showing up on all of our servers since Port 135 needs to be open on the local domain for AD purposes as I understand it. I am trying to figure out what mitigation steps can be taken to reduce our risk to offset this issue as best we can. I know that we need to lock down the port on the external Internet Firewall. Does anyone know if this port at the member server level is used to communicate with workstations as well as domain controllers? I suspect the answer is yes for RPC purposes.

 

[Neemobeer]

Yes domain joined devices need RPC. Microsoft enforced some default security measures back in 2020.