BlogMaintaining IT security has indeed become everyone's business and as a consequence people with all levels of IT background are trying their hand at various forms of open-source/commercial scripting and tooling. It's probably one of the most intuitive ways to start getting into an attacker's mindset and learning how to protect your critical assets more effectively. One such way is to deploy honeypots – either for research or in production.
While there are conflicting opinions on whether deploying honeypots should be a standard security practice for enterprises, the truth is they can be quite valuable for learning more about attackers, and can complement IDS and network traffic analysis solutions like Reveal(x).
Deploying honeypots in production environments does require considerable planning around network access management, which should be just lax enough to lure an attacker but not so lax as to actually put your legitimate assets at risk. Furthermore, managing and maintaining these additional assets enterprise-wide presents its own challenges with the top SANS CIS control, "asset inventory and tracking." As a consequence of this I have lately had a lot of customers ask me, "What can Reveal(x) do about detecting honeypots?"
Since honeypots should ideally be indistinguishable from legit servers, internal or internet-facing honeypots owned by an enterprise will be treated by Reveal(x) like any other critical asset in your environment. Reveal(x) will still extract the same 5,000+ metrics across 50+ protocols for these assets and will fire detections when it sees these assets behave abnormally. So classic behavioral anomalies like scanning attempts, brute force attempts, new connections, privilege escalation, potential exfiltration attempts etc. will be picked up by the Reveal(x) ML engine and associated to the relevant asset (honeypot).
However, this workflow is now further solidified with our new support of "complex device groups" in 7.5. This will allow users to set up a "honeypots" specific group within our UI to allow users to pay more attention to suspicious activities associated with the real time traffic of these specific assets as an early indicator of attack. One can now use a combination of criteria to dynamically tag these honeypot systems and keep them separated from other assets of the same type to avoid their signals getting merged with other mainstream devices. This flexibile grouping of assets will help augment already available honeypot logs with specific network behavioral symptoms seen by Reveal(x) on the wire when these specific systems are indeed accessed.
Interestingly enough, I was working with one customer recently where Reveal(x) picked up a detection that was associated with a server that turned out to be a honeypot. At our first glance, this surfaced as an abnormal DNS tunneling activity detection associated with an internal asset in their environment. Looking closely at the detection card gave us a lot of details related to why this specific behavior was worth investigating.
As you can see in the screenshot of this detection card it is claiming that DNS tunneling could be related to a client communicating with a command and control server. What was interesting to note here was the domain linked to this detection. This domain actually belonged to a known honeypot software:
Potential DNS Tunneling Alert
At this point there are several directions you can take as a SoC analyst. Some are:
- Validate whether this honeypot is owned by your organization: Our customer was able to confirm that this system was part of an old blue team evaluation that they weren't aware was still running.
- Launch an activity map to see what peers this device is talking to and validate if any other abnormalities have been seen on this node (or its peers).
- Look at the DNS Tunnel traffic more closely to see if anything looks suspicious.
The activity map did show some additional ping scans originating from the same node, which further validates the abnormality in this node's behavior:
Honeypot Activity Map
Looking at the DNS traffic closely—especially at the DNS TXT records—one can clearly confirm the encoded data being sent in the DNS messages and can potentially even decode it. However, further investigation revealed that this honeypot was using these DNS TXT messages to communicate with its console:
Honeypot DNS TXT Records
Using this data and some additional historical data points about the traffic associated with this server on the ExtraHop, the customer was able to conclusively prove the existence of an unaccounted-for honeypot in their environment that was still live.
There are many situations like pen tests, product evaluations and audit exercises where such assets are sometimes spun up for a specific problem but later forgotten. Any "legacy" or orphaned assets create risk as they are not maintained and can become vulnerable. In this situation, the authoritative visibility presented by ExtraHop's network traffic analysis highlighted a decommissioned asset that classic scanning and CMDB modes of asset tracking did not.
ExtraHop's approach also protects also you in forensic situations where a sophisticated attacker has recognized the honeypot and managed to destroy its logs. Because wire data cannot be compromised or altered, Reveal(x) will still allow you to go back in time and observe communications to and from the honeypot server to aid with investigations.
While there are many situations where Reveal(x) will help you with active threat hunting and maintaining security hygiene, this was a classic use case where ExtraHop's passive and always-on approach helped our customer validate the communications in their environment, complementing their existing security landscape of honeypots and IDS solutions.
