HoHo... No⚓︎
Elf: Eve Snowshoes
Direct link: hohono terminal
Objective: Kerberoasting on an Open Fire
Request⚓︎
Eve Snowshoes
Hey there, how's it going? I'm Eve Snowshoes.
Lately I've been spending a lot of cycles worrying about what's going on next door.
Before that, I was checking out Fail2Ban.
It's this slick log scanning tool for Apache web servers.
If you can complete this terminal challenge, I'd be happy to give you some things I've learned about Kerberoasting and Active Directory permissions!
Why don't you do some work with Fail2Ban on this Cranberry Pi terminal first, then we'll talk Kerberoasting and Active Directory. OK?
Solution⚓︎
Welcome message
Jack is trying to break into Santa's workshop!
Santa's elves are working 24/7 to manually look through logs, identify the
malicious IP addresses, and block them. We need your help to automate this so
the elves can get back to making presents!
Can you configure Fail2Ban to detect and block the bad IPs?
* You must monitor for new log entries in /var/log/hohono.log
* If an IP generates 10 or more failure messages within an hour then it must
be added to the naughty list by running naughtylist add <ip>
/root/naughtylist add 12.34.56.78
* You can also remove an IP with naughtylist del <ip>
/root/naughtylist del 12.34.56.78
* You can check which IPs are currently on the naughty list by running
/root/naughtylist list
You'll be rewarded if you correctly identify all the malicious IPs with a
Fail2Ban filter in /etc/fail2ban/filter.d, an action to ban and unban in
/etc/fail2ban/action.d, and a custom jail in /etc/fail2ban/jail.d. Don't
add any nice IPs to the naughty list!
*** IMPORTANT NOTE! ***
Fail2Ban won't rescan any logs it has already seen. That means it won't
automatically process the log file each time you make changes to the Fail2Ban
config. When needed, run /root/naughtylist refresh to re-sample the log file
and tell Fail2Ban to reprocess it.
Introduction⚓︎
Andy Smith's KringleCon talk provides a great introduction to Fail2Ban and goes over all the steps required to set up your own custom configuration. In short, there's 3 config files we need to create: a filter, an action, and a jail which ties it all together.
Log analysis⚓︎
Before we start diving into config files though, we first need to analyze /var/log/hohono.log to understand what bad activity actually looks like. Lines containing Valid, successfully, and successful are obviously good and should be ignored. By filtering out the valid log entries using grep -v 'successful\|Valid' we're left with 4 distinct types of failure messages.
Filter configuration⚓︎
Now that we know what each failure message looks like we can configure Fail2Ban, starting with the /etc/fail2ban/filter.d/hohono.conf filter. This configuration file contains a series of regular expressions matching every possible failure message and uses placeholders like <HOST> to identify and extract the IP address responsible for the activity.
/etc/fail2ban/filter.d/hohono.conf
1 2 3 4 5 | |
Running fail2ban-regex /var/log/hohono.log /etc/fail2ban/filter.d/hohono.conf validates our custom filter definition.
Action configuration⚓︎
Next we create the /etc/fail2ban/action.d/hohono.conf action which instructs Fail2Ban what commands should be run to ban (line 2) and unban (line 3) an IP address. Just like we used <HOST> to identify and extract the IP address in the filter, we can use <ip> to automatically pass the correct IP address to the naughtylist command.
/etc/fail2ban/action.d/hohono.conf
1 2 3 | |
Jail configuration⚓︎
The final step to setting up Fail2Ban for our use case is to create an /etc/fail2ban/jail.d/hohono.conf jail which ties together our filter (line 3), action (line 4), /var/log/hohono.log (line 5), and a 10 failures per hour threshold (lines 7-8).
/etc/fail2ban/jail.d/hohono.conf
1 2 3 4 5 6 7 8 | |
Bring down the ban hammer!⚓︎
All the required configuration pieces are now in place. Restart the fail2Ban service using either /etc/init.d/fail2ban restart or service fail2ban restart and check that the hohono jail has been loaded by running fail2ban-client status hohono.
The final step is to use /root/naughtylist refresh to force Fail2Ban to rescan the /var/log/hohono.log log file.
Response⚓︎
Eve Snowshoes
Fantastic! Thanks for the help!
Hey, would you like to know more about Kerberoasting and Active Directory permissions abuse?
There's a great talk by Chris Davis on this exact subject!
There are also plenty of resources available to learn more about Kerberoasting specifically.
If you have any trouble finding a domain controller, remember that, when not running as root, nmap default probing relies on connecting to TCP 80 and 443.
Got a hash that won't crack with your wordlist? OneRuleToRuleThemAll.rule is a great way to grow your keyspace.
Where'd you get your wordlist? CeWL might generate a great wordlist from the ElfU website, but it will ignore digits in terms by default.
So, apropos of nothing, have you ever known system administrators who store credentials in scripts? I know, I know, you understand the folly and would never do it!
The easy way to investigate Active Directory misconfigurations (for Blue and Red alike!) is with Bloodhound, but there are native methods as well.
Oh, and one last thing: once you've granted permissions to your user, it might take up to five minutes for it to propogate throughout the domain.