Skip to content

HoHo... No⚓︎

Elf: Eve Snowshoes
Direct link: hohono terminal
Objective: Kerberoasting on an Open Fire


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?


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
* You can also remove an IP with naughtylist del <ip>
        /root/naughtylist del
* 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!


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.


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.

Fail2Ban configuraton

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.

Log analysis

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.


failregex = <HOST> sent a malformed request
            Login from <HOST> rejected due to unknown user name
            Failed login from <HOST> for .*
            Invalid heartbeat .* from <HOST>

Running fail2ban-regex /var/log/hohono.log /etc/fail2ban/filter.d/hohono.conf validates our custom filter definition.

Check regex

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.


actionban = /root/naughtylist add <ip>
actionunban = /root/naughtylist del <ip>

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).


enabled = true
filter = hohono
action = hohono
logpath = /var/log/hohono.log
bantime = 86400  # 1 day (in seconds)
findtime = 3600  # 1 hour (in seconds)
maxretry = 10

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.

Service restart

The final step is to use /root/naughtylist refresh to force Fail2Ban to rescan the /var/log/hohono.log log file.



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.