Attacking FreeIPA — Part III: Finding A Path

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:

Diagram Detailing the Layout of the FreeIPA Lab Environment

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.

Identifying a valid kerberos CCACHE Ticket, and applying it to this session.

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

Utilizing IPA administrative tooling to review the user information for nginxadmin

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.

HBACRule delegating host accessSudo Rule delegating sudo access

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.

Copying Poseidon payload to mysql.westeros.local via scp, then executing itNew agent check-in for mysql.westeros.local demonstrating lateral movement

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.

Kerberos CCACHE Tickets are stored in /tmp/ by defaultKlist can be used to list the principals inside of specific tickets or in the current session

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.

User properties for the “admin” account in FreeIPA

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.

Spawning a new agent as rootSetting the KRB5CCNAME environment variable to instruct kerberos to utilize the specified 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”.

Copying and executing an agent via scp and sshNew agent check-in from vault.westeros.local


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:

  • An overview of some unique scenarios that attackers can abuse inside of a FreeIPA environment.


Attacking FreeIPA — Part III: Finding A Path was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article Link: