At its core, the DCSO Threat Detection & Hunting (TDH) service uses network security monitoring to protect organizations against both targeted attacks by advanced threat actors and annoyances that are best described as “commodity” crime ware.
Network Security Monitoring requires tuning and verification
In our experience, simply adding passive security appliances to existing networks has limited benefits. This is especially true if there is no guarantee that the appliance can access all relevant traffic which may include activities caused by potential adversaries. Therefore, a common task that emerges after the TDH network sensors have been deployed at a customer’s site is to verify what traffic is seen by the sensor. Not only do we need to check whether any network traffic at all is being fed to the sensors but also whether it is the expected kind of traffic.
Some background Noise is useful
While performing the initial baselining and verification process at a recent deployment, colleagues encountered unexpected problems: Normally, one would expect to find a certain rate of events that we view as “background noise”, i.e. indicators pointing to singular commodity malware infections (e.g. Lokibot, Emotet), even if firewalls or other security products intercept the actual command&control traffic. At this customer’s site, the rate of “background noise” events was considerably lower than expected, given the number of active workstation endpoints and mobile devices. The reason, as it turned out, was that the customer was using a security middle-box installation which included endpoint agents that routed large portions of the traffic via a proprietary tunneling protocol. Little public information about the specifics of the tunneling protocol was available, so we decided to generate some traffic patterns from typical workstations within the customer’s network – hopefully we would be able to tell if our sensors were able to reliably detect those patterns. Performing those measurements from many different endpoints would require a considerable effort on the customer’s side, so an easy-to-use script or program that requires only few operating instructions and no interaction for running was key.
Mauerspecht: A free client/server tool by DCSO::Labs
This led to the development of Mauerspecht within DCSO::Labs with the aim of increasing the effectiveness of network security monitoring. Mauerspecht is a simple client/server tool that can be used to probe different aspects of internet connectivity in a not-well-known network. Server and client components exchange a number of pre-configured messages via HTTP, usually within a few seconds. Because the clear-text HTTP protocol is used, any network sensor on the path should be able to pick up the messages transmitted in the clear. The only information that needs to be passed to the client is the server address – all other configuration information is retrieved as an encrypted/obfuscated message at startup. Information about which messages were or were not successfully transmitted is also logged via encrypted/obfuscated messages.
Both server and client components are written in the Go programming language and can be easily built for and deployed on Windows, Linux, MacOSX, and other Unix operating systems.
In the end, using Mauerspecht, we were able to quickly verify that the tunneling protocol could actually be dissected by our sensors without further customization. We saved a lot of time by determining that in fact not all relevant traffic was being fed to our sensor.
Mauerspecht is free software, released under the GNU General Public License version 3 or later.