We recently teamed up with Ty Miller, director and founder of specialist pen testing and strategic security consultancy Threat Intelligence (TI), for a webcast on advanced pen testing techniques, including the DNS Channel and attacking Windows systems using WMI. Ty and Core's technical guru, Alberto Soliño, explained and illustrated some of the attack technologies currently being used to exfiltrate data from organizations and maintain persistency inside a network. Cool stuff!
Q: What is a prevention or detection for WMI attacks?
A: First, you should find out if you need WMI within your Windows infrastructure. If not, you have two options. On each system, you can:
- Disable the Windows Management Instrumentation (WMI) service. Stopping it will not be enough however; you have to explicitly disable it. This option is extreme and may cause some other issues, since some tasks may need WMI locally.
- Enable Firewall Rules to block WinRM and DCOM Ports. There is also a Firewall rule specific for WMI (look for Windows Management Instrumentation in the Firewall's inbound rules). This is the preferred method, since it doesn't break existing WMI functionality that may be running locally.
In terms of detection, enabling WMI logging may help spotting specific attacks. First, enable Analytic and Debug View in the event viewer and enable logging for Microsoft/Windows/WMI-Activity/Trace.
Q: How can you overcome the Privilege Escalation problem using wmic?
A: If you refer to the ability to use WMI through wmic.exe to gather system's data that could be use to perform EoP (e.g. weak services permissions): wmic.exe runs in the context of the user. Everything that can be requested with wmic.exe means there are explicit permissions for the user running it (e.g. listing services, users, etc). The drawback (or benefit for the attacker) is wmic.exe is fairly easy to use. But at the end, an attacker could manage to get that data outside wmic.
Q: What is Impacket?
A: Impacket is a library we developed aimed at crafting packets for the different OSI Layers. It is extensively used inside Core Impact Pro for different tasks ranging from the TCP Port Scanner (since we can create raw TCP packets) up to talking to a WMI Service, through DCOM, under a Kerberos authentication. The benefit of this library (and the main driver for us to develop it) is it is completely developed in Python, which allow us to use this library's capabilities when pivoting through different systems inside Core Impact Pro. It worth mentioning we open sourced this library and are always adding new functionality.
Q: Where are the EventsConsumer/EventFilter, etc. stored?
A: Everything is stored in the WMI database. It is usually located at %systemroot%\system32\wbem\repository. If not, check the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Installation Directory
Q: What protocol on the network does the WMI activity use? Kerberos or? What does that traffic look like?
A: WMI Traffic uses DCOM or WinRM. DCOM sits of top of DCE-RPC. You will see DCE-RPC traffic while sniffing WMI connections. Check this Wireshark page that includes a link to Sample Captures (look for DCE RPC there): https://wiki.wireshark.org/DCOM
Q: Are any current next generation firewalls tending to see/trigger on the excessive DNS traffic from a compromised host? Does the DNS tunneling use any DNS queries/responses outside of the RFC?
A: NGFWs and IPS appliances often have DNS tunneling detection capabilities. The effectiveness of these detection mechanisms depends upon their implementation. Detection for DNS Tunneling may be bypassed using a number of techniques including slowing down the DNS requests to avoid exceeding thresholds, randomizing the size of the DNS requests to avoid signatures looking for large DNS requests, and potentially using other encoding techniques than Base32. The DNS Tunneling in Core Impact Pro all comply with the RFC specifications. This is why Wireshark in the demonstration was able to successfully parse and display the DNS Tunneling packets.
Q: Is the DNS tunnel slower than a standard connection?
A: The short answer is yes. DNS Tunneling has traditionally been performed over UDP, which is very slow. However, as far as we are aware, the DNS Channel in Core Impact Pro is the first implementation to use DNS over TCP for tunneling. This means that instead of requiring around 600 DNS requests to download the Impact agent that takes minutes, we are able to download it in 3 requests that dramatically increase the speed of the DNS Tunnel to deploy the agent in seconds. The DNS Channel also has a fall back mechanism built in so that if DNS over TCP is not available then it will then use DNS over UDP.
Q: Could you provide pointers on how to setup back end DNS server to capture and pass traffic?
A: I'm not sure exactly what this is asking; however, the demonstration was using Wireshark on the Core Impact Pro system to capture the DNS traffic. If this is referring to the internal DNS server, then most of them by default are configured to pass the DNS traffic through as a standard implementation.
Q: For the DNS exfil example, it looks like Impact used a combination of TXT records (in the beginning) and A records following the delivery of the agent. If an organization blocks TXT records outbound from workstations, will this stop the agent from being deployed?
A: DNS Tunneling uses TXT records to download data and A records to upload data. This technique is used throughout the agent installation as well as the ongoing communications. If you block TXT records, yes you will break the DNS Channel communications. However, this will break other functionality throughout the organization that require DNS TXT records, such as SMTP servers looking up SPF details via TXT records. The better approach is to implement a Split DNS architecture.
Q: DNS Tunnel - is the encoded data that's passed over DNS encrypted?
A: Core Impact Pro offers the functionality to encrypt the communications-out of the box. You can disable it if you want through Tools->Options->Agents->Use encrypted channel for agents.
Q: Can we get this mitigation method in written form?
A: The best approach to prevent DNS Tunneling is to implement Split DNS. This is where the hosts on your internal network, including your internal DNS server, are not able to resolve any external domain names. This means that you don't actually allow ports 53/TCP and 53/UDP outbound through your internal firewalls. Your internal DNS server is purely used for resolving internal host names. In order to use DNS, systems like web proxies and SMTP mail relays are placed in the DMZ where an external DNS relay server exists that is allowed to resolve external domain names. So when workstations wish to access a web page or send an email, they send the HTTP request or SMTP traffic to the DMZ web proxy and mail relay, respectively. The web proxy and mail relay then perform the DNS lookup via the DMZ DNS relay in order to resolve external domains. This means that the DNS communications is severed between the workstations and the Internet, which breaks the two-way DNS traffic and prevents DNS Tunneling.
Q: Which is just an architectural design – Internal dns-->dmz dns--> external? Correct?
A: This is an architectural design; however, the setup described here is one that is vulnerable to DNS Tunneling and is a very common setup. A Split DNS architecture severs the DNS traffic between the internal DNS server and the DMZ DNS server to prevent internal machines from resolving external domains. In order to resolve domain names, workstations use proxy servers and mail servers in the DMZ that then do the DNS lookup via the DMZ DNS relay.
Q: DNS Tunnel - is the encoded data that's passed over DNS encrypted?
A: Core Impact Pro offers the functionality to encrypt the communications; out of the box. You can disable it if you want through Tools->Options->Agents->Use encrypted channel for agents.
Q: Can DNS tunneling be done on HTTPS?
A: HTTPS and DNS are different protocols, so the short answer is no. The longer answer is that it would be possible to force an HTTP/S proxy to send outbound DNS requests to exfiltrate data; however, this would be a one-way DNS Channel and would not provide remote control over an internal system via DNS.
Q: Can you please explain why proxying requests for external name resolution prevents DNS tunneling. If you send the proxy a legitimate DNS packet which contains the malicious payload won't you end up with the return DNS packet in the same way as you would a normal recursive resolution call that goes through your internal DNS server?
A: When your browser is configured to use a proxy, your browser doesn't perform the DNS lookup of the domain. Instead it sends the HTTP request to the proxy, which parses out the HTTP "Host" header that contains the domain that your browser wants to connect to. The proxy then performs the DNS lookup and gets the DNS response. This DNS response is never returned back to the web browser or the corresponding workstation, which prevents a two-way DNS tunnel from being possible from the workstation.