Attacking FreeIPA — Part III: Finding A Path
This post is Part III in a series about my experiences attacking FreeIPA. In Part I of this series, we reviewed some of the background and underlying technologies utilized by FreeIPA. We also discussed several authentication mechanisms, and forms of credential material, specifically how to identify, parse, and re-use credentials as an attacker. In Part II of this series we discussed the various different types of objects inside of a FreeIPA environment, and a little bit about their significance, as well as how these objects can be enumerated to obtain situational awareness.
If you haven’t read the first two parts of the series you can find them here:
Lab Environment
Before we dive into our attack path, let’s briefly review the lab environment we will be operating in. If you want to follow along I have released a post detailing how you can configure your own FreeIPA lab to follow along with this series, or even conduct your own research. You can find that post here:

Once the lab is configured and created we can get started. Our starting point in this exercise will be ceded access to a compromised web server inside the managed FreeIPA environment. This access will be ceded through the Apfell C2 platform utilizing the Poseidon agent. The goal is to ultimately obtain an admin credential for the domain, and exfiltrate sensitive data from the SQL Database.
Attack Path
Given our ceded access we now need to start conducting some basic enumeration. For the purpose of this post I will only be focusing on the FreeIPA aspects of host enumeration, but inside of a real environment you will likely need to perform more comprehensive enumeration than shown in this post.
So with our initial access my first step is to identify which user context I am currently in, and what permissions that user context holds.

After obtaining access to the compromised web server, we identified that we are currently inside of the “nginxadmin” user context. The ipa management utility is also present at its default location: /usr/bin/ipa and finally, there are some tickets stored in /tmp/ one of which is readable by our user. Let’s check its validity and apply it to our Poseidon callback.

With this ticket imported into our agent, we can begin to enumerate the permissions associated with the “nginxadmin” account.

Based on the output above we can identify both a Sudo Rule and HBAC Rule that are applied to this account. Sudo Rules can be used to restrict or delegate the ability to execute commands as sudo on hosts enrolled in the domain. HBAC Rules are used to delegate access to specific resources. Let’s grab more information about both the Sudo Rule and the HBAC Rule.


Reviewing the “Web-Admin” HBAC Rule shows us that “nginxadmin” has access to all services on both “mysql.westeros.local” and “web.westeros.local”. This means that we should be able to utilize SSH and SCP with a valid TGT for “nginxadmin”.
The “Web-Sudo” Sudo Rule shows us that “nginxadmin” has the ability to run sudo as any user or group and for any command. This rule is applied to both “mysql.westeros.local”, and “web.westeros.local”.
Between the HBAC Rule and the Sudo Rule “nginxadmin” should be able to both authenticate to “mysql.westeros.local” and execute commands as root via sudo.


Access to mysql.westeros.local accomplishes the objective to obtain access to a sensitive database. But let’s attempt to extend access to control of the FreeIPA domain. A quick listing of /tmp/ identifies two kerberos CCACHE TGT’s. We can attempt to enumerate these tickets with our sudo privileges.


In FreeIPA the “admin” account is roughly equivalent to a “Domain Admin” account in traditional active directory. Listing its permissions and user attributes show that it is a member of the “admins” and “trust admins” groups as well as several Sudo Rules and HBAC Rulesets.

With sudo privileges, we can obtain access to this account by creating a copy of the existing ticket, and modifying the permissions so our current user context can utilize it. It is also possible to utilize sudo to establish another agent in the root context, removing the requirement to copy or modify permissions of the ticket.


With these new permissions it should be possible to move laterally to any host inside the environment. Let’s test out this theory by obtaining an agent on “vault.westeros.local”.


Conclusion
Despite this lab environment being a small and slightly contrived example of production FreeIPA environment, it effectively demonstrates how to enumerate permissions and utilize those permissions to conduct lateral movement. Hopefully by now we have a slightly better understanding of how to apply some of our prior knowledge about FreeIPA in an offensive context.
In the final post of this series I will aim to cover the following:
References
- Defining Host-Based Access control Rules, Fedora, https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/hbac-rules.html
- Defining Sudo-Rules, Fedora, https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/defining-sudorules.html
- Docker, FreeIPA, https://www.freeipa.org/page/Docker
- FreeIPA Container, Github, https://github.com/freeipa/freeipa-container
- FreeIPA Server, DockerHub, https://hub.docker.com/r/freeipa/freeipa-server/
- MIT Kerberos Documentation, MIT, https://web.mit.edu/kerberos/krb5-latest/doc/