Presented at
Still Hacking Anyway (SHA2017),
Aug. 5, 2017, 3:30 p.m.
(30 minutes)
Detecting a breach is hard, detecting someone who targets your network specifically is even harder. As pentesters, we notice that we often remain undetected and breaching an infrastructure via an external server generally goes unnoticed. However, indications of our breach could definitely have been picked up, we could have been detected. So, why weren’t we? This talk focusses on using simple detection mechanisms that detect specific post exploitation steps. We demonstrate simple tricks that can be used as a final warning mechanism. We choose to focus on the behaviour of an attacker and give them what they want. Is the attacker using Mimikatz? Give them (fake) credentials. Are they using Responder? Broadcast WPAD queries! Port scanning the network? Give them something to port scan! Design small traps from an attackers perspective to detect someone snooping around.
Modern companies have various detection systems and immense amounts of logging. Not every alarm can be followed up, there needs to be a proper justification before starting a full-scale investigation. Indications of an initial breach (exploit-kit/phishing/malspam) do not justify a full-scale investigation. However, indications of post exploitation directs you towards a more focussed investigation. Assuming you don’t have many indications of post exploitation ;).<b>
#NetworkSecurity
This talk is about detecting breaches with simple scripts, tricks and honey*. We improve regular techniques by making simple uni-tasking scripts that have a high reliability. Alerts from these scripts can be used to monitor and protect organisations. As pentesters we are often undetected, and these techniques will help you to detect us and (most likely) any other external attacker. To put it mildly: we’re gonna regret this.
Listeners to our talk will learn:
To think differently about detecting a breach.
Know It is important to understand the attackers approach. Knowing this approach allows you to create specific alarms to detect the attackers behaviour and/or hacking tools on your network with a low false-positive rating.
Detecting an attacker doesn’t have to be hard, it can be done using simple scripts and machines deployed on your network. This costs less time compared to existing detection tools that collects, and produces, huge amounts of information.
Simple detection mechanisms could be used to detect attacker-specific behaviour. This specific behaviour gives you a highly reliable indication of (potential) compromise. As an example: Imagine we have a webserver in the demilitarized zone (DMZ), and the hosted site contains a remote command execution (RCE) bug. Once the server has been compromised, the attacker must find a way into the internal network. If the local server does not contain any interesting data that allows for further compromise, the attacker needs to discover other systems on the network. At this point the attacker can either listen to broadcast traffic to detect systems, or can perform a portscan to identify systems and available services on the network. Having a honeypot running a simple script that detects a portscan, that is placed within the DMZ and only accessible from the DMZ, will give you a very reliable indication something is happening. Detecting a breach by Inspecting traffic that is sent to the web server from the internet is more difficult. Furthermore, external traffic will generate many alerts while only one or two alerts are actionable.
Inspirations for our detection mechanisms are derived from our pentest experience. We’ve looked at the steps we take once we gain access to a workstation or server. We’ve mapped our steps to figure out where we are most prone to detection. However, since pentesters work different from a motivated attacker, our detection techniques are also based on publicly available information about breaches like diginotar, gamma international, and hackingteam.
Presenters:
-
Wesley Neelen
Wesley Neelen, has over 5 years’ experience as a penetration tester with some additional experience in forensics. Wesley has an OSCP, OSCE, and is practicing for his OSEE certification. Wesley performed several hacking related forensic investigations.
-
Rik van Duijn
Currently working as a pentester, i've been a cook too. I like offense, squash and long walks on the beach. ps. <plaintext>
Rik van Duijn, has over 5 years’ experience as a penetration tester. His first real job was auditing webapplication source code for a Dutch bank. Rik holds the OSCP, OSCE certifications, and is currently practicing for the OSEE certification.
Links:
Similar Presentations: