 That is the subtitle of the next talk. The next talk will be provided to you by two pen testers who have done pen testing for five years and who experienced that a lot of time they are not detected. This is the question why they are not detected and they want to show you some easy kinds of how to detect them next time. The talk is detecting bridge from an attacker's perspective and the speakers are Rick Van Daun and Wesley Nailen. Please give them a round of applause. Is mine working? Mine is working, but his isn't. Sorry? Do you want to hear my phone? Have you tried turning it on and off again? Is that it? Yes, yes. Is it working now? Yes, it's working. Great. Welcome to our talk, detecting a bridge from an attacker's perspective. Like mentioned, we are penetration testers, so probably we are going to regret this because in a lot of tests we are undetected and we think with the techniques we could be trapped and detected during our engagements. We are offensive guys. We have around five years experience penetration testing. We are OSCP and OSCE certified. We are currently working on OSCE. It's Advanced Exploitation Certification from Offensive Security. We are working for a defense company named Derbytes. Like mentioned, we are penetration testing a lot of companies and most of the time we are unnoticed. So we are wondering how is that possible? We are also members of HoneNet. This is a group of people that likes HonePot and are working on that. Okay, short introduction. As pen testers, we notice we don't get detected a lot. And what we do notice is that lots and lots of companies own a seam or an IDS. Hooking up that IDS to the internet directly. Making sure you have like a nice big tree of alerts. Lots and lots of data. Lots and lots of alerts. And this makes it hard to know when you are actually being reached or when just a simple scan is being performed on your external range. This makes it hard to even know and to discern between a human attacker and an automated attack or just like simple ransomware within your network. To us, we think there is a need to have a clear indicators of an internal breach. These indicators are a last resort. A last trick you can have in order to know that you have been breached. Please note that this means if these indicators go off, this means that somebody is already inside of your network and most likely has either high privileges on systems or network level access. We are also mapping our traps against hacks that already happened. For example, the hacking team, they were breached using a zero day on the router and he packaged a special package for the router and then he was able to end up and to run responder on the network. So he was enumerating the network using NMAP from that router where he came in. He found the iScusi backup drive and he was able to mount it and he was able to dump the credentials of a VMDK that was available on that iScusi drive. With the credentials extracted from that VMDK, he was able to compromise a live system, a exchange server. Again, on that server, he was able to extract credentials from the memory using Mimikatz. After that, he extracted a lot of data, for example, exchange mailboxes. Next to the hacking team hack, we have the Diginotar hack. For all Dutch people, this must be a familiar scenario. Diginotar was a company selling certificates and sell certificates and they were breached via an outdated installation of .NET Nuke and after the breach, the attacker had to look around. He had to figure out where he could go from there. So what he did was investigate the DMZ where the web server was running but next to this, he inspected the configuration of the web server. This showed a connection to a database server in the internal network running MSSQL. Some of you may know that MSSQL in default configuration, the old one, not the current one, allows you to perform xpay command shell which essentially allows you to do SQL queries that execute system commands. This allowed him to pivot his way from the DMZ to the internal network after which he gained domain and credentials, possibly via pwdump or mimicats. According to his own write-up on basebin, he took one month of pivoting through various networks in order to gain access to the signing network. During this month, he had to attack various systems, had to identify running systems, so making lots and lots of noise. This made us wonder, next to all the pentests we did, why are companies that should know better and should be able to detect the breach, are not detecting breaches, how could they have been hacked for such a long time without actually noticing? And actually, this made us say the famous words, how hard can it be? So we are going to look at it from an attacker's perspective. We ask ourselves some questions, how do we catch ourselves? Because we are doing similar things every time, like scanning the network. What steps do we take during a pentest? And how do we detect this behavior? And yeah, we concluded that it's important to not detect the tools, but to detect the end goal of an attacker. For example, if you have an important machine within your network, then it's great to create a trap which detects whenever that system is attacked. So a short disclaimer, this talks about the way of thinking, not about the tools. There are tools available like Open Canary and Tripwire, so we advise you to use such tools. These are just a couple of examples, they won't save you. They are an addition to your existing monitoring or a new way of thinking of implementing your current monitoring. And we hope to inspire you all to look differently towards defending your network and to maybe take into account the offensive approach an attacker would take instead of hoarding large amounts of data and then afterwards trying to figure out what to look at in order to detect the breach. One advice I can give you all, honey all the things, it will help you. Regular old honey pots in a network will be touched by asset management tooling, stuff like that. However, once you try and filter out all the background noise which shouldn't be that much, it will allow you to detect interesting things. So we have split up our honey pots in two topics, the passive and the active honey pots. The passive honey pots are just waiting to be touched, for example. One very simple trick we've made is an internal poor scan detector. This is just a simple script that monitors to check whether the system is touched in any way. Very systems can already do this, of course, but these are not single-purpose systems and they are trying to filter out the false positives. So you might miss some scans. For example, if an attacker performs a slow scan, yeah, maybe it's not detected. For example, in the hacking team hack, he performed a slow scan to try to avoid being detected. Yeah, attackers need to know what they can attack so we can explore this by just simply monitoring on that. So we have created a poor scan detector. This is just only a system which is waiting to be touched. It's doing nothing else and you can keep it simple. For example, this one-liner T-speeder, you can use it to monitor whether your system is touched or not and then you can get a warning, for example. I've created a video of this. First you will see an NMOP scan which is performed on our honeypot and this is the honeypot that detects the poor scan. Every poor that is touched is displayed over here and you can make a notification of that. This is again the NMOP results. We've also created IP tables forwarding so every request is forwarded to another system so it looks even real but at least we know that the system is touched. We've also created a program that increases the attack area of this. It is possible to assign multiple virtual interfaces that allow you to assign static IP addresses in multiple segments for example the DMZ and the internal network. You can specify DSP addresses, for example I want 10 days CP but you can also assign it static. This improves the simple poor scan detector. It is now listening on all those interfaces. As you can see here it is the same output as from the video but now it is on different IP addresses so you can use the single system to put it in multiple segments. It is just a system that is hanging into your network but you can make it look even more real. For example you can give it an interesting name like DC02, PV store, super secret, whatever. What is interesting in your company? You can add DNS records in your network for that. You can add it to multiple subnets and for example I would place one in DMZ, one in the internal network and whenever the poor scan detector is touched within your DMZ it is strange because there are no systems that need to be touching that system. To make it even more real you can also add it to Active Directory because a lot of systems in a network will be. We created a wide list functionality for example if some systems are allowed to scan it automatically then you can wide list those that no notification will be sent. Another way attackers try and pivot their way through your network is by gaining higher privileges than they have. For example after a regular fish attackers would look through that local system and look through the network drives in order to find interesting credentials or other information to gain higher privileges and be able to pivot their way through the network. By playing in on this, by salting your network with fake credentials you are essentially giving them what they want in a controlled environment obviously and thereby you would be able to detect them. A tool like Mimikatz allows you to retrieve Windows credentials from memory. There are some APT groups that use their own tooling for this however they all try and read the memory of the LSAS process in order to dump credentials. Well you can actually implement this fairly easily. The one-liner run as not only allows you to spawn a notepad process with these credentials and the not only flag will allow you to spawn it with fake credentials since it only works for a network doesn't check locally. From my perspective when I'm doing a pentest and I find like existing domain of credentials this is a happy moment for me because I'm probably finally able to attack that server gain access to the domain control or whatever so imagine finally after spending a day three days five days finally finding your creds and then all of a sudden all the alerts go off. This would suck. I created a PowerShell script that actually does this. It's a modification of invoke run as by Marta Bone. However this is just Mimikatz running. It's dumping credentials regular old user offset lab noob lab nothing special going on. After this I use the invoke run as script which allows you to specify a username domain name and the password. After you run this I'm filling in admin user steal my creds but you can make it a bit more believable obviously. With the prod admin password and now it's spawned a conhost process hidden conhost process that contains these or at least that uses these credentials and after this you can see the the admin user steal my creds with the prod admin credentials are reside in memory. If this and it's important to actually okay wait back. This is funny it's nice to have however if you are attacking a network and you find like credentials you'll probably want to check if these are those are actually in existence so every domain joined PC would be able to query the Active Directory and check if the user exists. So it's important to actually create a legitimate domain admin account with a very difficult password and you all agree on not using that account. Then you spread around the fake credentials so the moment that an attacker gains access to those credentials for memory and checks in the Active Directory if the account is in existence active and is allowed to log on he will probably use it because it's very difficult from then on to determine if the account is actually fake or not. However do not put in the something in the description like fake horny account. The description is also readable for the same users. Another nice monitoring feature is for a web server is there's a web route and whenever a file is created in that web route for example there's something going on if it's not an update or something expected and we have created there was created the tool which allows you to monitor the web route. It's available on github and what it's doing is remotely logging in through SSH and then it's making just some of all the existing files and whenever a change is detected so it's pulling every 30 minutes whenever a change is detected a new file a modified file or deleted file then the alert goes out. Yeah remote integrity tools available on github it allows you to send multiple notifications for example email but also it's possible to send telegram messages this is for example on my blog. Yeah I run an update and then yeah I get a message from the telegram board that new files are created. This is expected but whenever this is not expected yeah a attacker might have uploaded the shell to your web server so it's time to act. Well we also developed some active honipods so these are trying to actively lure the attacker into your trap and one of those things when performing a pentast you can use for example netstop the output of that to see what existing connections are present on the system so that can be interesting to pivot into the network and attack those systems then you don't have to run an nmap scan so you will not be detected by the port scan detector but still you have some knowledge about the network. So you can do this but we can also yeah salt this netstop output and for example it's interesting when you put msql into it because yeah it's interesting because you can use xp command shell to pivot further into the network so the following screen shows an example this is a netstop output of the system and you'll see that my sql connection is active but this is actually our script creating a fake connection so this could lure an attacker into the trap to connect to that system and that will be our honipod and whenever it starts we get the notification. So another well obviously popular red teaming trick is using responder. Responder allows you to directly interact with broadcast traffic of LLMNR and MB&S and what they do is they they are old windows tricks in order to broadcast or to do name resolution of systems. The responder was also used during the hacking team attack and the interesting thing here was they only use the analyzed part so they only looked at broadcasts so you can use these broadcasts against an attacker. Responder is quite loud it responds to any broadcast you do unless you specify otherwise and we can take advantage of this by just plainly shouting back. So the moment somebody is trying to perform responder on your internal network and you have this running you'd be able to check out and figure out where they are running it from or where they are trying to send you later on. So I made a tool that just sends out LLMNR queries and MB&S queries onto the network so it's just running the entire time it's broadcasting the moment you start responder it already detected one of the touch to be burned long manager queries and after this it starts doing MB&S as well and you can see it's coming from there and it's pointing to that system so it's trying to get my system to connect to one of to their system in order to force like windows authentication or something like that. Obviously the name isn't that cleverly chosen but this is just as a proof of concept you could also do just not existing systems within your internal network by broadcasting those it will allow you to figure out once somebody is just responding to anything you send out there. Well these are some of our some of our tricks and we would like to go back to the initial breaches of hacking team and diginota breach in order to see if we could map those on the attack so step by step and look if we would be able to detect breaches like this using our simple tricks. So let's go to the hacking team so he came in through that zero day on the router and started end mapping the network he started the slow end map so if your the port scan detector was over there he probably touched that server and then an alarm goes out and someone is on your network so that would be great point to detect simply did with a simple detection mechanism to detect the attacker. Also he connected to a NOS network error storage and that contain the VMDK with credentials he was able to dump the that those credentials a local admin. You could solve those as well so it's not only limited to put fake users into the memory but you could also put yeah fake local users and whenever you use those users you could detect that they are used and that something is compromised. After gaining credentials from that VMDK he was able to log on to the exchange server. He used Mimicats to get yeah passwords out of the memory and he was able to obtain domain admin credentials. You could also put fake domain admin credentials in there and whenever that user is used yeah something is going on because who will get the those credentials those fake credentials from the memory that would be an attacker. After gaining access to the exchange server he got access to Christian posies laptop and there was a true kept container mounted with fake passwords in the HITL-TXT yeah you could also put fake credentials in there so there are a lot of layers where you are able to detect them. Using the Christian posies information he was able to get in the developer's LAN it's a segment. Also he was scanning that network so there again the port scan detector would be would be triggering so multiple layers it's possible to detect the attacker and at least you are already compromised but at least you know that you are compromised. So trying to map these on the Diginotar breach well the .NET Nuke web server was compromised so if you would have been able to monitor the the web route you would have you've been notified of changes to files or additional files being added. Well obviously it's not a clear indication but it's a it's a point of you can start by contacting your web admin asking if they have done some modifications to the website if not well try and look at that to see what's happening. After gaining access to the initial web server connections to MS SQL within the office LAN were made as well as internal checks to see if there were interesting systems within the DMG. Let's say you add like a Honnipod the port scan detector to your DMG it's not accessible from the internet it's not accessible from your internal network. The moment a system starts like let's say your web server starts port scanning your internal DMG it's a well it's at least something to look at but to me it's a it's an oh shit moment. Coming from the the web server he was able to compromise a database server within the office LAN well the fake MS SQL connections could have also worked here or faking other connections. Next to that obviously salting the system with fake information or credentials. After a long while he was able to gain access to the secure the signing network which is also an interesting environment to put in Honnipod since these are well obviously should be silent networks not not a lot of traffic there. So this is our presentation. Are there any questions? So Rick and Wesley. Thank you. Yes if there are questions line up at the microphone please. I think it was very good insight into a word that well maybe some of us don't know so good well so well if there are no questions. And I would say thank you. Thank you. Thank you.