DNS Blackholes for Ransomware
DNS Blackholes for Ransomware
Ok – over in this post: https://allaboutcloud.info/blocking-ransomware-for-free-with-honeypots/ we talked about blocking ransomware attacks with honeypot files or folders, as opposed to the common approach of using FSRM to block known bad extensions (hint: that doesn’t work as well as you’d hope, in practice).
So now we’re going to extend the functionality we gained in that post by setting up the ability to black hole the location of where someone got that malware from. We can do this by hand or, if you’re feeling brave, by automation.
So if you check out the previous post about honeypots, you’ll see in our FSRM setup, we set this option on the File Screen Template:
So basically, this just logs the honeypot trigger to the event log (Application, EventID: 8125). Basically, it will look like this:
So here we see some really useful things. Firstly, we know who triggered the ransomware and what PC they’re on but more importantly (or equally, anyway) when know when they triggered it. In this case, at 22/6/18 11:17:01am (note, the event log shows the date in the user’s format, which for me is dd/mm/yy – but the log files themselves infuriatingly store them in US format of mm/dd/yyyy).
So we need a way to work out what the user did at that time – not just on their PC but what they spoke to, on the internet. Now, remember the point of all this is $0 budget ransomware protection – so we’re assuming the network has no detailed monitoring or none that you can access. So we need a Windows way of knowing where someone went at that time (what URL did they visit or link did they click, to trigger this ransomware).
We’re going to do this by using DNS Query Logging on our domain controllers. We set that up as follows:
- Open your DNS management snapin.
- Go to Properties of the DNS server itself (in our case, Muppet).
- Enable Debug Logging (Microsoft claims there is negligible performance impact here, so don’t worry).
- Technically, we don’t need to tick all of those – just the Queries/Transfers option.
- Set a location for the log. In this case, we’re using c:\dnslogs\dns.log – because it’s easy for me to find, for this blog.
The log file looks basically like this:
Blackholing the Malware Source
Ok, here’s how we can manually blackhole the source of the malware. We know the user was demo\demo.user and in our case, I know they’re on 192.168.0.98. I know the malware executed at 11:17am and I can make the assumption that the malware executed immediately on visiting the malicious site (because they usually do). So I can now go to powershell and issue the following command:
select-string -path c:\dnslogs\dns.log -pattern 192.168.0.98 | findstr "6/22/2018 11:17:01"
or some variant of that (you don’t need to be that specific with the time stamp – you could just limit it to 11:17 or even 11: if you want a bigger view window. We’ll see output like this:
There’s lots happening here, because my test VM is doing a Windows Update but that’s ok – we can look at the domains and see which ones are pretty unexpected. In my case, I wrote a basic malware test to come from “perthsectalks.com.au” – a fake domain I used for a talk at an event of a similar name. So we can go (safely) check that site out and work out that it is indeed where the malware came from.
Now we just go add a fake DNS forward zone in AD so no users can find that domain, and it’s blackholed:
We do that like this:
- Add a new zone
- Add this to all domain controllers
- Set the zone to our bad domain
- Leave it empty, so the entire domain is a black hole, until you can trust it again (if ever).
We’ve now prevented users from going to that domain – so the original user who clicked the malware or went to the malicious site triggered our honeypot – and we have now used information gained from that to stop the rest of the users falling for the same phishing expedition.